MVP Validation Frameworks: A Comparison of the Top Five

What you need to know

• Each framework answers a different question. Pretotyping and smoke tests answer "is there demand?" Wizard of Oz answers "is this experience compelling?" JTBD answers "why would someone switch to this?" Lean Startup provides the operating cadence.
• Validation must produce behavior data, not opinion data. A customer who says they would use the product has not validated demand. A customer who signs up, pays, or takes a concrete action has.
• Combining frameworks is appropriate: use JTBD interviews to understand the job, a smoke test to validate demand, and a Wizard of Oz prototype to validate the experience.
• The goal of validation is to surface the most expensive assumption as cheaply as possible. Identify the assumption that, if wrong, kills the business, and design the test around that assumption first.
• Validation that confirms what the founder already believes is not validation. Rigorous validation seeks to disconfirm the hypothesis by looking for evidence against it.

The core argument

Most founders use a single validation framework by default, usually the Lean Startup framework in a loose interpretation, without matching the framework to the specific uncertainty they are trying to resolve. The result is validation that produces confidence without actually reducing the most dangerous uncertainties. Understanding what each framework tests makes it possible to design a validation sequence that addresses the right questions in the right order.

The validation sequence for most consumer or B2B SaaS products starts with demand validation: does the problem exist at scale, and will people take action to solve it? A smoke test or a landing page with a call to action measures this in days with minimal cost. The signal is behavioral: how many people who encounter the proposition take the requested action? At a landing page conversion rate below a threshold that makes the unit economics work, the demand hypothesis is not validated and the founder learns this before writing code.

The second validation layer is experience validation: assuming demand exists, is the proposed experience the right way to deliver the solution? The Wizard of Oz method is the highest-fidelity test here because it delivers the actual experience to real users without building the underlying automation. A manual-fulfillment version of a software product reveals whether users find the experience valuable, what feedback they give about the workflow, and whether they return. This feedback shapes the technical investment before it is made.

JTBD interviews provide the qualitative context that quantitative smoke tests cannot. A high smoke test conversion rate tells you demand exists; JTBD interviews tell you why people are motivated to solve the problem and what they expect a solution to do. The combination of a validated demand signal and a clear understanding of the job being hired means the founder builds the first version with confidence about what matters.

Common mistakes

1. Using customer surveys as validation. Surveys produce opinion data, not behavior data. A survey where 80 percent of respondents say they would pay for a product is not validation. The same 80 percent may not convert when presented with a real checkout page.

1. Designing the smoke test to succeed. A landing page designed to maximize conversion through optimistic copy and compelling visuals does not measure demand for the actual product; it measures demand for a perfect-sounding version of it. The smoke test should present the real value proposition, not the most optimistic version.

1. Stopping validation after demand is confirmed. Demand validation shows that people want a solution to the problem. It does not show that the specific solution being built is the right one. Continue validation through experience and solution testing after demand is confirmed.

1. Using validation as a reason to delay building. Validation should run in parallel with early development, not as a prerequisite. The smoke test, JTBD interviews, and Wizard of Oz test can run while the first technical prototype is being built.

1. Treating negative validation as a failure. A validation test that disconfirms the hypothesis is the most valuable outcome. It prevents investment in the wrong direction. Founders who treat negative signals as tests to be run again until they get the "right" answer are not doing validation; they are doing confirmation.

Where to start

1. Write the three most dangerous assumptions underlying the product idea. The first is usually: customers have this problem severely enough to switch from their current solution. The second is usually: customers will pay at least [amount] for this solution. The third is usually: the proposed solution actually solves the problem better than existing alternatives.

1. Design a smoke test for the first assumption. Create a landing page that presents the value proposition and measures how many people take a meaningful action. Run it for two weeks with targeted traffic before concluding anything.

1. Schedule five JTBD interviews with people who have the problem. Focus the interviews on understanding what they are currently doing to solve the problem, why that is insufficient, and what a better solution would need to do. The interview insights shape the smoke test messaging and the eventual product direction.

Related reading

• How to Test an MVP With Real Users Before You Have Real Users
• MVP Failures I Have Witnessed: A Field Guide
• How to Build an MVP in 2026: A Non-Technical Founder's Complete Roadmap
• How to Set Realistic User Targets for Your MVP