Every product investment starts with something the organization believes in. The budget gets approved, the team gets staffed, and the work begins. Then the product launches and falls flat. The postmortem reveals that customers didn’t need it, didn’t want it, or weren’t willing to pay for it. The budget is gone, and the organization is left asking what went wrong.
How Most Organizations Fund Product Investment
The standard approach to product investment is familiar to anyone who has sat through a planning cycle. Someone builds a business case, leadership reviews it, and if it’s compelling enough, the budget gets approved. The team gets full funding and goes off to build.
The business case looks credible because it draws on real inputs: market research, competitive analysis, revenue projections, customer feedback. The problem is that these inputs feed a set of beliefs the organization then treats as facts. The problem is real. Customers will pay to solve it. The solution the team has designed is the right one. The market is large enough to justify the investment. None of this has been proven. It has been argued.
That distinction rarely gets scrutinized during budget approval. It gets scrutinized during the postmortem.
The Problem With Funding Product Development on a Business Case
A business case that hasn’t been tested against reality is carrying risk in four distinct categories. Any one of them, left unexamined, is enough to undermine the investment.
- Desirability risk: Customers don’t actually have the problem you think they have, or don’t want your solution to it badly enough to change their behavior.
- Feasibility risk: Your team can’t build what the business case assumes you can build, at the cost or timeline the plan requires.
- Usability risk: Customers can’t figure out how to use the product effectively enough to get value from it.
- Viability risk: The unit economics don’t work. The cost to acquire and serve customers exceeds what they generate.
For a deeper look at how each of these plays out in practice, and how to identify which ones apply to your product, see Product Risk Management: The 4 Types Every Product Manager Must Master.
Using Validated Learning to Reduce Product Risk
Eric Ries introduced validated learning in The Lean Startup to help teams address exactly these risks. The practice is straightforward: generate evidence about your assumptions through structured experiments rather than treating them as facts. Design experiments that test the assumptions in each risk category and use what you learn to decide whether to proceed.
The experiments don’t need to be elaborate. The goal is to find the cheapest test that could produce a credible answer. The sequence matters because running technical feasibility work before validating customer demand risks investing engineering effort in a product nobody wants. Test the riskiest assumption first.
Before running any experiment, define three things: what you’re testing, what result would increase your confidence enough to keep going, and what result would cause you to change direction. That pre-commitment prevents the most common failure mode, which is collecting data and then selectively interpreting it to confirm what the team already believed. If the experiment results don’t change any decisions, it wasn’t a real experiment.
For a practical guide to choosing and running the right validation approaches, see Product Discovery and Validation: 10 Proven Techniques for Better Products.
Incremental Funding: Increasing Investment as Risk Reduces
The evidence those experiments generate is what drives the next funding decision. Rather than committing the full budget upfront, incremental funding starts with a smaller initial investment, enough to run the experiments that test the riskiest assumptions. As those experiments generate evidence and risk comes down, the justification for increasing investment grows.
Early in a product’s life, all four risk categories are open questions. That is precisely the wrong time to commit full capital. As each round of experiments generates evidence and closes those questions, it earns the next increase in investment. A team that has validated customer demand, confirmed technical feasibility, and demonstrated willingness to pay has earned a fundamentally different conversation with leadership than a team that has only argued for those things in a slide deck. That difference justifies a larger investment, not because the business case got more persuasive, but because the evidence base got stronger.
Fund What You’ve Learned, Not What You Believe
Funding everything upfront asks the organization to make one big bet based on what the team believes at the start. Incremental funding changes the nature of that bet. Each round of investment is smaller, tied to what the team has learned, and justified by evidence rather than conviction. The organization doesn’t have to be right at the beginning. It just has to be willing to learn before it commits more.
