An MVP is not a product with fewer features. It's a hypothesis with a feedback mechanism. Most startup MVPs are actually MFPs — Minimum Feasible Products — and they answer the wrong question.
The Confusion
"Minimum Viable Product" has been so thoroughly redefined by startup culture that it now means almost the opposite of what Eric Ries intended.
The original intent: build the smallest thing that tests your most critical assumption. Ship it. Learn. Iterate.
The common interpretation: build a stripped-down version of what you actually want to build, then add features until it's good.
These are not the same thing.
The Critical Assumption Problem
Every startup is a bundle of assumptions. Some of those assumptions, if wrong, will kill the business. The MVP's job is to identify which assumptions those are — and test them as cheaply as possible.
The failure mode is not building too little. It's testing the wrong assumption.
A technically excellent product that tests whether users like your interface is useless if the real critical assumption is whether users will pay for the outcome at all.
What the Wrong MVP Looks Like
The wrong MVP is built by engineers who've been told to "build fast and learn." So they build the product — just with fewer features. The interface looks good. The data model is thoughtful. The API is well-structured.
But nobody asked: What is the specific belief we need to validate, and what's the cheapest experiment to validate it?
The answer to that question is rarely "build a software product."
What the Right MVP Looks Like
The right MVP might be:
- —A landing page with a waitlist (tests: Is there demand for this solution?)
- —A manual service delivered via email (tests: Will people pay for this outcome?)
- —A spreadsheet shared with 10 customers (tests: Does this data help them make decisions?)
- —A Wizard of Oz — a product that feels automated but is actually manual (tests: Does this workflow solve the problem?)
The right MVP is frequently not a software product. When it is software, it's the minimum code needed to test the specific assumption — not the minimum features for a usable product.
The Engineering Tension
This creates real tension for engineers who care about craft. We know the code is held together with metaphorical duct tape. We know the data model will need to be rebuilt. We know we're accumulating technical debt.
Here's the reframe: technical debt on the wrong product is not debt. It's sunk cost. You don't pay it down — you write it off.
The discipline is knowing which assumptions are critical enough to require a real implementation, and which can be tested with something far simpler.
The Question That Matters
Before writing a single line of code for an MVP, ask:
What is the specific belief this product is designed to test, and what would falsify it?
If you can't answer that question precisely, you're not building an MVP. You're building a product — just a small one.