A healthy roadmap allocates roughly 70% of investment to core (H1), 20% to emerging (H2), and 10% to speculative bets (H3)—adjusted for your market maturity and risk appetite. The three-horizons model turns "should we fund this moonshot?" from a per-feature argument into a portfolio-level decision with an explicit target mix you can measure against.
Quick Answer: Use the three horizons—H1 (core, defend and extend), H2 (emerging, scale what's working), H3 (bets, explore what's next)—to classify every roadmap item. Target a 70/20/10 split by investment (not headcount alone), and treat any quarter where H1 exceeds 85-90% as a portfolio in firefighting mode, not a strategy.
What Is the Three Horizons Model, Exactly?
The three horizons model, introduced by McKinsey consultants Mehrdad Baghai, Stephen Coley, and David White in The Alchemy of Growth (1999), classifies investment into three time-boxed categories of maturity and risk. It was built for corporate growth strategy, but it maps cleanly onto product portfolios: every initiative on your roadmap is either defending today's revenue, scaling tomorrow's bet, or exploring an option that may never ship.
The three horizons, applied to product work, look like this:
- Horizon 1 (H1) — Core. Your proven, revenue-generating product lines. Investment here defends market share, fixes reliability, and extends existing value.
- Horizon 2 (H2) — Emerging. Initiatives with validated demand that are scaling but not yet mature. They need investment to cross from "promising" to "core."
- Horizon 3 (H3) — Bets. Exploratory work—new markets, unproven mechanisms, early-stage prototypes—where the goal is learning, not revenue, and most bets will fail.
The critical nuance is time horizon, not project size. An H3 bet that validates becomes tomorrow's H2, and a mature H2 eventually becomes H1. The model describes a pipeline, not three permanent buckets.
Why Balance Is a Portfolio Question, Not a Per-Feature One
Balance across horizons only makes sense as an aggregate allocation across your entire roadmap—asking "is this one feature H1 or H3?" in isolation tells you nothing about whether your portfolio is healthy. The real question is what percentage of total investment, across every active initiative, sits in each bucket this quarter.
This is the shift most PM teams miss. They evaluate each feature request on its own merits—customer value, effort, urgency—and approve or reject it individually. That process can produce a portfolio that's 95% H1 without a single bad decision along the way, because no one ever asked what the aggregate looked like.
Per-feature thinking optimizes locally and starves the future. Each H1 fix is individually defensible: a real customer complaint, a real bug, a real churn risk. But stack twenty of those decisions together and you've quietly defunded every emerging bet, without ever making that trade-off explicit. The fix isn't better feature-level judgment—it's a periodic portfolio review that looks at the mix as a whole, the same way a financial portfolio manager rebalances a fund rather than second-guessing each individual trade.
This connects directly to the broader discipline covered in a complete guide to roadmapping: a roadmap is a portfolio-management artifact first, a scheduling tool second.
How This Differs From Prioritization Frameworks
Horizon balance operates one layer above per-item prioritization frameworks like RICE or Kano—it sets the budget envelope those frameworks compete within. RICE tells you which H1 features to fund first; it does not tell you whether H1 should be 60% or 90% of the roadmap.
Run horizon allocation as the first pass, then apply item-level scoring inside each bucket. Trying to prioritize H1 firefighting against H3 exploration on the same RICE scale is a category error—reach and confidence mean structurally different things for a proven feature versus a two-week prototype.
A Target Allocation Heuristic You Can Defend
A commonly cited starting heuristic is 70% H1, 20% H2, 10% H3 by investment (engineering time, budget, or headcount-weeks), popularized in innovation-management literature including Google's well-documented 70/20/10 rule for engineering time. Treat it as a starting point to calibrate, not a universal law—your ratio should shift with market maturity, cash position, and competitive pressure.
| Market Context | Suggested H1/H2/H3 Split | Rationale |
|---|---|---|
| Mature market, stable revenue | 70/20/10 | Defend core, fund emerging, keep optionality alive |
| Early-stage startup, pre-PMF | 40/30/30 | Core barely exists; most work is discovery |
| Post-PMF scale-up | 60/30/10 | Scaling H2 aggressively while defending new core |
| Declining market / sunset product | 85/10/5 | Extraction mode; minimal new bets justified |
| Cash-constrained turnaround | 90/10/0 | Survival first; explicitly pause exploration |
The table's point isn't the exact numbers—it's that the ratio is a strategic choice you make on purpose, not a default that emerges from whichever tickets got loudest this sprint. Bring this table into a leadership or board conversation and you have a portfolio argument, not a feature-by-feature negotiation.
Measuring the Mix Without Gaming It
Measure horizon allocation by engineering-weeks or budget committed, not by ticket count or feature count—a single H3 prototype and a single H1 hotfix are wildly different sizes, and counting items instead of effort will overstate whichever bucket has smaller, more numerous tasks.
- Tag every roadmap item with a horizon at intake, not retroactively at sprint planning.
- Sum estimated effort per horizon for the quarter (or rolling six weeks), not just count of items.
- Compare against your target ratio and flag drift before it compounds across multiple quarters.
- Review quarterly, not annually—horizon mix drifts fast when incident volume spikes.
Outcome-based framing helps here too: tagging by outcome pursued rather than feature shipped makes horizon classification more honest, a point elaborated in outcome-based roadmaps versus feature lists.
How to Detect an H1-Overloaded Portfolio
A portfolio overloaded on H1 typically shows four symptoms together: shrinking discovery time, an aging or empty H3 pipeline, roadmap conversations dominated by defect counts instead of opportunity size, and leadership surprised by competitive moves they had no bet in flight to counter. Any one symptom alone is normal; all four together signal firefighting has become the strategy by default.
Watch for these specific signals:
- Discovery research time trending toward zero across consecutive sprints—a proxy metric worth tracking explicitly, since it's usually the first thing sacrificed when H1 pressure spikes.
- No active H3 experiments for two or more quarters running. A healthy pipeline always has something in exploration, even if small.
- Roadmap reviews spend most of their time on bug/incident counts rather than opportunity sizing or bet outcomes.
- Competitors ship in a space you have zero exploratory presence in—not because you evaluated and passed, but because nothing was ever funded to look.
- Engineers report chronic reactive mode—sprint plans repeatedly reshuffled by urgent fixes, with planned H2/H3 work perpetually bumped.
This pattern is worth naming explicitly with stakeholders and executives, since an H1-heavy roadmap often looks responsible from the outside—you're fixing real problems—while quietly forfeiting future position. Being candid about that trade-off in roadmap communication, rather than papering over it, is the subject of communicating roadmap uncertainty honestly.
The Inverse Failure: Too Much H3
Overinvestment in H3 is less common but just as damaging—a portfolio spending 40%+ on speculative bets while core reliability degrades will bleed the revenue base that funds exploration in the first place. The signal here is inverted: rising churn or support volume in the core product while leadership attention stays fixed on the next big bet.
Balance cuts both directions. The heuristic exists precisely because either extreme—all defense or all exploration—eventually starves the other.
Turning Bets Into Committed Investment
A bet only earns promotion from H3 to H2 once it clears a defined evidence bar—typically validated demand signal, a working prototype, or a committed pilot customer—not simply because it has survived long enough or a champion pushed hard enough. Without an explicit graduation gate, H3 work either stalls forever in prototype limbo or gets promoted on politics rather than evidence.
Define graduation criteria before the bet starts, not after:
| Horizon Transition | Evidence Required | Typical Owner |
|---|---|---|
| H3 → H2 | Validated demand signal, working prototype, committed pilot user | PM + design lead |
| H2 → H1 | Reliable revenue or retention contribution, operational maturity | PM + engineering lead |
| H1 → Sunset | Declining usage, high maintenance cost relative to value | PM + leadership |
Grounding H3 exploration in real customer problems—rather than internal enthusiasm—connects to jobs-to-be-done discovery discussed in the complete guide to jobs-to-be-done, and to mapping where friction actually occurs across the customer journey before committing H2 investment to smooth it.
Keeping the Mix an Explicit Decision, Not an Accident
Most portfolio drift happens silently: no one decides to abandon H3, it just stops getting tagged, tracked, or discussed until a quarter later someone notices there's nothing in the pipeline. The fix is procedural, not motivational—make horizon tagging a first-class field on every roadmap item, and make the mix visible enough that drift gets caught before it compounds.
Key Takeaways
- The three horizons—H1 core, H2 emerging, H3 bets—classify investment by maturity and risk, not by project size or team.
- Balance is a portfolio-level question: evaluate the aggregate mix across all roadmap items, not whether any single feature "deserves" funding.
- 70/20/10 is a starting heuristic, not a universal rule—calibrate it to your market maturity, cash position, and competitive pressure.
- Measure by effort (engineering-weeks or budget), not ticket count, or you'll overstate whichever bucket has smaller, more numerous items.
- An H1-overloaded portfolio shows four converging symptoms: vanishing discovery time, an empty H3 pipeline, defect-dominated roadmap reviews, and unanswered competitive moves.
- Define explicit graduation criteria for H3 → H2 → H1 transitions so promotion runs on evidence, not politics or persistence.
- Tag horizon at intake and review the mix quarterly—drift compounds silently when nobody is watching the aggregate.
Frequently Asked Questions
What is the ideal H1 H2 H3 ratio for a product roadmap?
A commonly cited starting point is 70% H1, 20% H2, 10% H3 by investment, but the ideal ratio depends on market maturity. Pre-product-market-fit startups often run closer to 40/30/30, since most of their work is still discovery rather than defense.
How do I know if my roadmap is too focused on H1?
Watch for four converging signals: discovery time trending toward zero, no active H3 experiments for multiple quarters, roadmap reviews dominated by defect counts, and competitors moving into spaces you have no exploratory presence in. Any single signal is normal; all four together mean firefighting has become your default strategy.
Is the three horizons model the same as a now-next-later roadmap?
No—they solve different problems. Now-next-later communicates timing and confidence to stakeholders, discussed in depth in now-next-later roadmap honesty, while the three horizons model classifies investment by maturity and risk to set your portfolio's funding mix; many teams tag items with both a horizon and a now-next-later timeframe simultaneously.
How often should a team review its horizon allocation?
Review the mix quarterly, or on a rolling six-week basis if your roadmap moves fast, rather than annually. Horizon balance drifts quickly whenever incident volume spikes, so infrequent review lets an H1-heavy quarter compound into a multi-quarter pattern before anyone notices.
Can a single feature belong to more than one horizon?
Not simultaneously, but a feature's horizon classification can change over time as it matures—an H3 prototype that validates demand graduates to H2, and a scaled H2 initiative eventually becomes H1 core. Define explicit graduation criteria in advance so that transition runs on evidence rather than internal momentum.