Ship a portfolio, not a project

When investing, we think of building a portfolio made up of a variety of assets. In a similar way, I encourage teams to ship a portfolio of projects. By this, I mean taking on a set of projects that vary in terms of size, problem area, and risk in any given quarter or half.

Here’s my rationale:

Diversifies risk of project outcomes

Not all projects will succeed. This is especially true on user-facing teams that run experiments—not all experiments will yield results that the team is looking for.

However, a team can increase their likelihood of impact with a variety of projects. For example:

  • A larger, riskier project fails, but the team is still able to claim a successful half by shipping three small projects that were more certain wins.
  • A project aimed at improving one part of a funnel isn’t effective, but another project focused on a different part shows good results.

By planning a set of projects that vary in terms of size, problem area, and risk, the team is able to deliver results on more consistent basis, quarter over quarter.

A steady drumbeat of wins

Working on a mix of small and large projects means that some project is typically hitting a milestone in any given week. Some projects are launching in beta, some as production experiments, some may be shipping. This gives a team momentum, which is critical to morale. Shipping is a muscle that’s distinct from building, and it’s important to practice it regularly.

Internally, your team is perceived as high output, constantly shipping. Externally, your users recognize the continued improvements and product announcements.

The opposite of this is stagnation. A team invests all of its resources in one large, risky project. Leadership begins to wonder if the project is worthwhile, team morale drops as nothing has shipped in months, users begin to wonder if the product is abandoned.

Balances the team’s schedule

Gaps are inevitable in a team schedule. Maybe one platform finishes before another, or a team member goes on vacation during a project. Things naturally get out of sequence, and that’s okay. In these scenarios, it’s helpful to have well-scoped projects ready to fill the gaps. These projects can bring a schedule back into alignment while continuing to ship.

For example, one engineer works on a two-week project while another engineer is unavailable, before starting a longer-term project together.

A mix of projects in terms of size also gives team members time to recover after a large project. Working on a multi-month project can be draining, and it’s easy to burn out going from one large project to the next. Having engineers take a few down weeks to ship some easy wins can be rejuvenating.

The portfolio concept also applies to individual contributors

I like this philosophy for ICs just as much as I do for teams. As an IC, you typically have one major project to focus on. But at the staff level, simply completing a project often isn’t sufficient to meet the bar.

Instead, it’s helpful to actively identify problems, even if they’re small, and work those into a portfolio for the half. These can be things like refactoring an area of the codebase, or implementing a small feature requested by a user. Continuously shipping small improvements can make a major impact, especially in cases where a large project drags on, or doesn’t ship for external reasons.