Your roadmap's investment mix is the split of engineering capacity across run (keeping existing systems alive), grow (improving what already works), and build/transform (new bets). Left unexamined, that split defaults toward run — because outages, tickets, and tech debt escalate themselves while growth work has to be chosen deliberately.
Quick Answer: Set an explicit run/grow/transform target (a common starting range is 30/50/20), tag every roadmap item against it, and audit actuals quarterly. If you don't measure where capacity actually went, firefighting will quietly eat your growth budget every time.
This isn't the three-horizons model wearing a new name. Horizons McKinsey-style is about time horizon — what pays off this year versus in three. The build/run/grow lens is about capacity allocation right now — literally, what percentage of this quarter's engineering-days went to each bucket, regardless of when the payoff lands. A horizon-3 bet and a horizon-1 feature can both be "grow" work in the same sprint. The two frameworks answer different questions, and conflating them is why most roadmap reviews talk past each other.
Why the Investment Mix Defaults to Firefighting
Without an explicit allocation target, roadmap capacity drifts toward run work because maintenance has a built-in escalation path that growth work doesn't. A production incident, a security patch, or an angry enterprise customer generates its own urgency; a growth initiative has to compete for attention on its merits, every single planning cycle.
This is a structural bias, not a discipline failure. Run work is reactive and self-prioritizing — it shows up as a page, a support ticket, or a Slack fire, and someone drops what they're doing. Grow work is proactive and has to be argued for — someone has to build the case, get it ranked, and defend it against the next incident that bumps it. Over several quarters, the asymmetry compounds:
- Deferred maintenance becomes urgent maintenance, which becomes emergency maintenance.
- Each near-miss adds a new "we should really fix this" item to the backlog, permanently inflating the run baseline.
- Teams that never audit the split assume they're roughly balanced, because the plan looked balanced — the actual rarely does.
Ron Yekutiel and various engineering-leadership studies on tech debt (Stripe's 2018 developer survey among them) put the median share of engineering time lost to debt and maintenance-adjacent friction at roughly a third — and that's before counting the run work teams correctly classify as legitimate keep-the-lights-on effort. The point isn't the exact number; it's that nobody assigned that third on purpose. It happened by accretion.
The Difference Between "Should Be" and "Is"
Most roadmap conversations happen entirely in the "should be" register — the intended split discussed at quarterly planning. Almost none happen in the "is" register — what capacity actually consumed last quarter, reconstructed from completed work. That gap is where the drift hides, and it's invisible until someone builds the audit (see the section below).
Defining the Three Buckets Without Ambiguity
Run, grow, and transform need crisp, teachable definitions or every team will classify its own work in the most flattering bucket. Run is work required to keep the current product operating at its current level; grow is work that improves outcomes for the product's existing job; transform is new bets outside the current scope.
| Bucket | Definition | Typical work | Failure mode if starved |
|---|---|---|---|
| Run | Keeps current functionality alive at current quality | Bug fixes, security patches, infra upgrades, on-call, compliance renewals | Outages, churn from broken trust, security incidents |
| Grow | Improves outcomes for the job the product already does | Conversion optimization, expansion features, performance, retention loops | Flat or declining core metrics; competitors out-execute you |
| Transform | New bets: new markets, new product lines, new categories | New product surfaces, adjacent-market pilots, platform bets | No future revenue engine when the current one saturates |
A few disambiguation rules that hold up under real prioritization pressure:
- If removing the work would degrade something that already works, it's run — even if it's technically "new" code (e.g., a migration off a deprecated API).
- If the work targets an existing metric for an existing job, it's grow — even if it ships a brand-new UI.
- If the work targets a job or segment you don't currently serve, it's transform — even if it reuses existing infrastructure.
- Tech debt paydown is run, not grow, unless the debt is actively blocking a specific growth initiative — in which case tag it to that initiative instead.
Getting this taxonomy right matters more than getting the target ratio right, because a fuzzy taxonomy lets every team self-report whatever ratio makes them look good. This is also where the framing differs sharply from an outcome-based roadmap versus a features roadmap — that debate is about how you describe the work; build/run/grow is about what fraction of capacity each description class consumes, which is a separate and, for capacity-planning purposes, more decision-relevant question.
Setting an Intentional Target Split
There's no universal correct ratio — the right split depends on product maturity, competitive pressure, and technical debt load, but most healthy SaaS products land somewhere near 20-30% run, 40-60% grow, and 10-30% transform. What matters is that leadership picks a number on purpose and states it out loud.
Use maturity stage as the primary input, not a copied benchmark:
| Stage | Typical run | Typical grow | Typical transform | Rationale |
|---|---|---|---|---|
| Early-stage, pre-PMF | 10-15% | 30-40% | 45-60% | Survival depends on finding the bet that works |
| Growth-stage, scaling | 20-25% | 50-60% | 15-25% | Compounding what's proven beats chasing new bets |
| Mature, defending share | 30-40% | 40-50% | 10-20% | Legacy surface area and compliance burden grow with scale |
| Declining or sunset-adjacent | 40-60% | 20-30% | 10-20% | Protecting revenue outweighs new investment |
Two caveats that experienced leaders learn the hard way. First, run below ~15% is usually a warning sign, not a win — it typically means maintenance is being deferred, not eliminated, and the bill arrives later with interest. Second, transform above ~30% sustained for multiple quarters tends to starve the core product of the polish that retains the customers funding the bets in the first place.
The target should be a board-level or leadership-level decision, revisited at most quarterly — not something each squad sets independently, or you'll get five different implicit ratios and no coherent company-level answer to "what are we actually investing in."
Tie the Split to Company Stage, Not Habit
A common failure is carrying last year's ratio forward unexamined because it's familiar, even after the company's stage has shifted — a team that just hit product-market fit but is still running an 80% transform ratio designed for the pre-PMF search phase is under-investing in the retention and reliability work that PMF now demands. Revisit the target explicitly whenever the company crosses a stage boundary, not just on the calendar.
Auditing Where Capacity Actually Went
The audit is the single highest-leverage habit in this whole framework: reconstruct last quarter's actual run/grow/transform split from completed work, then compare it against the intended target — the gap is your real story, not the plan you made at kickoff. Most teams never do this because it feels like paperwork; it's actually the fastest way to see the firefighting drift described above.
A simple four-step audit, doable in one afternoon per quarter:
- Pull every shipped item from the last quarter — tickets, PRs, or roadmap entries, whatever your system of record is.
- Tag each item run/grow/transform using the disambiguation rules from the previous section. When in doubt, tag conservatively toward run (it's the bucket people under-report).
- Weight by effort, not item count — ten one-day bug fixes and one three-week platform migration are not equal "run" contributions; use story points, days, or whatever estimate you already track.
- Compare the actual percentage split against the intended target and name the gap explicitly in the next planning cycle, rather than letting it silently reset.
A worked example makes the gap concrete:
| Bucket | Intended target | Actual (reconstructed) | Gap |
|---|---|---|---|
| Run | 25% | 41% | +16 pts |
| Grow | 55% | 44% | -11 pts |
| Transform | 20% | 15% | -5 pts |
That 16-point overshoot on run is where the quarter's growth ambitions actually went — not to a bad decision anyone made in a meeting, but to the accumulated weight of unscheduled fixes that each individually felt justified. Naming it is the entire intervention; teams that see the number in writing tend to correct it the next quarter without further argument.
This audit habit pairs naturally with the honesty practices in communicating roadmap uncertainty — both are about replacing a comfortable fiction (a confident-looking plan, a tidy intended ratio) with the messier, more useful truth of what's actually happening.
Making the Split Visible on the Roadmap Itself
The investment mix should be legible directly on the ranked roadmap, not buried in a separate spreadsheet nobody opens between planning cycles. If every item on a prioritized list carries a run/grow/transform tag, the implied allocation is just a rollup away — and stakeholders can see it without asking.
This is a natural, honest use for Prodinja's Prioritization workspace: each backlog item can be tagged as run, grow, or transform alongside its RICE or Kano score, so the ranked roadmap that comes out the other end makes its real allocation visible rather than implicit. Seeing that a top-10 ranked list is actually 60% run, when leadership assumed 30%, tends to be a more persuasive argument for rebalancing than any slide deck.
Making the split visible also changes how roadmap conversations with stakeholders go. Instead of defending individual features one at a time, a product leader can point to the aggregate mix and ask the more useful question: is this the ratio we actually meant to fund? That's a much more productive framing than treating every stakeholder ask as an isolated negotiation — a theme covered in more depth in the complete guide to roadmapping.
Where This Intersects With Now-Next-Later
Teams already using a now/next/later structure for roadmap honesty can layer the run/grow/transform tag directly onto each column. A "now" column that's 70% run isn't dishonest, but it is informative — it tells stakeholders that this quarter is a stabilization quarter, which is a very different message than "we're focused on growth" delivered with the same roadmap format.
Common Ways the Investment Mix Goes Wrong
Most investment-mix failures aren't caused by a bad target ratio — they're caused by the target never being checked against reality, or being set by the wrong altitude of decision-maker. Three patterns recur often enough to name specifically.
- The silent creep: no one ever set a target, so there's nothing to be off from — the mix is whatever emerged, and it's rarely examined until a growth metric stalls and someone asks why.
- The squad-level fragmentation: each team sets its own informal ratio, so the company-level number that matters to the board doesn't exist anywhere, and no one can answer "what are we actually investing in" with a straight number.
- The transform mirage: leadership believes the ratio is healthy because the roadmap narrative emphasizes big bets, while the audit (if anyone ran it) would show the actual capacity went overwhelmingly to run — the story and the ledger disagree.
Each of these is fixable with the same medicine: one explicit target, set at the right altitude, checked quarterly against reconstructed actuals. None of it requires new headcount or tooling sophistication — it requires the discipline of actually running the audit and saying the number out loud in the room where the next quarter gets planned.
A related trap worth naming: teams sometimes assume that because a feature serves an existing customer job, it must be "grow," and skip checking whether the job itself has evolved. Revisiting the underlying job — using something like the complete guide to jobs-to-be-done — before tagging a feature as grow versus transform prevents misclassifying a pivot as an incremental improvement, which quietly hides a much bigger strategic bet inside a "grow" label.
Key Takeaways
- The investment mix is a decision, not an emergent property — unexamined, it defaults toward run because maintenance escalates itself and growth work has to be argued for every cycle.
- Build/run/grow answers a different question than three horizons — it's about capacity allocation right now, not payoff timing, and the two frameworks shouldn't be conflated.
- A crisp taxonomy matters more than the exact target ratio — without clear disambiguation rules, teams self-report whatever split makes them look best.
- Set the target ratio at leadership altitude, tied to company stage — a pre-PMF startup and a mature SaaS company should not share the same run/grow/transform split.
- Audit actuals every quarter and compare against the intended target — the gap between plan and reality is the real story, and most teams never look at it.
- Making the split visible on the ranked roadmap itself, not in a separate spreadsheet, turns an abstract policy into something stakeholders can see and question directly.
Frequently Asked Questions
What's the difference between build/run/grow and the three horizons model?
Three horizons categorizes work by time horizon — near-term, medium-term, and speculative future bets. Build/run/grow categorizes work by what kind of capacity it consumes right now — maintenance, improvement, or new bets — regardless of when any of it pays off. A horizon-1 item can be run, grow, or transform work; the two frameworks are orthogonal, not synonyms.
What percentage of the roadmap should go to maintenance versus growth?
There's no universal number, but most healthy, growth-stage SaaS products land near 20-30% run, 40-60% grow, and 10-30% transform. The right split depends heavily on company maturity, technical debt load, and competitive pressure — the important step is picking a deliberate number for your stage, not copying someone else's benchmark verbatim.
How do I audit where my team's capacity actually went last quarter?
Pull every shipped item from your tracker, tag each one run/grow/transform using clear disambiguation rules, weight by effort rather than raw item count, and compare the resulting percentages against your intended target. Most teams discover the gap is larger than expected, especially on the run side, because maintenance work accumulates quietly across a quarter.
Is technical debt paydown run work or grow work?
Tech debt paydown is almost always run work, since it restores the product to its current intended quality rather than improving outcomes for an existing job. The one exception is debt that's actively blocking a specific growth initiative — in that case, tag the paydown to that initiative's grow bucket instead of the general run bucket.
How often should leadership revisit the investment mix target?
Revisit the target at least quarterly, and always immediately after the company crosses a meaningful stage boundary — hitting product-market fit, entering a new competitive phase, or absorbing a wave of technical debt from rapid scaling. Carrying last year's ratio forward out of habit, after the underlying stage has shifted, is one of the more common ways teams under- or over-invest without noticing.