Most ROI Math Is Backwards. That's Why Your Strategy Doesn't Sell
- Elena Leonova
- Apr 28
- 4 min read
Monday morning. The proposal you've been polishing for three weeks is finally ready.
The deck is tight. The numbers check out. You've rehearsed the opening three times.
You walk in.
Slide one lands clean. You move to slide two.
The CFO leans back in his chair. The CRO picks up his phone. The founder asks a question that has nothing to do with what you just said.
You finish the deck anyway.
You walk out telling yourself the room didn't get it.
The room got it.
The room could smell that the ROI was reverse-engineered
You fell in love with the solution first.
Then you built the numbers to justify it.
That sequence is the tell. CFOs and board members run that pattern check in sixty seconds.
It's not a numbers problem. It's a sequence problem.
When you reverse-engineer ROI, the trail you leave looks like this:
You start from the solution you want to ship.
Then you go looking for a KPI it could plausibly move.
Then you size the lift until it clears hurdle rate.
Then you pick the time horizon that makes the chart look right.
By the time the proposal lands in front of the leadership team — or the memo lands in front of the board — it's internally consistent and externally hollow.
The room reads it before you finish the second slide.
Forward-built ROI starts somewhere completely different
It starts with the gap.
Not the solution you fell in love with. Not your team's capacity. Not the open slot on the roadmap.
The gap between where the business is and where the operating plan needs it to be by a specific date.
If you're a Director, the gap is the one your function owns inside this year's plan.
If you're a CPO, the gap is the one tied to the next funding round, the next earnings call, or the exit window.
The altitude changes. The starting point doesn't.
Once the gap is named, the next four sentences write themselves.
Which driver closes it. How much movement is required. What investment level produces that movement. When the signal arrives.
Written in that order, the proposal doesn't argue for the bet. The bet argues for itself.
Pull up your last document.
Read the first paragraph.
Did you start with the operating plan gap — or with the solution you'd already fallen in love with?
If it's the second one, you reverse-engineered it.
The room saw it. That's why it walked out of the room dead.
The deeper problem: most product leaders don't know what the operating plan is actually asking of them
You know the targets the company committed to. ARR, NRR, gross margin, payback period.
You don't know which of your bets the CFO — or the board — is counting on to hit which target.
So you write proposals that talk about your bets.
The room sits there trying to map your bets to their plan.
They can't.
That isn't a presentation problem. It's a strategy problem you haven't done yet.
You haven't built the bridge between what you're proposing and what the company committed to externally.
The reverse-engineered version skips six lines you never wrote down.
The forward-built version makes those six lines the spine.
Line one: the operating plan gap you're closing. "We committed to 24% NRR. We're tracking to 18%."
Line two: the driver under the gap. "Concentrated in expansion within enterprise accounts past month nine."
Line three: the magnitude required. "Closing it means lifting expansion conversion by 11 points in that segment."
Line four: your bet. "A workflow integration tier with a price test."
Line five: time-to-signal. "Leading indicator by week six. Lift by quarter end."
Line six: confidence band and risk. "60% confidence. The risk is integration depth on the customer side."
The room funds line six.
Not the demo. Not the strategy slide. Line six.
Same bet. Two versions. Different fate
The version you've probably sent:
"We're building a workflow integration tier. It will increase ARR by $4M and improve NRR. We need three engineers and a designer. Six months."
The version that gets funded:
"We committed to 24% NRR. We're tracking to 18% on enterprise expansion past month nine. The gap is integration friction at the workflow layer. A tiered integration with price differentiation is the highest-confidence bet to close it. Lift signal at week six. Required investment: four headcount, six months. Confidence: 60%. Risk-weighted return: $2.4M against an $800K cost."
The first is reverse-engineered. The numbers are clean. It still won't get funded.
The second is forward-built. Same bet. It gets funded because the gap is real, the driver is named, and the confidence band is honest.
The leadership team doesn't fund features. The board doesn't fund roadmaps.
Both fund gaps closing on schedule.
The shift from Director to VP — and from VP to CPO — lives in this one sequence
A Director walks in arguing for the bet.
A VP walks in showing the gap, naming the driver, sizing the bet, giving the room a confidence band.
A CPO walks in connecting that bet to the company's external commitments — the funding round, the earnings call, the exit window.
The Director thinks the leadership team is evaluating the idea.
The VP knows the leadership team is evaluating the thinker.
The CPO knows the board is evaluating the company.
Reverse-engineered ROI is the most reliable signal that someone isn't ready for the next altitude.
Forward-built ROI is what moves them up.
One question to sit with this week.
Pull up the last proposal or memo you wrote. The one that didn't quite land, or landed quietly.
Read your first paragraph and ask yourself one thing.
Did I start from the gap? Or did I start from the solution I'd already fallen in love with?
If you started from the solution, the rest of the document was already lost — no matter how clean the numbers were.
This is the work I drill in From PM to Strategic Product Leader.
Six weeks, live, cohort-based. We build the muscle of writing proposals and memos that get funded the first time.
If this resonates, you should be reading this weekly.
I write Product Leadership Unlocked — a weekly newsletter for senior product leaders making high-stakes decisions under real constraints.
Comments