MVP vs Evidence: What Actually Reduces Risk

The MVP concept has been reduced to "build something small." That misses the point entirely.

The original insight behind MVP was not about size — it was about learning. Build the minimum thing required to test a hypothesis. But in practice, MVP has become "build a smaller version of the full product" — which is just a smaller commitment to the same unvalidated assumptions.

The MVP misconception

Common MVP mistakes: - Building a scaled-down version of the imagined product (a small product, not a learning tool) - Defining MVP by feature count rather than by hypothesis tested - Treating MVP as "version 1" rather than as an experiment - Spending 3-6 months building an "MVP" that tests nothing specific

An MVP that doesn't have a falsifiable hypothesis isn't an MVP — it's a premature product.

Evidence-based development

Evidence-based development inverts the traditional product development flow:

Traditional: Idea → Build → Launch → Measure → Learn Evidence-based: Hypothesis → Smallest possible test → Evidence → Decision → Build (if warranted)

The key difference: evidence-based development generates learning before committing to building.

Hypothesis prioritization

Not all hypotheses are equal. Prioritize by:

1. Risk magnitude: If this assumption is wrong, how much does it cost?
2. Uncertainty level: How confident are we in this assumption?
3. Testability: Can we test this assumption cheaply?

Test high-risk, high-uncertainty, easily-testable hypotheses first.

The risk-weighted experiment model

For each hypothesis: - Define the experiment (what are you testing?) - Define success (what evidence would confirm the hypothesis?) - Define failure (what evidence would falsify it?) - Estimate cost (time, money, opportunity cost) - Calculate risk-weighted value (risk reduced per dollar spent)

The experiment with the highest risk-weighted value goes first.

The evidence ladder

Climb from cheapest to most expensive evidence:

1. Desk research — What already exists? What do competitors reveal about demand?
2. Conversations — What do potential users say when you describe the problem (not the solution)?
3. Landing page — Do people express interest with their email (low commitment)?
4. Concierge test — Can you deliver the value manually before building?
5. Prototype — Does a minimal interactive version change behavior?
6. MVP — Does a functional version generate payment?

Most teams jump to step 5 or 6 without climbing steps 1-4.

How this decision shapes execution

The choice between MVP-as-small-product and evidence-based-development determines whether your first 6 months produce a product or produce knowledge. Products built without evidence are gambles. Products built on evidence are investments. The execution architecture should optimize for learning speed, not shipping speed.