Product Portfolio Roadmaps: Why Your Roadmap Is a Portfolio Allocation Decision, Not a Feature List

A CEO I was working with maintained that the business was spending around 20% of its capacity on Transform — new product bets, adjacency plays, the kind of forward-looking work that boards love to hear about. It sounded healthy. It sounded balanced. It sounded like a company taking its future seriously.

When we actually tagged the roadmap with simple Run / Grow / Transform tags, the picture was completely different. Nearly 50% of discretionary spend was going to Transform. Almost nothing was going to Grow. The lights were being kept on — Run was covered — but nobody was actively growing the existing product lines that were already producing revenue.

The CEO resisted the data. Massively. Because the data told him something he didn’t want to hear: the business wasn’t revenue-led or product-led. It was what-the-CEO-finds-interesting-led. Transform work is exciting — new ideas, new markets, new technology. Grow work is unglamorous — optimising onboarding funnels, reducing churn, increasing expansion revenue on products that already exist. The roadmap reflected the CEO’s enthusiasm, not the market’s needs.

We rebalanced the portfolio. Massively reduced the spend on Transform and focused the business on Grow. The rebalance was painful and politically charged. It was also right — the company had products with genuine growth potential that were being starved of investment because they weren’t novel enough to capture the CEO’s attention.

That is a portfolio story. Not a product story — a portfolio story. And it’s the kind of story that only becomes visible when you look at the roadmap as a portfolio allocation decision rather than a feature list.

A product portfolio roadmap is a capacity-allocation plan across multiple products, each at a different lifecycle stage, each with a different team shape, each with different objectives and success metrics. It replaces the single-product feature roadmap with a portfolio-level allocation view: how much capacity is going to each product, why, and is that allocation consistent with what the market needs from each product at its current stage? The roadmap is the portfolio decision — it is the mechanism by which the organisation converts strategic intent into operational reality.

Sign up (free) to see your portfolio allocation on a single grid

Most Companies Are Portfolios — Single-Product Thinking Is the Exception

Almost every article about product portfolio management treats “portfolio thinking” as something large enterprises do. That framing is wrong. Very few companies above seed stage have genuinely one product. Most have a core product, at least one adjacent product line, probably an internal platform, possibly an acquired product they’re integrating, and usually two or three Transform bets in various states of health.

The question is not whether you have a portfolio. The question is whether you manage it as one or pretend each product is an island with its own separate roadmap, its own separate priorities, and its own separate reality.

Single-product thinking creates three specific problems:

1. Invisible cross-subsidy. Product A’s engineering capacity is funding Product B’s maintenance without anyone formally deciding that. The best engineers end up on the product with the loudest stakeholder, not the product with the highest-leverage opportunity.
2. No lifecycle-stage differentiation. A mature cash-cow product and a pre-PMF new bet are managed with the same roadmap cadence, the same sprint structure, and the same success metrics. They need completely different operating models (see the product lifecycle directory ).
3. No allocation governance. The board sees individual product updates but never the portfolio-level question: are we spending the right amount on the right products at the right stage? That question is the one that catches the CEO-interest-led anti-pattern before it eats the budget.

The Roadmap IS the Portfolio Decision

This is the foundational claim of the article, and the claim that no competitor in the SERP makes.

A roadmap is a capacity-allocation plan. It decides which squads work on what, for how long, against which objectives. In a multi-product company, that plan is inherently a portfolio allocation — whether it’s managed as one or not. If Squad A is on Product 1 and Squad B is on Product 2, the roadmap has already made a portfolio decision. The only question is whether that decision was deliberate.

The sequence that works:

1. Portfolio view first. Before any feature-level prioritisation, look at the capacity split across products. What percentage is on each product? Is that consistent with each product’s lifecycle stage and growth opportunity?
2. Per-product objective setting. Once the portfolio-level allocation is decided, each product gets objectives appropriate to its stage — discovery outcomes for pre-PMF products, reference-customer targets for chasm-stage products, expansion revenue for growth-stage products, margin and NRR for mature products.
3. Feature prioritisation within products. Only now do you reach for RICE , BRICE , or WSJF . Prioritisation is a within-product exercise, not a portfolio exercise. The portfolio question is upstream.

Teams that skip step 1 and jump to step 3 are doing feature prioritisation inside a portfolio allocation they never examined. That’s how you end up with a beautifully prioritised roadmap that is strategically incoherent — every individual feature is well-reasoned, but the overall allocation is driven by which product’s PM shouts loudest.

