What an MVP is — and the different types
Minimum Viable Product, properly understood: not half a solution, but the fastest experiment to learn something real.
MVP stands for Minimum Viable Product — the smallest possible product that lets you validate a core assumption against the market. The term is often misunderstood: an MVP is not a stripped-down final product, and not an excuse for poor quality. It is an experiment.
The right question isn't "what's the minimum we can build?" but "what's the minimum we have to build to learn something real?".
Viable, not just minimal
All three words matter:
- Minimum — as little effort as possible.
- Viable — yet usable enough that someone actually uses and judges it.
- Product — it must deliver real value, not a placeholder.
The famous picture: if the customer wants a car, a single wheel is not an MVP — nobody can drive it. A skateboard is. It solves the same basic need (getting from A to B), however incompletely, and produces real feedback.
Build — Measure — Learn
An MVP is part of a loop, not a one-off shot:
You build only as much as you need to measure. You measure in order to learn. You learn to steer the next iteration — or to discard the idea before it gets expensive.
The different types of MVP
An MVP doesn't always have to be code. Depending on the assumption you want to test, there are different forms — roughly two families.
Low-fidelity: test whether the problem is real
Here you often build nothing yet. The goal is to probe demand and need.
| Type | What it is | What for |
|---|---|---|
| Landing page | A page describing the product, plus a "sign up" button | Measures interest via clicks and sign-ups before anything exists |
| Explainer video | A short video showing the value | Test ideas that need explaining (this is how Dropbox started) |
| Fake door / button | A feature button that only shows "coming soon" | Measures whether a feature gets clicked at all |
| Piecemeal MVP | Stitched together from existing tools (forms, Zapier, sheets) | Quickly simulate an experience without custom development |
High-fidelity: test whether the solution works
Here you actually deliver the service — only the implementation behind it is minimal.
| Type | What it is | What for |
|---|---|---|
| Concierge MVP | The service is delivered manually and in person | Understand the service before automating it |
| Wizard of Oz | Looks automated up front, a human does the work behind | Test automation without building it |
| Single-feature MVP | A real product with exactly one core function | Validate the actual solution path |
The difference between concierge and Wizard of Oz: with the concierge, the user knows a human is helping. With Wizard of Oz, they believe they're interacting with a finished system — the manual work stays hidden.
How to choose the right type
The choice follows the riskiest assumption:
- Do you doubt the problem even exists? → low-fidelity (landing page, fake door).
- Do you believe in the problem but not the solution? → concierge or Wizard of Oz.
- Are problem and solution plausible and you want to test scalability? → single-feature MVP.
Common misconceptions
- "MVP means poor quality." No — viable includes a working, trustworthy experience. Reduce the scope, not the care.
- "You build an MVP once." It's the first step of a loop, not a milestone to check off.
- "More features = safer." Every extra feature obscures what actually creates value and delays learning.
A good MVP is uncomfortably small. That's exactly the point: it forces you to find out early whether you're on the right track — while changing course is still cheap.