How to Build an Evidence-Based Business Case for a New Product

An evidence-based business case for a new product is a funding argument where every major claim — that customers want it, that it can make money, that you can build it — is backed by a validation test you actually ran, not a forecast you assembled. It trades projected confidence for demonstrated learning, which is what survives a stage gate.

Quick Answer: Build the case around six parts — problem, solution, evidence, viability, risks, and the ask — and attach a real validation result to each. A gate rewards demonstrated learning over a confident forecast, so lead with what you tested, not what you predict.

Why forecast-first business cases fail at the stage gate

Forecast-first business cases fail because they ask a reviewer to trust a spreadsheet no one has tested, and seasoned gatekeepers have learned that a confident projection is the cheapest thing in the room to manufacture. The more polished the hockey-stick chart, the more skepticism it earns from anyone who has watched projects like yours miss by an order of magnitude.

The mechanics of the failure are worth understanding. A five-year forecast bundles dozens of separate assumptions — that the problem is real, that your solution fits it, that people will switch, that they will pay, that you can reach them affordably — into a single number at the bottom of a column. When that number turns out wrong, and it almost always does, nobody can tell which assumption broke. The forecast was never a test; it was a wish with decimals.

There is a structural reason this pattern persists inside companies. As Tendayi Viki, Dan Toma, and Esther Gons argue in The Corporate Startup, traditional stage gates reward the best-argued plan rather than the best-evidenced one. The person who writes the most persuasive deck gets funded, and persuasion and truth are only loosely correlated. A gate optimized for confidence selects for people who are good at sounding certain, not people who are right.

The alternative isn't a better forecast — it's a different burden of proof. An evidence-based business case shifts the question from "how good is your argument?" to "what did you actually learn?" Instead of defending projections, you present tests: a landing page that converted, interviews that surfaced the same pain repeatedly, a pre-order someone paid real money for. Evidence is harder to fake than confidence, and reviewers know it.

This is also kinder to you as the intrapreneur. A forecast you can't back forces you to defend a position you secretly aren't sure of, under questioning from people who do this for a living. Evidence lets you say "here is what I tested, and here is what came back" — a much easier room to survive, and a much easier conscience to keep.

The evidence-based business case skeleton

An evidence-based business case has six load-bearing parts, and each one carries a piece of evidence instead of a promise: the problem, the solution, the demand evidence, the viability model, the risks, and the ask. Miss any part and the case wobbles; fake the evidence in any part and it collapses under the first hard question.

Think of the skeleton as a chain of claims, each one earning the right to the next.

• The problem — who has it, how painful it is, and how you know it's real rather than assumed.
• The solution — what you'll build, framed as a response to the problem, not a feature list.
• The demand evidence — the tests showing people want this enough to act, not just to nod politely.
• The viability model — how this becomes a business, grounded in signals you've observed rather than benchmarks you borrowed.
• The risks and unknowns — the assumptions still untested and what would prove them wrong.
• The ask — the specific, staged resources you need to retire the next risk, not a blank check for the whole vision.

If you want a fill-in-the-blanks starting point, a founder-focused business case template lays out these sections as a document you can adapt for an internal review.

Here is how each part reads when it's backed by evidence versus when it's running on assumption — the third column is what earns funding, and the fourth is what gets picked apart in the room.

The pattern is consistent: strong cases replace adjectives with tests. Every time you're tempted to write "clearly" or "obviously," that's the exact spot a reviewer will ask "how do you know?" — and the exact spot evidence belongs.

Desirability evidence: proof that customers actually want it

Desirability evidence proves that real customers want your product badly enough to do something about it, and the strength of that evidence depends entirely on how costly the action was. A reply to a survey is weak; a pre-payment is strong. Your case should lead with the strongest desirability evidence you have.

The distinction that matters most here comes from David Bland and Alexander Osterwalder's Testing Business Ideas: weigh what people do far more heavily than what people say. Opinions are cheap and polite; actions cost something. A stranger who hands over an email address, a signature, or a deposit is telling you something a hundred enthusiastic interviews cannot.

Rank your evidence by the cost of the action behind it:

• Said — interview enthusiasm, survey intent, "I'd definitely use this." Useful for discovering problems, nearly worthless for predicting behavior.
• Clicked — a landing-page sign-up, a waitlist join, a click on a fake-door feature. Costs a little attention; a real but soft signal.
• Committed — a letter of intent, a pre-order, a deposit, a signed pilot. Costs money, reputation, or both. This is the evidence that moves a gate.

Present the behavior, then the interpretation — never fused. Write "of the qualified prospects we contacted, a meaningful share booked a paid pilot" and keep it separate from "the market wants this." The first is data; the second is a claim you're making about the data, and a good reviewer will want to see the seam between them. The broader menu of tests that produce this evidence — interviews, smoke tests, concierge MVPs, pre-sales — is laid out in the complete guide to startup idea validation, which is worth working through before you decide which signals to gather.

