Your platform teams spend 60% of their time keeping production up and 2% opening their components to the teams that wait on them. That was the measurement one VP of Engineering brought me, and the exec deck built on it had no money in it. Here is the business case we built instead: where the capacity goes, what the quarter costs, when it comes back, and the one task you measure before you bet the org.
"We shipped more features this year than last year. I didn't see the revenue." That was the head of product's answer when Tomáš, a VP of Engineering, promised his exec team three times the throughput. A platform team business case is the ask that survives that answer: one quarter of roadmap capacity, shown coming back within three, in money.
Tomáš (not his real name) runs engineering at a B2B SaaS company. His platform teams spend 60% of their time keeping production up, 2% making their components open to other teams and 38% building features. The product teams can't move without them, so every cross-team initiative waits in someone's queue.
His deck was good. Dependencies drawn as spaghetti, autonomous teams, a 3x target. Every number on it was a percentage.
One slide was missing, and I told him so. There wasn't a single dollar in the deck. Stripe's Developer Coefficient found developers spend 17.3 hours of a 41.1-hour week on maintenance, bad code and technical debt. Your exec team already pays that bill, so show them the invoice.
Boards fund a payback date
Ask ChatGPT how to get a platform team funded and it tells you to "stop selling it as an engineering improvement and start selling it as a business investment". Right, and not enough. An investment without a date is a wish.
So say the date. "Give me half of Q1. You'll have it back by the end of the year, and from then on we run faster." You're not scratching at the door for platform time, you're a VP selling an investment.
A percentage invites a negotiation about the percentage. A payback date invites a decision, and the decision belongs to the people in the room. That's where you want it.
The bill is big enough to carry it. CIOs told McKinsey that 10 to 20% of the technology budget meant for new products gets diverted to tech debt.
Tomáš got lucky. His CEO had his own "the train is leaving without us" moment the weekend before the offsite and was ready to break the roadmap. But a mandate doesn't come from one hour of talking, and the payback slide is what you keep coming back with. At Mews and at the companies I advise since, I've watched that fight take half a year to a year before people get it: you're not selling a slower roadmap, you're speeding up the company.
Measure where the capacity goes before you ask for any of it
You can't sell a payback date on a guess about today. The first slide shows where the time goes now, and the numbers have to come from the teams, not from you.
Five buckets, planned or unplanned
Split every team's time into roadmap work, platform investment, reactive production work (incidents, on-call, hotfixes), customer escalations and help for other teams. The first two are planned, the last three mostly aren't. The unplanned share is your headline number: it's how much room your teams really have for the roadmap.
No timesheets
Each team lead splits their team's person-days into the five buckets. Fifteen minutes, ±10% is enough. Run it for two weeks as a pilot, then switch to a rolling six weeks, because one big incident skews two weeks completely.
Tag who asked
Next to every bucket, write which division asked for the work. Now capacity becomes a budget you can hand out: "Your division has 400 person-days this quarter, you decide what goes in." A new request becomes a trade, and the fight over priorities moves to the people who own the priorities.
Turn days into money
Person-days times the fully loaded cost of a day. That's the number a CFO reads. If you've never priced an engineering decision for an executive, I wrote up the smaller version of this in how to talk to executives.
Here is what Tomáš's measurement and target looked like. These are one real company's numbers, anonymised. The product-team target is a target, not a measurement.
| Team type | Work | Today | Target |
|---|---|---|---|
| Platform teams | Keeping production running | 60% | 30% |
| Platform teams | Opening components to other teams | 2% | 50% |
| Platform teams | Customer-facing features | 38% | 20% |
| Product teams | Keeping production running | 35% | 10% |
| Product teams | Changes in the platform (via contribution) | 3% | 10% |
| Product teams | Customer-facing features | 62% | 80% |
Look at the bottom row. The product teams already spend 62% on features.
What holds them back is the 35% they spend looking back at production and the queue they stand in for the platform. More feature capacity is a side effect of removing that. If you want an outside read on where your teams' time goes before you build this slide, that's what an engineering productivity audit is for.
Your platform team should build features last
Tomáš's priority order for platform teams is production first, opening the components second, features last. 30% production is the desired share, not a cap: when production burns, production wins.
The platform-team flip Tomáš asked for. Today's 2% on opening components isn't drawn.
Why features last? Ten autonomous teams that all need the same five people in the shared core aren't ten parallel streams. They run fast for a few weeks, then they wait on reviews, questions and dependencies again.
The queue only moved. DORA's research calls this "downstream disorder": gains in coding speed get swallowed by bottlenecks in testing, security review and beyond.
Own 10%, open 90%
A small set of components stays owned end to end: authentication, authorization, privacy, the things where you want to be careful. In Tomáš's plan that's about 10% of changes. The other 90% become "owned, but open": the owner decouples, documents, writes down the intents and limits, adds tests, and builds safe paths so any team can contribute without breaking the core.
The 90/10 rule: 90% of changes flow through open components.
Contribution runs both ways
Product teams change the platform when they need to. Platform teams change product code when production needs it, for example when something falls over or can't keep up on performance. Both sides have to be fine with someone else in their code. Years of strong ownership at Tomáš's company grew red tape around every component, and he wants 90% of it gone.
Don't build for the drawer
No capability "because it might come in handy in three years". Build what a team needs now. The platform follows where the product teams go, it doesn't run ahead of them.
Measure the platform by how fast the others run
Platform teams get measured by how much faster the product teams ship, not by what they built. That's the Team Topologies idea of a platform team in practice: an internal product that exists to speed up the stream-aligned teams. If you want the role itself explained, here's the platform engineer role.
The counter-voice deserves a fair hearing. The 2024 DORA report found a 6% gain in team productivity with a dedicated platform team, and an 8% drop in throughput among those using a platform. A platform done badly slows you down, which is exactly why you measure it by the other teams' speed and prove it on one task first.
Turn the percentages into money: the one-for-three slide
This is the slide Tomáš didn't have. Three numbers make it.
What the quarter costs
Person-days moved off the roadmap times the loaded day cost. That's your investment, in money.
When it comes back
The roadmap output you lose in the investment quarter against what you gain after it, quarter by quarter, until the running balance turns positive. Expect the teams to slow down, or nearly stop, for about two months while they adopt new tools and a new way of working. Say it out loud on the slide: slow down to get faster later.
Don't guess the speed-up. Take it from the pilot (next section): whatever the benchmark task shows at the first read is your Q2 number, and you don't extrapolate further than the pilot proved.
What it's worth
Your CPO should know how much revenue you generate every quarter and how much of it is attributed to new functionality. That's your price per quarter of roadmap. Put the result on the slide as a hypothesis, and still put the number there. That's when people stop debating whether to allow it.
Here's the shape, with numbers made up for this post (illustrative, not Tomáš's). Output is in "today's quarters", where 1.0 is a quarter like the current one, and $3M a quarter of revenue comes from new functionality.
| Quarter | Roadmap output | Running balance | Extra revenue vs today, if adoption holds |
|---|---|---|---|
| Q1, investment | 0.5 | −0.5 | −$1.5M |
| Q2 | 1.2 | −0.3 | +$0.6M |
| Q3 | 1.4 | +0.1, break-even | +$1.2M |
| Q4 | 1.6 | +0.7 | +$1.8M |
One quarter in, three to get it back: by the end of Q4 you're 0.7 quarters ahead, about $2.1M. If year two holds the Q4 speed, that's 0.6 extra quarters of output each quarter, about $7.2M a year.
Read the last column header again. "If adoption holds" is the head of product's objection, written onto your own slide, and it's why the next section exists.
Reliability and security work gets a revenue number too. Jade Rubick's ValueSum scores a delivered item so that 100 points means adding 100% ARR over one year, multiplied by the probability of success. His reliability example, step by step:
| Step | Score |
|---|---|
| A third of customers at risk of churn from this instability | 33 |
| They skew large, so it's really about 45% of revenue | 45 |
| Real churn risk per customer about 20%: 45 × 20% | 9 |
| Reputational damage doubles it: 9 × 2 | 18 |
Rubick also gives you the argument for a standing platform share instead of a fight per project: "a certain percentage of every engineering organization should be focused on things that make the organization more efficient over time", because that work "will typically get shortchanged" if you only optimise for value delivered.
"We shipped more and revenue didn't move" is the right objection
The head of product was right. That we speed up the machine doesn't mean we'll deliver the right things at that speed. Pendo's feature adoption report found that 80% of features in the average software product are rarely or never used.
So the business case needs a second owner. I told Tomáš what we did at Mews, where I grew engineering from 8 to 80 teams as VP of Engineering. My KPI, the one I was known for: every quarter I delivered at least 80% of the roadmap. If I didn't deliver, they could fire me.
I tracked it as roadmap contribution: what percentage of my teams' time goes on the roadmap as opposed to off it. Two teams working off the roadmap for whatever reason put the whole quarter at risk. I taught my leaders the rule I lived by: if you don't bring me the roadmap, I have a problem too.
My product peer had another KPI. "Thank you, Marian, for building me a fast machine. But I have to throw things into the machine." His job was to feed my roadmap with things that matter, measured as product adoption, and we set it up on purpose so we'd be twins in a pair.
A faster machine sells nothing on its own. Somebody has to own what goes into it.
Every initiative was locked in a quarter and had a custom field in Jira with its adoption grade. I'll admit it, we graded by hand, there was no automated metric:
| Grade | What it means | Counts toward 65%? |
|---|---|---|
| Ultra-high | It makes us a lot of money | Yes |
| High | As expected | Yes |
| Neutral | It earns back what it cost: people, licences, infrastructure | No |
| Disaster | It doesn't earn back its cost | No |
| To be evaluated | Too early to grade, allowed for one quarter at most | No |
Timing is part of a good product decision, so nothing stays ungraded longer than a quarter.
I had 80% roadmap delivery. The product leader next to me had 65% product adoption, meaning high or ultra-high. Waiting doesn't count, because waiting doesn't generate money.
And honestly, we yelled at each other. "I'm holding a fast roadmap for you, and you're throwing junk into it? Then my people are unhappy and somebody leaves."
Sometimes I said a thing didn't belong on the roadmap. Sometimes he wanted to label something a success and I said, that's probably not a success. But now you have valid discussions, about value.
Rubick lands in the same place from the other side. He recommends re-scoring every feature three or six months after delivery and keeping both the predicted and the retroactive score. Two more rules from that work I'd copy: product or division leaders score the value, not engineering, and you don't use the score to rate individuals or teams.
Tomáš couldn't get an adoption KPI agreed at the top yet, so his version of the twin sits one level down: every autonomous area gets a product manager and an engineering manager who own one business outcome together. The pair should exist on every level, team, director, VP, CTO and CPO. If you're an engineering director setting this up below the VP, your product counterpart is your twin.
Prove it on one task before you ask for the whole org
Tomáš wrote a small code change himself, his first in two years. It should have taken three hours. Reviews, pipelines and information he couldn't find about how the change would hit customers turned it into a day of development, and gating turned the rollout into a week.
That task became the benchmark:
| Benchmark task | Today | End of the pilot | Long term |
|---|---|---|---|
| Develop | 1 day | ~4 hours | 2 hours |
| Roll out | 1 week | a couple of days | 2 hours |
For the pilot he set one target. By the first read, 60% of the friction points on that task's path get better. Each one is small, an hour here, half an hour there, fifteen minutes somewhere else.
If your teams work with AI agents, the friction list includes what the agent can't do: see a slow endpoint before a customer does, know the product history, run a dev instance, observe the deployment.
Pick a quiet team for the pilot
Tomáš started with a team that had a light roadmap, so the pilot wouldn't kill the plan. You need a reference before you need a transformation.
Lend it a tooling SWAT
A small tooling group builds what the pilot team can't build itself: feature flags, faster pipelines, whatever the friction list asks for. After the pilot, the SWAT becomes a regular team with more people.
Cut the areas to the leaders you have
Tomáš cut his candidate outcome areas for autonomous teams from 18 to 5. Each area needs a strong engineering leader and a strong product leader, and five pairs is what he has. The existing leaders own fewer, broader areas, with no new leadership layer.
The six slides, and what I'd add
Here's the deck I'd want Tomáš to walk in with. Each slide answers one question an exec will ask anyway.
| Slide | The question it answers | What's on it |
|---|---|---|
| 1. What today costs | Where does our engineering money go? | Capacity split, unplanned share, in money, by requesting division |
| 2. Why we're slow | Why don't more people make us faster? | The shared components every team waits on |
| 3. The contract | What will teams spend time on instead? | Target split per team type, the 90/10 rule, reported every sprint |
| 4. The trade | What do we give up, and when does it come back? | Cost of the quarter, running balance, revenue if adoption holds |
| 5. The litmus test | How do we know before betting the org? | Benchmark task, pilot team, date of the first read |
| 6. Who owns the outcome | Who makes a faster machine earn? | Delivery KPI, adoption KPI, named owners, grading scale |
I put the outline, a capacity sheet and a payback sheet into a free kit: download the platform business case kit (16 KB zip: Markdown, Word and three CSV sheets, no email needed).
Bring a proposal, not only a photo. A snapshot alone invites "why so much on support?" and then someone else decides. Let your directors collect the data; your job is to interpret it and propose one change.
Report the contract against reality every sprint. Every quarter my 100% was split into three agreed boxes, product, tech and everything else, and I checked them each sprint. When the delta grows, the right call is sometimes paradoxical: stop the technical work for two sprints and do product work, to get the balance back.
And the hard part comes after the yes. Not everyone will make the switch, either because they don't take ownership or because they can't work in a pair and are big egos. A few of them will have to leave.
Tomáš walked out with agreement to start the pilot. Its first read is still ahead, so I can't show you his benchmark numbers yet; when it reads out, I'll add them here. What will your exec team say when you ask for one quarter and promise three back? If you want to build that slide together before you present it, that's what my CTO mentoring is for.
Originally published at marian.coach on 1 November 2026. Czech version: Business case pro platform engineering. Polish version: Platform team business case.
Marian Kamenistak mentors engineering leaders 1:1 and ran engineering at Mews as VP of Engineering, from 8 to 80 teams. Names and company details in this piece are anonymised.
Top comments (0)