Three letters, and probably the most misapplied concept of the lot. In practice "MVP" usually justifies a sloppy product, when the definition says the exact opposite: small, yes, but complete on what it promises.
The confusion is expensive, because an incomplete product yields no usable information. You will not know whether people did not want it, or could not manage to use it.
Definition
An MVP, minimum viable product, is the smallest version of a product that lets you test a hypothesis with real users, in real conditions, with real payment wherever possible.
Every word carries weight:
- Minimum describes scope, not quality.
- Viable means what ships actually works for the promised use case.
- Hypothesis forces you to know what you are testing before building.
The classic image: to get from A to B, a skateboard is an MVP, a lone wheel is not. The wheel is smaller, but it carries nobody, so it teaches nothing.
Hypothesis first, product second
An MVP without a written hypothesis is a prototype, not an experiment. Before building, write down the sentence you are trying to confirm or refute, and the threshold that will settle it.
| Hypothesis | The MVP to build |
|---|---|
| People have this problem | No product: ten interviews will do |
| They would pay to solve it | A Sales page and a real payment button |
| My solution solves the problem | The service delivered by hand, no software |
| It can run without me | Only here, the automated product |
The third row gets skipped most often and pays best. Delivering the service manually to twenty customers teaches you in three weeks what six months of development never will, because you see the edge cases.
Three ways to get it wrong
Shipping something broken
A user who hits a bug tells you about your bug, not about your hypothesis. The scope must be small, the execution must not.
Not charging
Free distorts everything. Enthusiasm without payment is the least reliable indicator there is, because it costs the person expressing it nothing. Even a token price radically changes the quality of the information.
Carrying on after the answer
An MVP has an end date. If it answered, move to the next hypothesis. If it refuted, change direction. Plenty of people keep adding features to an MVP that already said no.
Frequently asked questions
How long should an MVP take to build?
If the answer exceeds six weeks, the scope is too broad or the hypothesis is badly framed. The time constraint is not affectation: beyond it the market has moved and you have stopped learning.
How many users before concluding?
Far fewer than you think to refute, far more than you think to confirm. Five interviews surface most major problems. Concluding that a product works, however, means watching people come back, so several weeks of Retention.
Should I promote an MVP?
Yes, but say what it is. Stating the product's stage protects your reputation and attracts exactly the forgiving, talkative users you need at this point.
How does an MVP relate to Micro-SaaS?
The MVP is a stage, micro-SaaS is a destination. Plenty of profitable micro-SaaS still resemble their MVP two years on, because the narrow scope was right from the start. Our Claude Code course covers that slicing while you build, which is where the urge to add one more feature actually plays out.