One caution is specific to corporate settings: your colleagues and existing customers are a biased sample. They want to be supportive, they already trust the brand, and they'll tell you the idea is great. Desirability evidence is only as good as the independence of the people who produced it. Test with strangers who owe you nothing.

The viability model: how the numbers earn belief

A viability model earns belief when its numbers are built up from signals you actually observed rather than down from a market size you looked up. The question a reviewer is really asking is not "how big could this be?" but "which of these numbers have you seen with your own eyes?"

Build the model from the bottom up. Start with the parts you've tested — a conversion rate you measured on a real landing page, a price point someone actually agreed to, a willingness-to-pay range you probed in interviews — and mark everything else as an explicit assumption. A model that honestly separates measured inputs from assumed ones is more persuasive than one that hides the difference behind a confident total.

This is the hardest part of the whole case, because you genuinely don't have much data yet, and the temptation is to borrow authority from big round numbers. Resist it. The discipline of building a forecast when you have almost no history — and doing it without fabricating precision — is its own skill; our guide on how to forecast revenue before you have validation data walks through doing it with ranges and stated assumptions instead of false certainty, which is exactly what a skeptical gate wants to see.

A few principles keep a pre-validation viability model honest:

• Prefer ranges to points. "Somewhere between a conservative and an optimistic case, driven by these two variables" beats a single fake-precise figure.
• Show the unit before the total. If one customer doesn't make sense economically, ten thousand of them won't either. Get the unit economics defensible first.
• Name the make-or-break variable. Most models hinge on one or two numbers — usually conversion and retention. Say which, and say how confident you are in each.
• Tie viability to a test, not a benchmark. "Comparable companies convert at some rate" is a benchmark; "we observed this signal in our own smoke test" is evidence, and reviewers trust the second.

Viability is a claim you can test, not just calculate. Willingness to pay can be probed with a real price and a real call to action long before you build anything. A pricing page that takes a deposit tells you more about viability than any spreadsheet, because it converts a projected number into an observed one.

Feasibility evidence: proof you can actually deliver it

Feasibility evidence proves you can build and deliver the product with acceptable cost, time, and risk — and inside a company, "deliver" includes the operational and organizational reality, not just the code. The goal is to retire the largest technical unknown cheaply, before it becomes an expensive surprise.

Feasibility is usually the risk intrapreneurs over-test, because it's the controllable, familiar part. Engineers especially gravitate here: proving the thing can be built is satisfying and safe. But feasibility is rarely what kills a new product — demand and viability are. Spend proportionate effort. A short technical spike that answers "can the hardest part work?" is worth more than months of architecture on something nobody has agreed to buy.

That said, some feasibility claims genuinely need evidence, and the case is stronger when you show it:

• Technical feasibility — a spike or prototype proving the riskiest component actually works, not a diagram claiming it will.
• Operational feasibility — evidence you can deliver and support the product at quality, especially if it leans on a team or process that doesn't exist yet.
• Dependency feasibility — honest confirmation that the partners, data, integrations, or approvals you rely on are actually available on the timeline you're promising.

In a corporate setting, the feasibility question hiding under the technical one is organizational. Can this product get the shared engineering time, the legal sign-off, the security review, and the channel access it needs — or will it starve inside the existing execution machine? Naming those dependencies as feasibility risks, rather than assuming them away, signals to a gate that you understand where corporate products actually die.

Risks and unknowns: naming what could still be wrong

The risks section names the assumptions you haven't yet tested and states what result would prove each one wrong — and counterintuitively, naming your risks openly makes the case stronger, not weaker. A business case with no stated risks doesn't read as low-risk; it reads as under-examined.

Map your assumptions on two axes: how important each one is to the whole idea, and how much evidence you currently have for it. The assumptions that are both critical and untested are your riskiest, and they're where the next round of testing — and the next round of funding — should point. This importance-versus-evidence mapping is one of the most useful tools in Testing Business Ideas, precisely because it tells you what to test next rather than leaving it to instinct.

Be explicit about three categories:

• Known risks — assumptions you've identified but not yet retired. State the test that would retire each one.
• Kill criteria — the results that would make you stop. Deciding these in advance, before you're attached, is what separates disciplined validation from expensive hope.
• Unknowns you're watching — the things you can't test yet but are tracking, so a reviewer knows you're not pretending the map is complete.

The ask should be sized to retire the top risks, not to fund the whole vision. This is where The Corporate Startup's idea of metered funding matters: rather than one large upfront bet, you request a smaller amount tied to the next set of tests, with more released as evidence accumulates — the way a venture investor stages capital across rounds. It's easier for a gate to say yes to a bounded experiment than to an open-ended build, and it protects you from being over-committed to an idea that later data kills.

Keeping this evidence organized matters more than it sounds. When your risks, tests, and results live in one honest ledger rather than scattered across decks and memories, the whole case becomes legible to a reviewer, a sponsor, or a future you — the kind of validation record a tool like Edmired is built to hold.

