“Go. What will it cost?” That was the CTO’s whole answer to the AI transformation pitch. Two days later the roadmap for next year was exactly the same size.
An AI business case, for a VP of Engineering, is a request for roadmap capacity. In the org I’m thinking of, about 100 engineers shrank to roughly 40 or 50 available for next year’s roadmap once production care and the AI work were counted honestly. The money question was answered in one sentence. The capacity question nearly killed the plan.
Let’s call the VP Tomas. He brought his deck to one of our sessions. The extra hires he’d planned for were gone, so the transformation had to be paid out of the roadmap.
His Head of Product agreed with the numbers on his slides. Their wishlist for next year didn’t lose a single theme.
The planning offsite is a few weeks away.
You’re asking for roadmap, not money
Tomas’s capacity slide showed how ~100 engineers shrink to the people left for new work. Engineers read it in five seconds. His Head of Product read it as engineering’s problem, not as a list of things to drop.
| Line | FTE | What it is |
|---|---|---|
| Engineering total | ~100 | Everyone on the payroll who ships code |
| Keep the lights on | 35-45 | Incidents, support, upgrades, the work that isn’t on any roadmap |
| Left after production care | ~60 | What a roadmap silently assumes is the whole team |
| AI team + transition dip | 10-20 | The people building the AI setup, plus the slowdown in streams while they switch |
| Left for next year’s roadmap | 40-50 | What product can plan with |
Ranges from one real engineering org, anonymised. Your numbers will differ, the shape won’t.
That table is the business case. The CFO question (“is it worth the money”) was cheap, because there was no new money. The real cost is that half of what product thought it could build next year doesn’t fit.
If you’re still hiring the person who will own this, my Head of AI transformation playbook covers the first six months of that seat. This post is about the sell before it.
It dies in your peer’s roadmap
The CTO’s yes is the cheap yes. The expensive one is your Head of Product’s, because they pay for it with their roadmap, and the pressure from above to deliver all of it lands on them first.
So they agree in the meeting and the roadmap doesn’t move two days later. That’s product denial, and from my experience it’s part of the development, part of the battle. It isn’t bad faith. It’s what a person does when the only thing on the table is a loss.
The standard advice points somewhere else. Oracle’s guide to the business case for AI, the top US Google result for “AI transformation business case” on the day I wrote this (12 November 2026), is about justifying AI investments “based on solid ROI calculations”, and its first step is an AI center-of-excellence committee. That’s the right case for a company buying software.
It wasn’t Tomas’s problem. The ROI wasn’t the question; the CTO had already said go.
The person whose roadmap pays for it hadn’t been asked anything.
Without an answer to “what’s in it for me”, they stay in denial. And from where they sit, that’s rational.
Say we, not you
When Tomas walked me through his deck, his message was “you need to cut your roadmap”. I stopped him there, because I’ve watched this exact sentence lose the room.
It’s not that I want you to cut your roadmap. It’s that we cut our roadmap together. The moment you start using “you” instead of “we”, you’re screwed.
I know it sounds stupid. It helped me enormously for the rest of my career.
I learned it at Mews, while engineering grew from 8 to 80 teams. In one quarterly planning I told our product lead: you need to drop two features so we can rebuild the platform. The rest of the hour went into defending both. Next quarter, same numbers on the slide, I asked which two we drop together. We agreed in fifteen minutes. You take the weapon out of the other person’s hands, because they no longer feel pushed into a corner.
The slide has to say it too. Tomas had one cut slide with a lot of small numbers about product areas. What I wanted to see is two numbers: product minus x percent, platform minus y percent.
In the example table further down that’s product −60% of the wishlist and platform −33%. The platform team sits under the VP of Engineering, so the second number is his own cut, visible, next to theirs. Now you’re playing the same game.
The seven slides, in this order
Tomas’s punchline, the gain, sat on slide 9. By slide 9 the Head of Product has spent eight slides hearing what they’re losing. Move it to slide 2.
1. The decision you need
One line: “We propose to fund the AI transformation from next year’s roadmap: product −x%, platform −y%, for a gain we both commit to.” The room knows from the first minute what it’s being asked to approve.
2. What’s in it for product
The payoff first. In Tomas’s model a stream that’s transforming drops to about 30% of its normal throughput for a few months, then comes back faster, with break-even around mid-year and roughly 3x by the end of the year. It’s a model, not a measurement, and slide 7 is where somebody commits to it.
The second card I gave him is a risk, not a gain: if we don’t do it, customers churn to competitors who ship the AI features first. Ask your sales or customer-success lead which deals already mention it.
3. Where the capacity really goes
The burndown table above. Colour it: what’s under the line red, what’s above the line green. Yes, it’s basic. You want people to understand it in five seconds.
4. We both cut
Product −x%, platform −y%, side by side. Nobody in the room should be able to say “engineering wants us to cut”.
5. Three ways to cut
Not just that we cut, but how: reduce the scope, stretch the timeline, or drop the item. To go one step further, give an AI model your roadmap list and the capacity table and ask it to propose what to delay or drop. Careful: it’s a proposal, not an order.
6. Cost of delay against the gain
Cost of delay is “a way of communicating the impact of time on the outcomes we hope to achieve”: what does each month without this cost us? Put that number on every item you’re stretching.
Then translate it into CFO language: yes, we slow down and it shows in 2027, and here is what 2028 and 2029 look like if the model holds.
7. What each of us commits to
The Head of Product commits to the option they picked, because they get the boost out of it. The VP of Engineering commits to the multiplier. Both commitments on the table, in writing. Without them the meeting is an opinion poll.
The capacity table, filled in
Here’s the table I asked Tomas to rebuild for the offsite, filled in for a made-up company so you can see the shape. Every name and number in it is invented.
| Product area | Planned FTE (wishlist) | Real FTE | % of plan | Proposal |
|---|---|---|---|---|
| Checkout | 9 | 4 | 44% | Keep, cut scope to the payment-provider switch |
| Search | 7 | 3 | 43% | Stretch, ship in Q3 instead of Q1 |
| Mobile app | 6 | 4 | 67% | Keep, trim to the top three features |
| Partner integrations | 8 | 2 | 25% | Drop two of five integrations |
| Reporting | 5 | 1 | 20% | Freeze, maintenance only |
| Platform (VP Eng’s own) | 12 | 8 | 67% | Cut the internal tooling rewrite |
Fictional company, illustrative numbers.
The column that does the work is ”% of plan”. In Tomas’s case one area’s real capacity came out at roughly a third of what product had assumed, because the earlier estimate missed production care and the AI dip. A percentage per area lets your Head of Product decide what to cut, which is the point.
Download the blank version: the AI business case template (zip, 3 KB) has the capacity table as a CSV for Excel or Google Sheets and the seven-slide outline as Markdown, with one example line per field that you delete.
Win the room before you walk in
Ask yourself one question first: how do you want the offsite to end? Go backwards from that.
Definition of success
The VP of Engineering and the Head of Product walk in as one team and say three things. This is the situation. This is our proposal, with one alternative and its impact. These are the initiatives we struck out, please challenge and confirm.
By the end the impact is clear and you have a mandate. Let’s be honest, two initiatives will still be argued about.
The pre-read
Amazon replaced slide decks with six-page memos read in silence at the start of the meeting. You don’t need to go that far. Send the seven slides plus one page of context two days before.
Put the full capacity table in it, so in the room you can say “don’t look at the table now, look at it later if you want”. Expect people to throw it into their AI tools to check your math. Good, let them.
Shuttle diplomacy
The term comes from Henry Kissinger’s 1974 rounds between Middle East capitals. Your version is cheaper: before the offsite, walk the proposal past each decision maker one by one and ask what would make them say no. Nothing in the room should be a surprise.
If you need your boss to take pressure off your Head of Product for the next two quarters, ask here, in a one-to-one, not in the meeting. How to influence your manager is the same muscle.
What I’d tell myself before the next offsite
Strong product leaders strike, weak ones stretch
A strong product person removes the items with the lowest value. A weak one makes compromises: we keep everything on the roadmap, because removing it looks bad, and we just stretch it all. Stretching one item with a new date is a decision; stretching everything is avoidance.
RICE, Intercom’s reach × impact × confidence ÷ effort score, is enough for this. Score the list and the strikes become obvious.
The strongest card is churn
“If we don’t do it, our financial results will hold” is the assumption to break. Your customers will get the AI features somewhere else.
So this isn’t about delivering something later. It’s about whether the company is still in the race in 2028.
The CTO’s yes is the cheap one
Tomas had the go from the top in one sentence. He’s rebuilding the deck around a peer, a table and two percentages, and the offsite is still ahead of him. The method is the bet; the room hasn’t voted yet.
Which of your peers owns the roadmap you’re paying with? If you want a second pair of eyes on the deck before your offsite, that’s exactly what my engineering director mentoring is for.
[Writing time: 3h]
