Why is portfolio management important for growing product teams?

Product organizations don’t fail because they decided to build the wrong feature. They fail because before they know it, they have made a lot of commitments to build a lot of features, and then they don’t have the staff or capacity to make good progress on them. A team will ship an adjacent product, another team will inherit a line of products that no one wants to own, a large customer wants a variant of an existing product and a couple of years later the “roadmap” lists all the work that the company can’t possibly staff to build to an acceptable level of quality.

Portfolio management is the discipline that prevents a company from becoming a ‘lifestyle company’ that does too many things. In other words, it changes the unit of decision from that of individual projects to that of the entire portfolio of projects that a company is investing in, and tries to make a decision on whether each of these is the best use of a company’s resources compared to the other projects that are already funded.

The blind spot in initiative-by-initiative decision making

Single-initiative reviews within the framework of stage-gate processes or business cases are typically conducted for individual proposals. Concentration risk, duplicated investment, or even four of five funded initiatives being dependent on a single platform team may be uncovered in such reviews.

Portfolio planning. It sounds like scoring models against product ideas. In reality, however, it’s a totally different perspective. Before your next funding cycle, it is worth getting the whole leadership team aligned on what product portfolio planning is and how it differs from ranking ideas. That is, instead of asking whether a new product idea is good, the question becomes whether it is a better use of a company’s resources than the other projects that are already funded.

Symptoms worth auditing

• Two or more teams solving overlapping problems for adjacent segments without a shared plan
• Products that generate revenue but have had no meaningful investment decision made about them in three or more cycles
• A roadmap where every item is described as high priority and none has a stated expiry
• Discovery work that consistently loses staffing to delivery commitments when a quarter gets tight

Sorting the portfolio by intent, not by size

Thus early validation products would need to be decided on a different basis than harvest mode products. They would be funded differently, and reviewed on different timescales. And within each of these areas, it would not be sensible to apply uniform targets.

Choosing the mix deliberately

Set target proportions for the distribution of capacity in different positions. Check annually whether these are still appropriate. A company with 90% of its engineers in sustain mode has no growth left. On the other hand, a company with 50% of its capacity in explore mode is likely to underinvest in the products that bring in money.

Resource allocation is the decision, everything else is commentary

Prioritization, without the ability to move staff, is a meaningless exercise. Sure, you can create a ranked list of your backlog items, but that is not a prioritization strategy. In fact, growing a team of engineers to implement your strategy will quickly reveal that agreeing on a strategy in a planning session does not automatically translate into delivering new stuff in the subsequent quarter. In fact, most teams are too busy delivering the work of the previous quarter to do anything new.

Treating teams rather than individual engineers as the allocation unit for work in a Product Organization will deliver far greater results than trying to move individual engineers between projects. Growing teams learn this in planning sessions, when they agree on a strategy for a new product, and then deliver the work of previous quarters on other products. The persistent team that maintains the context for a product will deliver far greater results than a reconstituted team of engineers that are cobbled together to deal with a problem area. Model the platform group as a shared dependency and determine the capacity of this group before deciding to fund projects that will require the services of this group.

Lifecycle discipline and the cost of things you will not kill

Just keeping to the decided products can use up all resources (e.g. Attention, security reviews, compliance work and support). These resources are used in a number of different functions, therefore they are not easy to include in a business case. Therefore, these resources need to be surfaced in Portfolio Management by requiring periodic renewal for each Product Line.

Making retirement possible

1. Define kill criteria at funding time, so stopping later carries out a prior agreement rather than reversing one
2. Quantify the full carrying cost, including support tickets, integration maintenance, and audit scope
3. Plan the customer path first, whether that means migration, a supported alternative, or negotiated wind-down
4. Redeploy the freed capacity in the same cycle, or it dissipates into unplanned work

The operating cadence that holds it together

Without a rhythm, all Portfolio decisions will quickly degrade. Simple reviews are required to track the current allocation by position as well as the current lifecycle position of the various products in the explore, deliver and harvest stages of product development. An annual review of the target mix is required and should have the ability to move capacity.

It is much more valuable to review 8 products honestly than to review 40 superficially. To ensure useful input, keep the input set to a small and consistent number, e.g. Current allocation by position, evidence against each of the explore initiatives, and trends in the carrying costs.