Product Portfolio Management: What Gets Funded?
The planning meeting starts with three reasonable requests. A mature product needs engineers to keep existing customers well served. A newer product needs another team to improve adoption. A proposed product has early promise and a request for a full launch budget. Each owner can defend the request. The company still has the same people and money to divide among them.
Product portfolio management is the decision about that division. It asks which products and related investments deserve resources together, given the organization’s objectives and capacity. The Project Management Institute’s portfolio standard describes evaluating, selecting, prioritizing, and allocating limited resources across investments to serve strategy. A product roadmap answers a narrower question: what a team intends to build or change within its product. A portfolio choice determines how much room each roadmap gets.
The useful question is not, “Which product sounds most exciting?” It is, “What should we keep funding, what should we test with a smaller commitment, and what should we stop paying for during the same planning period?” That question makes maintenance, growth, and new ideas compete for the capacity they actually share. It also forces an uncomfortable fact into view: an attractive product can be the wrong investment when another one carries obligations or has a stronger route to the chosen business goal.
Set the boundary before ranking products
A portfolio needs a declared planning period and a clear strategic aim. Otherwise, a product expected to generate value this quarter is judged against one that may need years, while their costs are presented as if they occur at the same time. Define the period for the decision, then show both the resources required in that period and the likely timing of the benefit. A longer-term opportunity can remain in the portfolio, but its next funding request should be the work needed now to learn or advance it, not an unsupported claim on every future budget.
Start with an inventory of the products and substantial product investments that draw on the same scarce resources. Include existing offerings, improvements under way, proposed launches, and the operating work needed to support customers. The portfolio is broader than a list of upcoming features. PMI notes that portfolio components can include operations and that those components compete for people, funding, and other resources (PMI). If customer support, infrastructure, or contractual work is left off the page, the apparent capacity for new work is fictional.
For each product, write a short investment case in comparable terms: who uses it, the outcome sought in the planning period, current performance against that outcome, the people and spending it needs, the main uncertainty, and the commitments that limit changes. Record dependencies where one product’s work consumes a shared specialist or platform team. A product with a modest direct budget can still block another investment if both need the same engineers. The point of this inventory is to expose the trade, not to create a perfect forecast.
A simple example shows the boundary. Imagine a software company with four product teams available for the next two quarters. Its established reporting product needs one team to meet current customer commitments. Its newer onboarding product asks for two teams to improve adoption. A scheduling idea asks for one team to build a complete product. The requests exactly fill four teams, leaving no capacity for unexpected work or a promising finding from early tests. Approving all three requests is a portfolio decision: it commits the company to a particular mix of obligations, growth work, and uncertainty, even if nobody calls it one.
Fund a measurable change, not an attractive feature list
A product owner may present an impressive delivery plan without explaining what should improve for users or the business. That makes a portfolio review drift into a contest of features. Before assigning people, ask what change the work is meant to produce and how the team will tell whether it happened. Intercom’s account of outcomes and features distinguishes a product change from the customer behavior it may cause and the business result that might follow. The links between those steps are often uncertain, so a shipped feature alone cannot settle whether the investment paid off.
For the illustrative onboarding product, “ship a redesigned setup screen” states an output. “Increase the share of new accounts that complete setup and start using the core product within the next two quarters” states a result that can be checked. The team still needs to define which accounts count as new, what completion means, the starting rate, and the observation window. Without those rules, the target is easy to reinterpret after release. A portfolio leader should ask for that definition before giving the work a large share of scarce capacity.
The established reporting product may need a different kind of outcome. If customers have been promised continued service, the relevant near-term result may be reliable access and fulfilled commitments rather than rapid growth. That does not make the work invisible or immune from scrutiny. It means its investment case should state the service level and obligations that a reduced team would jeopardize. The scheduling idea, meanwhile, may not yet have enough information for a launch outcome. Its next useful result could be evidence that a defined group of customers has the problem and will use a limited solution. Each case should be judged against the next decision it can reasonably inform.
This distinction changes the funding conversation. In the example, assigning one team to reporting is a constraint set by current commitments. The remaining three teams are discretionary only to the extent that the company has no other binding work. Giving two to onboarding and one to a full scheduling build assumes both plans already deserve execution. If the scheduling case is uncertain, a smaller test may be the better purchase: it preserves room to improve onboarding or respond to what customers reveal. The cost is slower progress toward a possible new product. That cost should be stated openly instead of hidden in a favorable score.
Use portfolio tools to expose trade-offs, not issue verdicts
Market position can help explain why two products require different treatment. The classic Boston Consulting Group product portfolio compares market share and market growth to frame products that may generate cash and products that may require investment. That view is useful as a prompt: a mature offering may fund other work, while an offering in a growing market may need resources before it can stand on its own. Yet the labels do not show customer obligations, the cost of a shared platform, or whether a particular product is profitable. A portfolio decision needs those facts alongside the market view.
In the illustrative company, calling reporting “mature” does not justify stripping its team to fund scheduling. First ask what support and delivery obligations reporting carries, how much capacity can be released without breaking them, and whether customers still value the product. Likewise, calling scheduling a “growth bet” does not justify a full build. The missing fact is whether enough customers will adopt a useful solution. The market matrix helps raise questions about investment and cash; it cannot answer those product-specific questions by itself.
A scoring method can improve comparisons among candidate improvements. Intercom’s RICE method combines reach, impact, confidence, and effort. Reach needs a defined population and time period; effort needs a consistent unit; confidence should fall when estimates rest on weak information. Use a score to make assumptions visible and to compare similar options, such as two ways to improve onboarding. Do not turn one number into a ranking of every product, obligation, and exploratory idea. A required service commitment and a speculative new product do not become interchangeable because both have been placed in the same spreadsheet.
For example, suppose two illustrative onboarding changes would each require one team for a quarter. The first is expected to affect 2,000 new accounts in that quarter, based on observed traffic; the second might affect 500, but its effect on each account could be larger. These are assumptions for the example, not reported results. The first is not automatically superior: the second might solve a more severe problem. Record the source and uncertainty behind each estimate, then ask which change best advances the defined adoption outcome. If the result flips when a weak estimate changes slightly, the next investment may be measurement or a limited test, not full delivery.
The portfolio also needs balance across time horizons and risks. Funding only near-term improvements can leave no option for future growth. Funding every new idea can starve products that customers already depend on. Balance is not a fixed percentage for every company; it follows from strategy, commitments, available capacity, and how much uncertainty the organization can afford in the stated period. This is where a portfolio leader must make a judgment rather than ask a matrix to make it.
Make funding a decision that can change
Once the cases are comparable, choose a specific allocation and name the condition for revisiting it. For the illustrative company, a defensible initial choice might protect one reporting team, assign two teams to the onboarding outcome, and use a limited slice of the fourth team’s time to test the scheduling problem. The rest of that team’s capacity remains available for work exposed by the first two investments. This is an illustrative allocation, not a universal staffing ratio. It fits a company that has firm reporting commitments, a measurable onboarding opportunity, and little proof that scheduling deserves a full product build.
There are conditions that would change the call. If scheduling tests show a clearly defined customer group repeatedly uses a limited version and the company can support it, a larger investment becomes easier to justify. If onboarding changes fail to move the agreed measure despite sound execution, continuing at the same level needs a new reason. If reporting’s contractual workload declines, capacity may become available there. Each new fact changes the expected value or the constraints of the remaining work; none erases money already spent.
Atlassian’s lean portfolio guidance connects product-line funding with business priorities and describes redirecting spending as teams learn from users and the market. That supports a practical habit: fund the next meaningful period or learning step, then compare what happened with the assumption that justified the investment. It does not require treating every team as disposable at every review. Moving people has a cost, and some commitments cannot be changed on a short cycle.
A useful portfolio review therefore brings a decision, not just a progress report. For each active investment, ask whether the stated outcome moved, whether the remaining opportunity still matters, what resources are needed next, and which other product would lose those resources. Separate a disappointing result from a broken measurement rule: both require attention, but they lead to different actions. A missed target with credible data may call for a smaller commitment or a change of approach. A target that cannot be measured calls for clearer definitions before more money is committed.
The review frequency should follow how quickly useful information arrives and how reversible the funding is. A team can adjust a product experiment as feedback comes in; a long contract or a release promised to customers has a different decision window. PMI describes portfolio review as a way to change priorities, suspend investments, and reallocate resources while recognizing organizational constraints (PMI). Set a review date and a decision owner for each major investment, but let the nature of the commitment determine what can actually move at that date.
Stop funding responsibly when the case no longer holds
Stopping an investment is often the clearest portfolio choice and the easiest one to describe badly. “Stop the product” may mean stop building new features, stop seeking new customers, stop renewing contracts, or end service. Those are different decisions with different consequences. Before reclaiming a team, identify current users, promised service, support needs, and any contractual or regulatory commitments. PMI’s standard treats termination and resource changes as portfolio decisions and also calls attention to operational support and obligations (PMI).
Suppose the scheduling test in the example finds too little interest to justify a full product. The sensible choice may be to end the experiment and return its capacity to onboarding. That is a relatively simple stop if the test created no enduring customer promise. If reporting later loses its strategic case, withdrawal is harder: the company may still need maintenance, customer notice, migration help, or service through agreed dates. Budget the transition as part of the portfolio decision. Counting all of reporting’s team as instantly available would make the next investment plan unreliable.
The same discipline applies to a product that is performing well. Continuing it is an active choice to spend resources that could go elsewhere. A sound portfolio review makes that opportunity cost explicit and asks what new information could reverse the call. The aim is a mix of products that serves the organization’s chosen goals within real capacity, with enough clarity to move funding when the facts change. That is the practical answer to what to fund: protect commitments, invest in measurable opportunity, buy learning where uncertainty is high, and pay for an orderly exit when a product’s case runs out.