Definition
A business case is a structured document that justifies investment in a product initiative by quantifying the expected financial return, articulating the strategic rationale, and assessing the risks. It answers the executive question: "Why should we spend $X and Y months of engineering time on this instead of something else?"
A strong business case typically includes: the problem or opportunity being addressed, the proposed solution at a high level, financial projections (revenue impact, cost savings, NPV), strategic alignment (how this supports company goals), resource requirements (team, time, budget), risk assessment (what could go wrong and how you'd mitigate it), and success metrics (how you'll know it worked).
The business case is not a product spec. It doesn't define features or user stories -- that's what a PRD is for. The business case operates one level up: it justifies why the initiative deserves resources before anyone defines what to build. Amazon's famous 6-page memo format is essentially a business case with a narrative structure -- every significant product investment starts with a written argument before any code is written.
Why It Matters for Product Managers
PMs who can build a compelling business case get their initiatives funded. PMs who can't end up with smaller teams, lower priority, and roadmap items that get perpetually deferred. This is especially true in larger organizations where engineering capacity is the scarcest resource and every team competes for headcount.
The financial rigor of a business case also protects PMs from shipping features that don't matter. When you force yourself to quantify "this feature will generate $X in new revenue by Y date," you quickly discover whether you have evidence for that claim or you're guessing. Stripe's product teams are required to estimate the revenue impact of major features before approval -- this discipline has kept them focused on high-impact work.
Business cases also create accountability. When you commit to specific outcomes ("this initiative will reduce churn by 2% within 6 months, saving $400K ARR"), leadership can measure whether the investment paid off. That accountability loop makes future business cases more credible if you have a track record of delivering on projections, and more scrutinized if you don't.
At Spotify, the "bet" framework requires product teams to write a business case for each major investment, including the expected outcome and the "kill criteria" -- conditions under which they'd abandon the initiative. This prevents sunk cost fallacy and forces honest upfront assessment.
How It Works in Practice
Start with the problem, not the solution. Frame the business case around the business problem or opportunity, not the feature you want to build. "We're losing 15% of enterprise deals to Competitor X because of a gap in our reporting capabilities" is stronger than "We should build advanced reporting." The problem framing lets leadership evaluate the opportunity independently of your proposed solution.
Quantify the financial impact. Three common approaches: Revenue projection -- estimate new revenue from the initiative using pipeline data, market sizing, and conversion rate assumptions. Cost avoidance -- calculate savings from reduced support volume, manual work elimination, or infrastructure efficiency. NPV (Net Present Value) -- discount future cash flows to present value to compare investments on equal footing. For a $200K initiative that generates $80K/year for 3 years at a 10% discount rate, NPV is approximately $199K.
Calculate payback period. How long until the investment breaks even? A $300K initiative that generates $150K/year in gross margin has a 2-year payback. Leadership often has payback thresholds (e.g., "all initiatives must pay back within 18 months") that constrain which investments are viable.
Assess risks explicitly. List the top 3-5 risks: technical risk (we haven't built this before), market risk (customers say they want this but may not pay), execution risk (team is stretched thin), and competitive risk (competitor might ship first). For each risk, state the likelihood, impact, and mitigation plan.
Define success metrics and kill criteria. What metrics will you track to determine if the initiative is succeeding? Set 90-day and 180-day targets. Also define what failure looks like -- if adoption is below X% after 90 days, or revenue impact is less than $Y, what do you do? Revisit? Pivot? Kill it?
Keep it concise. A business case should be 2-4 pages, not 20. The audience is executives who make allocation decisions across many initiatives. Lead with the recommendation, support it with evidence, and use an appendix for detailed financial models.
Common Pitfalls
Over-engineering the financial model. A 50-tab spreadsheet with assumptions nested 5 levels deep creates false precision. Your revenue estimate is a guess within a range -- present it as such. "We estimate $500K-$800K in Year 1 revenue based on pipeline analysis and 20-30% conversion assumptions" is more honest and useful than "$643,217."
Ignoring the opportunity cost. The business case for Feature A isn't just "will it generate value?" -- it's "will it generate more value than the next best use of that engineering time?" Always compare against alternatives, even if the alternative is "invest those engineers in reducing technical debt."
No sensitivity analysis. What if your conversion rate assumption is off by 50%? What if the market timing is wrong by 6 months? A good business case shows how the conclusion changes under pessimistic, realistic, and optimistic scenarios.
Writing the business case after the decision. If the decision has already been made and the business case is just a formality to check a process box, it serves no purpose. The business case should inform the decision, not justify it retroactively.
Related Concepts
Product strategy provides the strategic context that business cases are evaluated against -- every business case should tie to a strategic priority. Prioritization frameworks like RICE generate the candidates that business cases evaluate in depth. A PRD typically follows an approved business case and defines the detailed requirements for the initiative.
Explore More PM Terms
Browse our complete glossary of 100+ product management terms.