Per-Product Lifecycle Stage, Per-Product Operating Model

Every product in a portfolio is at its own lifecycle stage. A mature product generating £5m ARR with stable retention is not in the same stage as a pre-PMF product with three paying customers. They need different things:

The portfolio roadmap makes this visible. Each product’s row on the grid should be running the operating model appropriate to its stage, not the operating model the organisation defaults to for everything. A pre-PMF product measured on ARR will be killed before it has a chance. A mature product measured on feature velocity will be over-invested. The portfolio view is what stops the organisation applying a one-size-fits-all model.

Try RoadmapOne to tag products by lifecycle stage and see your portfolio — free sign-up

The Five Portfolio Lenses (and When to Reach for Each)

The blog already has detailed articles on each of the portfolio frameworks below. This section is the chooser — which lens answers which portfolio question.

You don’t need all five. You need the one whose question matches the conversation your board is trying to have.

• Annual planning? Start with RGT. It’s the simplest and produces the sharpest allocation conversation.
• Innovation pipeline review? Three Horizons. It’s designed for exactly this.
• “Which products do we keep and which do we kill?” BCG. It’s the classic portfolio-rationalisation lens.
• “Where do we invest next?” GE-McKinsey or Ansoff, depending on whether you’re choosing between existing products (GE-McKinsey) or choosing between types of growth bet (Ansoff).

The CEO-Interest-Led Anti-Pattern

This is the failure mode that earns the portfolio view its keep, and the one nobody else writes about because it requires saying something uncomfortable about the CEO.

The pattern:

1. The CEO has a favourite product or technology area — usually the newest, most novel thing in the portfolio. It’s intellectually stimulating. It involves interesting technology. It’s the product the CEO talks about at conferences.
2. Capacity quietly migrates toward the CEO’s favourite. Not through a formal reallocation — through a thousand small decisions: the best engineers get assigned there, headcount requests get approved faster, priority disputes resolve in its favour.
3. The Grow products — the ones generating revenue, the ones where a 5% improvement in onboarding conversion would move the P&L — are starved. Not dramatically; incrementally. Nobody makes a decision to starve them. It just happens because the CEO’s attention is elsewhere.
4. A year later the portfolio looks like: Run (barely maintained), Transform (over-invested, under-performing), Grow (non-existent). The company is keeping the lights on and chasing novelty, with nothing in between.

The fix is simple to state and hard to execute: tag the roadmap, count the capacity by RGT, and show the board. Once the allocation is visible, the CEO-interest-led pattern cannot survive scrutiny — because no board, seeing that 50% of discretionary spend is on Transform while Grow is at zero, will accept “but the CEO finds it interesting” as a rationale.

RGT is the cheapest diagnostic. It takes an afternoon to tag every objective on the roadmap. The conversation it produces takes a quarter to resolve. But the conversation is almost always the right one to be having, and it’s the conversation the portfolio was preventing by being invisible.

The Minimum Viable Team Per Product

A portfolio allocation that doesn’t translate into dedicated teams per product is a portfolio allocation on paper only. The operational unit of a portfolio is the minimum viable team: two engineers and one product person, dedicated, full-time, with a proper business case and protected capacity.

The rules are the same ones this blog has argued for repeatedly:

• Dedicated means dedicated. A team that’s nominally on Product B but gets pulled onto Product A every time there’s a fire is not a Product B team. It’s a Product A team that occasionally does Product B. The portfolio allocation is a lie.
• Measured on per-product outcomes. The pre-PMF team’s outcome is validated assumptions and earlyvangelists . The growth team’s outcome is expansion revenue and segment win rate. The mature team’s outcome is NRR and margin. Same organisation, different metrics, same grid. See outcome-based roadmaps and outcome vs output vs input .
• Protected from cross-product interrupt. WIP limits and the discipline to resist priority whiplash are the enforcement mechanism.

Most companies can sustain three to five minimum viable teams. That means most companies can genuinely run three to five products in their portfolio at any time. Claiming a portfolio of eight products with three teams is claiming something operationally impossible — and it usually means five of those “products” are getting side-of-desk treatment that will never produce results.

The 2026 Reframe: AI Changed Portfolio Economics

AI has collapsed the cost of building a product to near zero. That changes portfolio economics in two ways that matter.

