Does Your Capacity Actually Match Your Growth Plan?
A board meeting I sat in on a few years ago, advising the chair. The CFO walked through the value creation plan. Forty per cent ARR growth over three years, built on a pipeline of new-customer acquisition, existing-account expansion, and the launch of a second product line. The board nodded. The slides were beautiful. Everyone left the room satisfied.
The CPO and I went back to her desk and opened the roadmap. Twelve squads. Twenty-six two-week sprints. I asked her to walk me through how that capacity was actually allocated, objective by objective, for the coming year. (The simplest thing that can possibly work is Run / Grow / Transform so we bucketed the objectives that way).
About an hour later we had a breakdown. Seventy per cent of the capacity was allocated to Run work — keeping the existing product stable, maintenance, compliance, bug fixes, platform-team load. Twenty-two per cent was allocated to Grow — improvements to the current product line that were genuinely aimed at new customers or expansion, the kind of work that moves the activation and retention levers the CFO’s model depends on. Eight per cent was allocated to Transform — the new second product line the entire growth plan depended on.
Eight per cent. The business plan the board had just signed off required a second product line to carry a meaningful chunk of the three-year growth. The engineering organisation was devoting eight per cent of its capacity to it. The two numbers could not both be true. Somebody — the CFO, the CPO, the board — was about to find out that the plan they had just committed to was not a plan. It was a hope.
Your engineering capacity matches your growth plan when the share of capacity allocated to each strategic pillar supports the share of revenue that pillar is forecast to deliver. If the board plan puts 40% of growth on a new engineering-heavy product line and engineering allocates 8% of capacity to it, the plan is (probably) fiction. The reconciliation is a simple sum — and almost no organisation actually does it.
This is precisely the question RoadmapOne was built to answer. Every objective can be tagged by the growth pillar(s) it serves — Run / Grow / Transform, innovation ambition, product line, SVPG risk, or the company’s own “we will win by” pillars (every organisation has one of these lists, even if they don’t all write it down). Every objective allocated to specific squads and sprints. And — at any moment, in any board meeting or diligence room or quarterly review — an analytics view that tells anyone in the room what share of capacity is actually backing each pillar. Either the numbers support the growth plan and the board can sign off with confidence, or they don’t — in which case a specific, bounded, decidable conversation opens up about what has to change: the growth plan, the resourcing, the allocation across pillars, or some combination. That discussion is the one every board should be having and almost none of them currently are.
The arithmetic nobody does
This is the single most common failure mode I see in private-equity due diligence, and it’s the reason I was eventually persuaded to build RoadmapOne . Every business has a top-down view of where it is going — revenue waterfalls, growth pillars, strategic themes, OKRs, board commitments. And every business has a bottom-up view of what its engineering and product organisation is actually going to build — roadmaps, squad allocations, sprint plans, backlogs. The two views are authored by different people, presented to different audiences, lived in different rooms. And almost nobody does the reconciliation.
Bottom-up allocation of resources has to match top-down growth assumptions. If it doesn’t, one of the two is fiction, and the one that is fiction is almost always the one that didn’t get audited by the engineering capacity grid.
The reconciliation is not complicated. It is a sum on the back of a napkin. You take every objective on the roadmap, you tag it by which growth pillar it serves, and you add up the capacity allocated to each pillar. Then you compare that allocation to the revenue contribution each pillar is forecast to make in the business plan. If the business plan has Pillar A delivering 60% of the growth and Pillar A has 10% of the engineering capacity, something is probably wrong, and the sooner the business discovers which, the cheaper the fix is. In RoadmapOne that sum is a single click on the analytics view; in a spreadsheet it’s a pivot table nobody maintains; in most organisations today it is not done at all.
The reason this arithmetic doesn’t get done isn’t that it’s hard. In 90% of organisation, the inputs live in Powerpoint, the outputs are framed in different units, and the two teams who need to reconcile them — finance and product — speak slightly different languages and rarely sit at the same table. The finance team doesn’t know how much capacity is going to Pillar A. The product team doesn’t know what share of the revenue plan Pillar A is carrying. Both teams assume the other has done the sum. Neither has.
What the sum actually looks like
Let me walk through it properly. Suppose you run a mid-sized SaaS business with twelve product squads. Over a year, that’s 12 × 26 = 312 squad-sprints of theoretical capacity. Take off holidays, conferences, training weeks, and unavoidable keeping-the-lights-on work , and you’re looking at maybe 280 squad-sprints of actual available capacity. That 280 is the real number. It’s the entire delivery capability of the organisation for the year, expressed in units you can do arithmetic with.
Now tag every objective on the roadmap by (say) Run / Grow / Transform :
- Run — keeping the existing business safe and functional. Compliance, reliability, performance, bug fixes, regulatory updates, platform maintenance.
- Grow — improving the existing product in ways that drive more revenue from the current business model. Conversion improvements, retention improvements, feature expansions, pricing experiments.
- Transform — building something genuinely new. A second product line. A new market. A platform rebuild. Anything where the business model of the new thing is materially different from the existing one.
Sum the squad-sprints by tag. You’ll get three numbers that add up to 280. In a typical mid-sized SaaS business I’ve looked at in diligence, it often comes out something like 65% Run, 25% Grow, 10% Transform. You can now ask the real question: does this allocation match the shape of the business plan?
Take the plan that was just signed off by the board. Where is the growth coming from? If the plan assumes 40% growth is largely carried by expansion of the existing product (a Grow-heavy plan), then the 25% Grow allocation is probably in the right ballpark and the sum makes sense. If the plan assumes a big chunk of growth comes from a new second product (a Transform-heavy plan), then 10% Transform is wildly insufficient, and either the plan is going to miss or the roadmap needs a fundamental re-allocation. The reconciliation exposes the lie before the quarter does.
The PE diligence version
Part of what I do now is due diligence on product and engineering organisations on behalf of private-equity firms. The sum I’ve described above is the first piece of analytical work I do in every diligence, and I can do it on the back of a napkin in about twenty minutes if the roadmap is reasonably structured. I’ve killed three investment theses in the last five years doing exactly this sum.
A common pattern is this: the growth plan assumes a Transform-heavy mix, but the engineering allocation is Run-heavy, because the codebase has accumulated enough technical debt that a substantial share of capacity is tied up maintaining it. The board believes the growth plan because it was authored by the CFO. The CFO believes the growth plan because the CEO signed it. The CEO believes it because it came out of the strategy offsite. Few in the chain believe it enough to go and look at the roadmap and do the sum.
Once you’ve done the sum, the conversation changes. It is no longer about whether the plan is ambitious enough. It is about whether the plan is deliverable given the current shape of the roadmap, and if not, what specifically needs to change — cut Run work, defer Grow work, hire or reallocate capacity, lower the growth target, shift the mix between pillars, or some combination. These are concrete, bounded decisions the board can actually make. Without the sum, the conversation tends toward handwaves and optimism and the plan that quietly misses in Q3.
The invisible cross-subsidy problem
There’s a particular failure mode worth naming because it shows up regularly and almost never gets caught until it’s expensive: invisible cross-subsidy between product lines.
A company has two products. Product A is the mature, cash-cow product. Product B is the new, strategic-bet product the business is supposedly betting on. On paper, you’ve allocated four squads to Product A and three to Product B. In practice, Product A’s legacy problems keep pulling Product B’s engineers in to firefight, or the platform team — nominally shared — spends 80% of its time on Product A because Product A is where the incidents are. Three months into the year, Product B’s actual effective capacity is less than half what it was nominally allocated, and nobody has noticed.
The most reliable way to catch this is to do the reconciliation at objective level, not at squad level. Every objective is tagged with the product line (or growth pillar, or strategic theme) it serves. Every squad-sprint is tagged with the objective it’s working on. Running the sum exposes that the Product A / Product B split in practice is 80/20 rather than the 55/45 the board was told. Portfolio-level transparency, which most organisations don’t have without deliberate effort, is what RoadmapOne — and the broader argument for product portfolio roadmaps — is designed to provide.
Why tagging is the load-bearing primitive
This is the part of the article that is least about ideology and most about plumbing. None of the analysis above is possible without objective-level tagging. If you can’t pull up a view of “how much of FY26 capacity is allocated to Transform?” or “how much of H2 capacity is allocated to each of our three growth pillars?”, you can’t have the reconciliation conversation, and the business is flying on CFO trust alone.
That’s why this blog spends so much time on tagging frameworks. Run / Grow / Transform is a really great place to start — it maps cleanly onto the business’s tolerance for risk and its investment horizon, and it’s a language the board already speaks. RoadmapOne ships with more than twenty tagging methodologies out of the box, and crucially lets you define your own custom taxonomy to match the specific way your business talks about growth. Depending on the business, the tags that matter might include:
- Objective tagging frameworks — RGT, McKinsey’s innovation ambition matrix , SVPG’s four product risks , or a company-specific taxonomy like “the four growth pillars we brief to the board.” Each asks a different question about the portfolio.
- Product line tags — which product does this objective serve? Essential as soon as the business has more than one product.
- Strategic theme tags — which of the board’s top-level themes (e.g. “international expansion”, “enterprise readiness”, “platform consolidation”) does this objective advance?
- “We will win by…” pillars — the company-specific growth drivers the CEO and CFO brief to the board. Most organisations have one of these lists. Custom tags in RoadmapOne let the roadmap speak back to the board using exactly that vocabulary.
- Key Result tagging — is this objective’s measurement leading or lagging , qualitative or quantitative , addressing which risk ?
The common thread is that every tag turns the roadmap into a set of numbers the CFO can do arithmetic with. That arithmetic is what the business actually depends on. Without it you have a roadmap that looks organised and a business plan that looks ambitious, but no proof that either one is real. RGT is the starting point; the goal is to get to the tag set that lets the roadmap answer the exact question your board is asking.
What RoadmapOne was built to do
A short product-origin note, because this particular article is where it actually belongs. When I was CTO at Trainline during the years Cagan describes in Transformed, we built an internal tool we called the WIP Wall — a spreadsheet that held every squad’s allocation against every sprint for the year, with each cell tagged by the objective it was serving. At any given moment I could run a pivot and tell the CFO, or the board, or anyone who asked, what proportion of engineering capacity was going to which strategic theme, which product line, which Run/Grow/Transform tag.
That tool is the direct ancestor of RoadmapOne. The product was built because I wanted the next CPO and CFO I ran into — and I ran into a lot of them, in diligence — to be able to do the same arithmetic without writing their own spreadsheet and maintaining it themselves. Being able to prove (or at least see and discuss) that capacity is allocated to the right growth initiatives is literally the raison d’être of the product. The grid × tagged-objectives × analytics architecture is the implementation of the argument this article is making.
If the rest of the blog is the theory, this is where the product sits on top of it — not as a pitch, but as the productisation of the arithmetic.
Three patterns worth checking for
Once you can run the capacity-by-objective sum — and in RoadmapOne it’s a filter-and-stack view you can pull up live in the meeting — three patterns tend to come up repeatedly, and each of them is diagnostic of a specific class of problem.
All Run. The business has quietly settled into a maintenance posture. Run work is 80%+, Grow work is small, Transform is near zero. The board often doesn’t know this. The CFO is still projecting growth. The diagnosis, more often than not, is technical debt — the codebase has accumulated enough friction that the team struggles to deliver change at meaningful pace. The fix tends to be a serious conversation about either platform investment or managed decline. This is also the shape of a business that can quietly turn into a feature factory of micro-improvements on a stagnating core — lots of motion, no compound effect.
All Grow, nothing Run. The reverse. The business has been chasing new growth so hard that reliability and platform work has been starved. This is the business that often suffers a major outage in month nine, spends the next quarter firefighting, and watches the growth plan miss. Run work is boring but it is also the foundation everything else sits on, and the right response when it’s been starved is usually a deliberate firebreak sprint rather than another promise to “do tech debt next quarter.” A capacity sum that shows less than 30% on Run in a mature software business is usually a warning, not an achievement.
Transform-heavy without customer traction. Large shares of capacity allocated to new products, platforms, or markets — and the revenue line for those bets still flat. This is the unfocused-innovation pattern. The organisation is pursuing many new things and committing to none of them hard enough to produce real customer adoption. The fix often looks like killing two of the three Transform bets and doubling the capacity on the one with the clearest traction. Until that happens, the business is funding optionality it probably cannot afford. (The companion article on side-of-desk work goes deeper into this failure mode.)
The conversation this enables
The actual reason to do any of this is that it enables the conversation the business should have been having all along, between the CFO and the CPO , with the CEO or chair in the room.
“Here is the business plan. Here is the capacity allocation that currently backs it. Here is the gap. Here are the decisions you can make to close the gap — change the growth plan, change the resourcing, change the mix between pillars, or some combination. Pick.” That is a grown-up conversation about reality. It replaces the far more common conversation, which is an exchange of optimism between people who are each assuming the other has done the sum. The sum is the difference between a plan and a wish. In RoadmapOne that sum is always one filter away; the point of the product is to put it in front of the board before the conversation starts, not after the quarter misses.
This is the same thesis that underpins why users do not experience averages and why presenting point-in-time numbers to a board is lazy : leaders can only have grown-up conversations about the business if the data they are looking at is honest enough to support one. The capacity-by-objective sum is the roadmap version of that same principle. Without it, the board meeting is theatre. With it, the board meeting is finally doing the job.
Frequently asked questions
What is Run, Grow and Transform in capacity planning?
Run, Grow and Transform is a portfolio lens applied to a product or engineering roadmap. Run work keeps the existing business safe and functional — reliability, maintenance, compliance, bug fixes. Grow work improves the existing product in ways that produce more revenue from the current business model — conversion lifts, retention improvements, expansion features. Transform work builds something materially new — a second product, a new market, a platform rebuild. Tagging every roadmap objective by RGT, and summing squad-sprints under each tag, produces a portfolio-level view of where engineering capacity is actually being spent.
How do you measure engineering capacity?
In squad-sprints. A squad-sprint is one squad’s effort for one sprint. For a year of two-week sprints, each squad has 26 squad-sprints of theoretical capacity. Subtract holidays, conferences, essential keeping-the-lights-on work, and unavoidable platform load, and you typically arrive at around 22–24 squad-sprints per squad of deliverable capacity. Multiply by squad count and you have an organisation-wide number — usually in the 250–300 range for a mid-sized SaaS business — that you can use to do real arithmetic.
What is the top-down / bottom-up approach to planning?
Top-down planning starts with business outcomes — the revenue plan, the growth targets, the strategic pillars the board has signed off — and asks what must happen beneath them. Bottom-up planning starts with the reality of teams, capacity, and current commitments, and asks what is actually deliverable. The reconciliation between the two is the honest plan. Either side in isolation produces either fantasy (top-down without capacity check) or timidity (bottom-up without strategic ambition). The mature artefact is a roadmap where both views reconcile, tagged by objective so the math is auditable.
How do you allocate engineering capacity to business growth?
Tag every objective on the roadmap by the growth pillar it serves — Run / Grow / Transform, or a company-specific taxonomy like “international expansion,” “enterprise readiness,” “new product line.” Allocate each objective to specific squads and sprints. Sum the squad-sprints under each tag to produce a capacity allocation percentage per pillar. Compare that percentage to the share of forecast revenue each pillar is expected to deliver in the business plan. If they diverge materially, the plan and the roadmap are out of sync and one of them needs to change.
Why do capacity plans and growth plans diverge?
Because they are authored in different rooms. The CFO builds the revenue waterfall from the top down and presents it to the board. The CPO builds the roadmap from the bottom up and presents it to the product organisation. Both documents look healthy in isolation. Neither team does the reconciliation arithmetic, because the inputs live in different tools and the outputs are framed in different units. The fix is a shared artefact — a roadmap where capacity is tagged by objective and can be summed by whichever pillar the board cares about — and a standing working session where CFO and CPO actually compare numbers.
The honest number is the one you can explain
The most useful test for whether your capacity is allocated correctly against your growth plan is this. If your board asked, right now, “what percentage of FY26 engineering capacity is allocated to [strategic pillar X], and can you show us the squads and sprints that make up that number?”, could you answer? In minutes, not weeks?
If the answer is no, you have a document rather than a roadmap. A roadmap is the artefact that reconciles top-down strategy with bottom-up capacity; everything else is a list. RoadmapOne is the productisation of that artefact, built specifically so the answer to the board’s question is always one filter away.
Bottom-up allocation has to support top-down growth assumptions. If it doesn’t, something has to change: the growth plan, the resourcing, the allocation across pillars, or some combination — and the board should be deciding that now, on purpose, rather than discovering it in Q3 when the quarter has already missed. The sum is the answer. The analytics view makes the sum available. The rest is a conversation.