Assumption-based vs evidence-based business cases: a side-by-side

The difference between an assumption-based and an evidence-based business case isn't length or polish — it's where the confidence comes from. One borrows confidence from forecasts and benchmarks; the other earns it from tests the author actually ran. Reviewers can tell the two apart within minutes.

The contrast shows up in every section of the document. Here is how the same six parts read depending on which philosophy produced them.

Notice that the evidence-based column isn't more optimistic — often it's more modest. Its power is that every claim can survive the question "how do you know?" A humble case you can defend beats a bold one you can't, every time it meets a serious reviewer.

Common mistakes that sink a new-product business case

Most new-product business cases die from a short list of predictable mistakes, and nearly all of them share one root: presenting an assumption as if it were a fact. Watch for these before you walk into the room.

Leading with a five-year forecast before you've validated anything. The classic error. A detailed projection built on zero tested inputs isn't rigor, it's decoration — and to an experienced reviewer, an elaborate pre-validation forecast actively signals inexperience. Forecast when you have signals to forecast from; before that, lead with what you learned.

Sizing the market top-down and calling it demand. A large addressable market says nothing about whether anyone will buy your specific product. Market size is a ceiling, not evidence. Desirability evidence comes from people acting, not from a slice of a big number.

Hiding the risks to look more confident. Omitting risks doesn't make a case safer; it makes it look naïve to anyone who has evaluated projects before. Stated risks with test plans read as competence. Silence reads as blind spots.

Testing feasibility while ignoring demand. Proving you can build it, in detail, while never testing whether anyone wants it. Feasibility is the comfortable risk to over-invest in because it's controllable. Point your evidence budget at the scary assumption instead.

Asking for everything at once. A single large request for the full build forces a reviewer into a binary, high-stakes decision. A staged ask tied to the next test is easier to approve and easier to defend when priorities shift.

Fusing observation and interpretation. Writing "the market clearly wants this" when what you observed was "a share of contacted prospects joined a waitlist." Keep the raw result and your claim about it visibly separate, or a sharp reviewer will assume you can't tell the difference.

Key Takeaways

• An evidence-based business case backs every claim with a test, not a forecast. The unit of persuasion is something you actually ran and can show, which is exactly what a skeptical gate has learned to trust over confident projections.
• Forecast-first cases fail because they bundle dozens of untested assumptions into one number. When the projection misses, nobody can tell which assumption broke, so the forecast never taught anyone anything.
• Weigh what people do over what they say. A pre-order, deposit, or signed pilot outranks any amount of survey enthusiasm, because costly actions are the only demand signals that don't flatter you.
• Build the viability model bottom-up from observed inputs, and label every assumption. A modest model that separates measured numbers from assumed ones beats a precise-looking total that hides the difference.
• Name your riskiest untested assumptions instead of hiding them. A case with no stated risks reads as under-examined, not low-risk; mapping importance against evidence shows a reviewer you know what to test next.
• Size the ask to retire the next risk, not to fund the whole vision. Metered funding tied to evidence is easier to approve and protects you from over-committing to an idea that later data might kill.
• Feasibility is rarely the idea-killer; demand and viability are. Intrapreneurs over-test what they control — spend your evidence budget on the assumption that actually scares you.

Frequently Asked Questions

What should a business case for a new product include?

A strong business case includes six parts: the problem and who has it, the proposed solution, demand evidence from real customer actions, a viability model, a clear-eyed list of risks and unknowns, and a specific, staged ask. What separates a fundable case from a rejected one is that each part carries a validation result rather than an assertion. Lead with evidence, not projections.

How do I forecast revenue before I have any validation data?

You forecast in ranges, not points, and you build the model up from whatever you've actually observed — a measured conversion signal, a price someone agreed to — while labeling every remaining input as an explicit assumption. Never present borrowed benchmarks as if they were your own results. A reviewer trusts an honest range with stated assumptions far more than a precise total pulled from nowhere.

Why do stage gates reject business cases that have strong financial projections?

Because experienced reviewers know a polished projection is the easiest part of a case to fabricate, and that elaborate forecasts built before any validation often signal inexperience rather than rigor. A projection bundles many untested assumptions into one number that can't be checked. Gates increasingly reward demonstrated learning — tests you ran — over confident numbers nobody has verified.

What is the difference between desirability, viability, and feasibility?

Desirability asks whether customers want the product; viability asks whether it can make money; feasibility asks whether you can build and deliver it. Popularized in Testing Business Ideas, the three are distinct risks that each need separate evidence. Most new products die on desirability or viability, yet teams over-invest in proving feasibility because it's the part they most directly control.

How much validation is enough to justify building a new product?

Enough that your riskiest demand and viability assumptions have each cleared a pass line you set in advance, through tests that could have failed. Feasibility you can often assume; desirability and willingness to pay you cannot. If you can't point to logged results that beat honest thresholds, you're not ready to build — no matter how confident the forecast looks.