First, the portfolio can now contain more candidates. It used to cost £500k to build a credible prototype; now it costs a weekend. A team can plausibly spin up three or four new product prototypes in a quarter. The temptation is to do exactly that — and the result is a portfolio of ten products, each one a plausible-looking prototype, none of them with a dedicated team, a business case, or a path to product-market fit . Portfolio discipline matters more than ever because the cost filter that used to prevent portfolio bloat has gone.

Second, the differentiator has shifted. When build cost was high, a product that existed was already differentiated by existing. When build cost is near zero, existing is not differentiated — your competitor can replicate your functionality in weeks. The portfolio’s durable value now lives in distribution, brand, reference customers, network effects, and deep workflow integration. The portfolio allocation should reflect this — more investment in GTM and retention for products that have PMF, more investment in validation and crown-jewel differentiation for products that don’t. See the AI-era lifecycle reframe for the deeper treatment.

The PE / NED Diagnostic for Portfolio Health

Five questions I ask of every portfolio company I review. The answers take fifteen minutes and tell you most of what you need to know.

1. Can you show me the capacity split across products, by RGT tag? If not, the portfolio isn’t managed — it’s happening by accident. If yes, look at the Grow percentage. Zero or near-zero Grow is the single most common finding and the single highest-leverage one to fix.
2. Does each product have a dedicated minimum viable team? If a product doesn’t have at least two engineers and one product person, full-time, it isn’t a product — it’s a side project. Count the real teams; that’s the real portfolio size.
3. Is each product’s success metric appropriate to its lifecycle stage? Pre-PMF measured on ARR is theatre. Mature measured on feature velocity is waste. Check the metrics match the stage.
4. Is the portfolio allocation consistent with the business case for each product? Every product should have a PID / business case with a committed revenue line. The portfolio allocation (capacity %) should match the relative scale of those revenue commitments. If a product has 30% of the roadmap capacity but 5% of the committed revenue, someone needs to explain why.
5. When was the portfolio allocation last deliberately reviewed? If the answer is “at annual planning and not since”, the allocation has drifted — guaranteed. Quarterly portfolio reviews are the minimum cadence. Anything less and the CEO-interest-led anti-pattern fills the vacuum.

How the Portfolio Connects to the Product Operating Model

Marty Cagan’s product operating model is about how individual teams work — empowered teams, discovery-led, outcome-measured. The portfolio is about which teams exist, on which products, with what allocation.

The two need each other. An empowered team without a portfolio-level allocation is a team that doesn’t know whether it’s supposed to be hunting PMF or defending margin — because the portfolio question was never asked. A portfolio allocation without empowered teams is a spreadsheet exercise that produces nothing — because the teams are still running feature backlogs, not pursuing outcomes.

The healthy pattern: the portfolio-level conversation happens at the board or ExCo, quarterly, using RGT or Three Horizons as the vocabulary. The individual product-level conversation happens inside each team, continuously, using dual-track agile , opportunity solution trees , and discovery techniques. The two levels are connected by objectives — the board sets per-product objectives based on the portfolio allocation, and the teams are empowered to determine the key results that deliver those objectives (see objectives to key results and OKRs for product teams ).

Try RoadmapOne to manage portfolio allocation and per-product objectives on one grid — free sign-up

Common Portfolio Failure Modes

Beyond the CEO-interest-led pattern, three other failure modes are worth naming.

The Cash Cow Attention Monopoly

The most successful product in the portfolio consumes all executive attention, all the best engineers, and all the budget flexibility. Adjacent products and new bets are starved — not because anyone decided to starve them, but because the cash cow’s stakeholders are louder, its revenue is more visible, and its fires are more urgent. The result is a portfolio with one over-maintained product and several under-invested ones. The Innovator’s Dilemma is what eventually catches up.

The Zombie Portfolio

Products that failed to achieve PMF but were never formally killed. They sit on the roadmap consuming 0.5 of an engineer each, producing no meaningful outcomes, and giving the portfolio a false sense of breadth. Three zombie products consuming 1.5 engineers is 1.5 engineers that could be on a real product’s minimum viable team. The honest move is to kill them — but killing requires someone to say out loud that the product failed, which most organisations avoid.

The Acquisition Integration Trap

An acquired product is consolidated onto the parent’s platform before it has achieved PMF in its own markets. The innovation lifecycles are coupled; the acquired product loses its ability to iterate independently; and any remaining PMF signal degrades because the product is now subordinated to the parent’s priorities. The better pattern: keep acquired products separate until each market has achieved its own PMF signal, then migrate deliberately. See the PMF coupling anti-pattern for the worked example.

