Product Portfolio Strategy: Decide Where to Invest, Improve or Stop

What a Product Portfolio Strategy Needs to Decide

A product portfolio strategy defines what a group of products should achieve together and how investment choices will support that purpose. It should explain which customers and needs the portfolio serves, what each product contributes, and where the organization will invest, improve, maintain, learn, or stop.

The practical test is whether the strategy helps resolve a real choice. If two products need the same engineer, which commitment takes priority? If an emerging product has promising evidence, what will you fund next, and what will receive less attention?

Start with the purpose of the product portfolio, compare the evidence and constraints, then state the tradeoff. The result should be a decision people can act on and revisit as conditions change.

Define the Outcome the Products Should Support

Give the portfolio a direction specific enough to constrain investment. “Grow all our products” leaves almost every request eligible. “Help multi-site service businesses coordinate bookings and staffing, while protecting the reliability of their existing operations” gives leaders a basis for choosing between opportunities.

Identify the customers, needs, business outcomes, and capabilities that belong within that direction. Also name what sits outside it. An attractive opportunity in an unrelated market may require a separate strategic choice before it receives funding from this portfolio.

Roman Pichler’s guidance on product portfolio strategy describes portfolio-level decisions as guardrails for individual product strategies. That is a useful starting point: teams need room to choose how their product contributes within a shared direction.

Before considering new investment, make existing constraints visible. Include service commitments, available skills, shared infrastructure, and work already promised. Some commitments may be renegotiable, but the strategy should identify that choice and its consequences explicitly.

Explain Each Product's Role and Relationships

Describe why each product belongs in the portfolio now. A mature product might support established customer workflows and generate revenue. Another might extend the offer into a related need. An early experiment might test whether a new market deserves further investment.

These descriptions are useful working roles, not permanent labels. A product's role should change when evidence changes its contribution or the portfolio changes direction.

Look beyond each product's standalone results. Ask whether it supplies a capability another product needs, supports a combined customer workflow, or creates a dependency that limits other choices. A shared platform may deserve investment even when it has no direct sales revenue.

Examine overlap in the same way. Two products serving the same customers may reinforce each other, substitute for each other, or create avoidable complexity. State which relationship you expect and what evidence supports it. A bundled offer does not establish that customers value every component.

If the plans rely on incompatible beliefs about customer behavior or buying authority, investigate those beliefs before treating the combined business case as established.

Compare Evidence Appropriate to Each Product's Stage

Use a common set of questions across the portfolio: What value does this product create? How strong is the evidence? What would the next investment accomplish? What does it depend on? What happens if we decline it?

The evidence answering those questions will differ by stage.

For an established product, examine customer outcomes, retention, usage of important workflows, support demands, operating costs, and the economics of serving customers. Segment the evidence where necessary. A healthy overall retention figure can conceal a problem in the customers the strategy aims to serve next.

For an emerging product, examine evidence of the problem, current alternatives, observed behavior in trials, willingness to pay, and the assumptions still unresolved. Separate interest in the idea from evidence that people will adopt it or change how they work.

An experiment will not have the same revenue history as a mature service. Give it a bounded learning objective and assess whether the proposed work can resolve a consequential uncertainty. Missing commercial evidence should remain visible when deciding whether to fund a larger commitment.

Keep forecasts, observations, and interpretations separate. Note the source, period, segment, and limitations. If a funding choice changes substantially when one uncertain forecast moves, make that sensitivity part of the discussion.

The classic BCG growth-share matrix uses market growth and relative market share to frame portfolio choices. A matrix can prompt useful questions, but a quadrant alone cannot explain a product's service obligations, shared dependencies, or the evidence needed for its next investment.

Choose What the Next Investment Will Do

Make the decision specific to a scope of work and a review point. Prodstack’s portfolio view can help you review product health across a portfolio before assigning one of these choices. A product can need reliability improvements while receiving no new market-expansion funding. The following choices are a practical vocabulary for the review, rather than a mandatory lifecycle model.

Maintaining a product still requires work. Stopping a feature initiative does not automatically end support for the product. Retirement may consume capacity before it releases any, so include the transition effort when comparing alternatives.

Use capacity planning to check whether the proposed commitment is feasible. An allocation is incomplete if it assigns budget but relies on skills already committed elsewhere.

Worked Example: Booking Reliability or a Forecasting Experiment?

The following example is fictional.

A company has a mature appointment-booking product and an emerging workforce-forecasting product. Its portfolio direction is to help multi-site service businesses coordinate bookings and staffing.

Booking has paying customers and existing reliability commitments. Its team also wants a new management dashboard. Forecasting has encouraging customer interviews, but the team has not established whether managers will use its predictions to change staffing decisions.

Both initiatives need the same data engineer. For this example, assume that after reserving the agreed booking reliability work, the engineer has at most three days available over the next four weeks. The research owner also confirms capacity for a small customer trial.

Leadership chooses to:

• Protect the booking reliability commitment.
• Defer the discretionary booking dashboard.
• Authorize a forecasting experiment capped at three data-engineering days over four weeks, using a limited prototype with two willing customer teams.

The portfolio lead owns the funding decision. The Forecasting PM owns the experiment and prepares the evidence for review.

The experiment asks whether managers use the forecast to make identifiable staffing decisions and what prevents them from doing so. The team will compare the proposed workflow with how those managers currently plan staffing. Interviews expressing interest are useful context; they do not answer the behavior question.

The decision accepts a cost: booking customers wait longer for the additional dashboard. Leadership records why it prefers the learning opportunity now and identifies who will communicate the delay to affected stakeholders.

At the review, evidence of useful staffing decisions could justify considering another bounded pilot. A broader rollout would still require evidence about repeat use, economics, and delivery feasibility. If managers only inspect the report without using it, investigate the barrier before authorizing more development.

If the prototype cannot fit within the effort limit, the team returns for a decision rather than silently expanding the allocation. If booking reliability needs more capacity, leadership reduces or delays the experiment and records the consequence.

This decision funds a next step. It does not declare Forecasting a proven growth product or permanently reduce Booking's role.

Record the Choice and the Conditions for Changing It

For each material investment decision, capture the following. The entries should be short enough to review together and specific enough to guide the people doing the work.

• Objective and product role: the portfolio outcome the investment supports and why this product should contribute.
• Evidence and uncertainty: the source material, its limitations, and what remains assumed.
• Funded scope and limit: the work authorized, capacity or budget boundary, and responsible owner.
• Obligations and dependencies: the service baseline, shared capabilities, and transition work that must be covered.
• Displaced alternative: what receives less investment, is delayed, or stops.
• Authority and rationale: who made the decision, when, and why the selected option was preferred.
• Review condition: the evidence, event, or date that will trigger reconsideration and the possible responses.

In the fictional example, the funding limit and four-week review prevent an exploratory commitment from becoming an indefinite project. A reliability incident is a separate trigger that can reopen the allocation sooner.

Once approved, connect the portfolio choice to product roadmaps so teams work from the same commitment. Use portfolio progress tracking to monitor follow-through, while keeping the investment rationale accessible.

At the next review, compare what happened with the conditions recorded. Continue, change, or end the investment with an explicit decision; do not let an expired experiment keep consuming capacity by default.