Minimum Viable Products (MVP)
An MVP is the smallest thing you can build that tests whether people actually want what you're planning to build, before you spend real money finding out the hard way.
Arrows loop through build, measure and learn, curling back to the start each time round.
Reach for this when…
- You're about to spend months building based on an assumption nobody's tested.
- Stakeholders want proof of demand before they'll fund the full build.
- You keep adding features to a thing no customer has touched yet.
How to run it
- Write down the assumption you most need to be true.
- Design the smallest thing that tests it, even if it's manual or ugly.
- Get it to real users, not internal reviewers.
- Measure what they actually do with it.
- Use the result to decide the next build, not to justify the last one.
A worked example
Situation. Ioana Pop wanted to sell smallholder farmers around Cluj, Romania, a soil-testing subscription, but her engineers were designing a full sensor and app platform before a single farmer had said yes.
Applied. She built "Pamant" as a WhatsApp number: farmers sent a soil photo, she paired it with a local agronomist's judgment and a paper report, no sensors involved.
Result. Nineteen farmers paid for reports in the first month. That told her the diagnosis had value long before she had to justify hardware costs.
The catch
MVP gets used as an excuse to ship something half-built and call the complaints 'learning'. A minimum viable product still has to be viable: it has to actually solve the person's problem, just narrowly. And a single early cohort's enthusiasm is not market validation.
If the 'minimum' version couldn't work as a real, if small, business on its own, it isn't viable, it's a prototype.
Origin: Eric Ries; Frank Robinson