How RoadmapOne Helps

RoadmapOne was built for this problem. The grid — squads in rows, sprints in columns — shows the portfolio allocation as a physical fact: which squads are on which products, for how long, against which objectives. Tag objectives by Run / Grow / Transform or Three Horizons and the analytics show the board the actual capacity split, by percentage, across the portfolio. Compare that to what leadership thinks the split is. The gap is always there, and closing it is always the right conversation.

Capacity-based planning is the underlying mechanism. It makes the portfolio allocation operationally real — not a strategy slide, but a grid with named squads, named sprints, and named objectives that someone is accountable for.

Frequently Asked Questions

What is a product portfolio roadmap?

A product portfolio roadmap is a capacity-allocation plan across multiple products, each at a different lifecycle stage. Unlike a single-product feature roadmap, it answers the cross-cutting question: are we spending the right amount on the right products at the right stage? The allocation decisions are made at the portfolio level first (how much capacity per product), with feature-level prioritisation happening within each product afterwards.

How is portfolio management different from feature prioritisation?

Feature prioritisation (using frameworks like RICE or BRICE ) is a within-product exercise — it decides which features to build next for a given product. Portfolio management is upstream — it decides how much capacity each product gets in the first place. You can have perfectly prioritised features inside a strategically incoherent portfolio allocation. The portfolio question comes first.

How many products can a company realistically manage?

The honest answer is: however many minimum viable teams the company can sustain. A minimum viable team is two engineers and one product person, dedicated, full-time, with a proper business case . Most companies can sustain three to five such teams. Claiming a portfolio of eight products with three teams means five products are getting side-of-desk treatment that will never produce meaningful results. Count the real dedicated teams; that’s the real portfolio size.

How often should we review the portfolio allocation?

Quarterly is the minimum. Annual planning sets the initial allocation; quarterly reviews catch drift. The CEO-interest-led anti-pattern fills any governance vacuum, so the longer between reviews, the more the allocation drifts toward whatever the most senior person finds interesting. The review itself is straightforward: tag the roadmap by RGT , count the capacity percentages, compare to what the board thinks the allocation is, and address the gap.

Which portfolio framework should we start with?

Run / Grow / Transform for almost everyone. It’s the simplest tagging framework, it produces the sharpest allocation conversation, and it’s the one most likely to surface the common failure modes (zero Grow, over-indexed Transform, CEO-interest-led distortion). The other four frameworks — BCG , GE-McKinsey , Three Horizons , Ansoff — are more sophisticated lenses for specific portfolio questions. Start with RGT; graduate to the others when you need them.

What’s the relationship between portfolio management and the product operating model?

The portfolio decides which teams exist, on which products, with what allocation. The product operating model (Cagan / SVPG) decides how those teams work — empowered, discovery-led, outcome-measured. You need both. A portfolio allocation without empowered teams is a spreadsheet that produces nothing. Empowered teams without a portfolio allocation don’t know whether they’re supposed to be hunting PMF or defending margin, because nobody asked the upstream question.

Sign up (free) to manage your product portfolio on a single roadmap grid

Conclusion

Very few companies have one product. Most are portfolios, whether they manage them as one or not. The roadmap — which squads work on which products, for how long, against which objectives — is the portfolio allocation decision. Making that decision deliberately, with lifecycle-stage-appropriate operating models per product, dedicated minimum viable teams, and quarterly board-level governance, is the discipline that separates portfolio management from portfolio accident.

The CEO-interest-led anti-pattern — where capacity migrates toward whatever the most senior person finds intellectually stimulating — is the most common and most expensive failure mode, and it is only visible when you tag the roadmap and show the board the actual numbers. RGT is the cheapest lens. An afternoon of tagging produces a conversation that takes a quarter to resolve. The conversation is almost always the right one to be having.

Stop looking at your roadmap as a feature list. Start looking at it as a portfolio allocation. The allocation you’re making today — whether you chose it or not — is the allocation your business will be living with for the next twelve months. Make it deliberate.

Baxter image prompt (photorealistic, 4:3): Baxter the wirehaired dachshund sitting at a grand wooden desk in front of a large wall map — the kind with coloured pins and thread connecting different locations. A few pins are clustered densely in one area; others are spread thinly. A magnifying glass resting beside his paw. Warm late-afternoon light from a window to the side. No text on the map — just colours and pins. Expression: quiet assessment, the kind of look that says “this isn’t balanced”.