How to Build a Business Case for a Product Investment
What’s the actual ask?
That question — usually the first one a CFO or COO asks when a PM finishes a product investment pitch — is almost always the moment the room goes quiet. Because most product business cases are built to justify a decision that’s already been made, not to communicate what’s needed and why. Learning how to build a business case for product investment that survives that question is a different skill than writing a good PRD, and most PMs never get taught it directly.
The business case that gets funded isn’t necessarily the one with the best idea. It’s the one that answers the finance team’s questions before they ask them, speaks in the language of risk and return rather than user value, and is honest about what it doesn’t know.
Why PMs Struggle to Get Investment Approved
The core problem is a translation failure. PMs think in terms of user problems, product opportunities, and experience improvements. Leadership thinks in terms of risk, return on capital, and opportunity cost. Neither frame is wrong — they’re just different, and the PM is the one who needs to bridge them. This isn’t a character flaw so much as a training gap: most PMs are taught to write PRDs and run discovery, and rarely taught the finance vocabulary that actually gets a document funded.
The second problem: PMs often show up with a solution rather than a problem. “We should build X because users want it” is not a business case. It’s a feature request with a rationale. A business case starts further upstream: here’s the opportunity, here’s what it’s worth, here’s what it would cost to pursue, here’s what we’re giving up by not pursuing it, and here’s how confident we are in each of those estimates.
This mistake shows up constantly at the mid-market stage: a PM pitches a significant investment in an onboarding flow by leading with user research — a handful of interviews showing clear confusion at a specific step. The product case is compelling, but the executive team listens, nods, and asks for “some numbers.” What they wanted was the business case that should have opened the meeting. A useful gut-check before any leadership conversation about resourcing: if you stripped out every sentence about the user and kept only the numbers, would there still be an argument left standing? If not, the case isn’t ready for the room yet.
What a Business Case Is (and What It’s Not)
A business case is a structured argument that a specific investment is worth making, given the costs and the alternatives. Harvard Business Review’s guide to building a business case frames this as telling a story about a need, not just presenting a spreadsheet — the numbers support the story, they don’t replace it.
It is not: a PRD, a pitch deck, a strategy document, or a user research report. Those are inputs. The business case is the synthesis that connects user insight to financial rationale to a specific decision request.
The keyword is “decision.” Every business case should end with a specific ask. Not “we think we should invest in this area” — that’s an opinion. “We’re requesting 1 engineer and 1 designer for 8 weeks to build the revised onboarding flow, to increase 7-day retention from 38% to 50% by Q3” — that’s a decision request.
Leadership can approve it, reject it, or modify it. They can’t act on a vague recommendation. The more specific the ask, the easier it is to say yes. Tying that ask to a metric your company already tracks matters more than most PMs realize — if your north star metric is already the language leadership uses in every other meeting, a business case framed against it doesn’t need to be translated twice.
The Business Case Structure That Actually Works
Business Case One-Pager Template
| Section | What Goes Here | Length |
|---|---|---|
| Problem | The specific user or business problem you’re solving, with evidence | 2–3 sentences |
| Proposed Investment | What you’re asking for: team, time, cost | 1–2 sentences, specific numbers |
| Expected Outcome | What changes if this works: metric, magnitude, timeline | 1–2 measurable outcomes |
| Risk | What could go wrong, and how would you know early | 2–3 honest bullets |
| Ask | The specific decision you need, by when | 1 sentence |
Keep the business case to one page. If it takes two, the argument isn’t tight enough yet. The one-pager forces you to prioritize — the things that don’t make it onto one page are probably not the core of the argument.
The most common mistake in the structure is making the problem section too short and the solution section too long. Leadership needs to feel the urgency of the problem before they’ll care about the solution. Spend at least as much space on “here’s what it’s costing us not to solve this” as you do on “here’s what we’d build.”
For context, how you pitch a feature to leadership is related but different — a pitch is often verbal and forward-looking; a business case is a written document that needs to stand on its own.
How to Estimate ROI Without Lying to Yourself
ROI estimates in product business cases are almost always wrong. The question is whether they’re useful despite being wrong.
The approach that works: build a range, not a point estimate. “We estimate this could increase 7-day retention from 38% to somewhere between 44% and 55%, based on similar interventions at comparable companies.” The range communicates confidence level and shows you’ve thought about variance. A single number implies precision you don’t have.
Show your math. Not in a footnote — in the body of the case, where anyone reading can follow the arithmetic without asking you to walk them through it separately. “If we move retention from 38% to 45% for the 800 users who sign up each month, we retain roughly 56 additional users per month. At our average contract value of $1,200/year, that’s approximately $67,000 in annual recurring revenue against a build cost of roughly $40,000 in team time.” That math might be wrong, but it’s a specific, challengeable argument, which is infinitely more useful than “we believe this will increase revenue.”
The trap is getting too precise. A spreadsheet with six decimal places and a Monte Carlo simulation is a red flag, not a credibility signal. It usually means someone has overinvested in the model and underinvested in validating whether the inputs are real. Financial models with a beautifully built structure and a completely made-up conversion assumption sitting three tabs deep are common enough to watch for — nobody in the room challenges the spreadsheet’s formatting, but the one person who asks “where does 12% come from?” can end the pitch in about ninety seconds.
A lighter-weight way to sanity-check the size of the opportunity before you build a detailed model: run a rough RICE-style estimate of reach and impact first. If the reach number is small enough that even an optimistic impact estimate doesn’t clear the cost of the investment, you’ve saved yourself the two weeks it would have taken to build the detailed ROI model, and you can go find a bigger problem instead.
Be explicit about your biggest assumption. Every ROI estimate has one number that’s doing most of the work. Name it. “The biggest risk in this estimate is the retention lift — we’re assuming we can move from 38% to 45%, but we haven’t validated that yet. Here’s how we’d test it cheaply before committing the full build.” Naming the assumption out loud, before anyone else finds it, changes the dynamic of the meeting from “defend your number” to “let’s figure out together how to de-risk this number” — and the second conversation is one you can actually win.
Understanding the roadmap context matters for ROI too — if this investment gets killed mid-quarter because of a priority shift, what’s the sunk cost? That’s a risk worth naming in the business case.
What Leadership Is Really Asking When They Say No
“No” to a business case is rarely about the idea. It’s usually about one of four things, echoing a pattern Lenny Rachitsky has described in his writing on getting buy-in: most failed pitches trace back to assuming the audience already shares your context, rather than building it for them explicitly.
They don’t trust the numbers. Either the ROI estimate doesn’t pass the smell test, or they don’t trust the underlying assumptions. Fix: show your math and name your biggest assumption proactively.
The timing is wrong. There’s a competing priority, a budget freeze, or a strategic initiative that makes this investment premature. Fix: ask “what would need to be true for this to be a yes?” — you’ll usually find out the real constraint.
They don’t understand the problem. If you lead with the solution, leadership might not have grasped why the problem is urgent. Fix: Send the one-pager a day before the meeting so they’ve read the problem section before they see you.
The ask is too vague. “Invest in onboarding” isn’t actionable. “8 weeks, 1 engineer, 1 designer, specific target metric” is. Fix: make the ask as specific as possible, including what you’re not asking for.
A well-structured product principles document can help here — if leadership knows your principles, they can evaluate the business case against “does this fit who we are” rather than just “does this make financial sense.”
Business Case Mistakes That Kill Credibility
Citing research without data. “Users tell us they want this” is not a business case. It’s a qualitative signal. Pair it with behavioral data: usage patterns, drop-off rates, support ticket volume. The research tells you what users say; the data tells you what they do.
Ignoring the opportunity cost. Every investment displaces something else. If you’re not acknowledging what won’t happen because you’re doing this, leadership will ask — and if you haven’t thought about it, you’ll look underprepared. Naming the trade-off yourself, before anyone asks, is a small move that disproportionately builds trust: it signals you’ve thought about the decision the way they have to, not just the way you want to.
Being defensive about the numbers. If leadership questions your retention estimate and you say, “Well, it could be higher,” you’ve lost the room. The right response: “You might be right. Here’s what we’d need to believe to hit the low end of my estimate, and here’s how we could test that assumption for $5,000 before committing the full build.”
Burying the ask. The specific decision request should appear at the top of the document and again at the end. Don’t make the reader search for it. A request buried on page two of a three-page doc under a section titled “Background” is easy for a skimming director to miss entirely — and easy to fix by putting the ask in the first line and repeating it in the last.
The business case you should write this week: pick the highest-priority item on your current roadmap that doesn’t have explicit leadership buy-in. Write one page — problem, investment, expected outcome, risk, ask. Read it back as if you’re the CFO. If you wouldn’t fund it based on what’s there, you know what’s missing. That gap between what you wrote and what would actually convince a skeptical CFO is usually smaller than it feels, and closing it is almost always a matter of specificity rather than persuasion.
References
