An MVP (minimum viable product) is the smallest version of a product that can test an assumption with real customers and produce learning. Its scope does not come from the wish list: it comes from the riskiest assumption, the one that brings the idea down if it is wrong. Only what is needed to test it goes in, with a success criterion set beforehand so the result leads to a decision.
How to use
- Describe the product and the hypothesis, and write the riskiest assumption.
- Choose the type of risk: demand, value, usability or feasibility. It sets the suggested MVP type.
- List the candidate features with value and effort from 1 to 5 and mark only those needed for the test.
- Set the metric, target and duration, and read the scope, the MVP type and the decision rule.
- Export as Markdown, CSV or DOCX, or take the scope to the PRD generator.
What each field asks for
| Field | What to enter |
|---|---|
| Product or idea | Name and one sentence on what it is. |
| Hypothesis | Who, what and why, in a sentence that could prove false. |
| Riskiest assumption | If it is wrong, the whole idea falls. |
| Type of risk | What the assumption puts in doubt. It sets the MVP type. |
| Feature | E.g. weekly recurring payment |
| Value (1 to 5) | 5 = a lot of value for the customer. |
| Effort (1 to 5) | 5 = a lot of work to build. |
| Needed for the test? | Without it, can you test the assumption? |
| Success metric | Real behaviour, not an opinion. |
| Target | The number that separates success from failure, set beforehand. |
| Test duration | How long the MVP runs before the decision. |
Example
A fictional frozen meal subscription for people who work from home wants to know whether people pay upfront for a fixed menu, a value risk. Of 6 features, 3 go into the MVP: the delivery notice, the subscription page and the recurring payment, which has effort 4 and is therefore simulated by hand. MVP effort comes to 4 of 10 for 4 weeks. The suggestion is a concierge MVP, with manual operation behind the interface as the alternative. The delivery tracking app goes to "rethink".
When to use
- When the list of what "must be in the launch" only grows and nobody manages to cut it.
- Before investing in a new product, to test first the assumption that could bring the idea down.
- To choose between a smoke test, a concierge, a prototype or a technical spike.
- To agree with the team and leadership, before starting, what counts as success.
Frequently asked questions
What is an MVP?
It is the smallest version of the product that lets you learn from real customers whether an important assumption is true. Minimum does not mean sloppy: what goes in must work well for the test to count.
What is the riskiest assumption?
It is the belief that, if wrong, brings the whole idea down, and for which you have little evidence. Testing it first avoids building a lot on a foundation that does not hold.
How do I choose the MVP type?
By the risk. Demand doubts call for a smoke test; value doubts call for a concierge, a single feature or a pre-sale; usability doubts call for a prototype; technical doubts call for a spike. The tool applies this rule and shows an alternative.
What does "simulated by hand" mean?
Features that the test needs but that are expensive to build can be done by people or with off-the-shelf tools during the MVP. If the test succeeds, that is when automation is worth it.
What is the difference between an MVP and a first version?
The MVP exists to learn; the first version exists to deliver value sustainably. An MVP with more than five features is usually a first version in disguise, and learning takes longer.
How do I set the success criterion?
Pick real behaviour (sign-up, payment, renewal), a number and a time frame, and agree on them before starting. Without a number set beforehand, any result looks like success.