What is a minimum viable product, and how do you design a useful MVP?
Key points
- An MVP is the lightest way to gather validated learning about a risky assumption.
- It does not need every planned feature and does not have to be software.
- It starts with a question, metric and decision threshold defined before the test.
- It must provide enough value to generate observable behaviour.
- The result may lead the team to continue, change the assumption or stop.
A team spends six months building a “minimum” first version. When customers finally see it, the team discovers that the problem was not important enough. The product was reduced, but the investment was not.
An MVP is not the complete product with fewer features. It is an experiment designed to create earlier learning.
What does MVP really mean?
Eric Ries defines a minimum viable product as the version that enables the maximum amount of validated learning about customers with the least effort. In his explanation of the MVP, he also addresses a common misconception: “minimum” does not mean simply building a poor product.
The format depends on the uncertainty. It may be a prototype, landing page, manually delivered service, demonstration or working feature. What matters is the ability to observe behaviour connected to the assumption.
How do you design an MVP?
- choose the riskiest assumption;
- define the behaviour that would support it;
- set the metric and threshold before starting;
- build the minimum required to produce that behaviour;
- involve people from the correct segment;
- record results, limitations and the decision.
If you want to test willingness to pay, asking “do you like it?” is not enough. You need evidence closer to a real choice: a request for a proposal, preorder, letter of intent or purchase, depending on the offer’s maturity.
What is the difference between an MVP, prototype and proof of concept?
A prototype helps explore an experience and whether people understand it. A proof of concept primarily tests technical feasibility. An MVP tests an assumption about value or market behaviour. The same artefact can perform several roles, but the initial question must be clear.
The most expensive mistakes
- building before deciding what needs to be learned;
- choosing users who are easy to reach but outside the target segment;
- measuring stated interest rather than behaviour;
- adding features for fear of showing something incomplete;
- ignoring a negative result and continuing as planned.
A test that disproves the assumption is not a failure. It can prevent months of work in the wrong direction.
How do you choose the assumption to test?
List the conditions required for the model to work. Does the customer recognise the problem? Are they willing to change their behaviour? Can the company deliver the value? Does the channel reach the segment? Can the price support the costs?
Assess every assumption by importance and available evidence. The most dangerous one combines severe consequences with little knowledge. Testing an easy detail first can produce reassuring results without reducing the main risk.
Phrase the assumption so it can be disproved. “Customers want greater control” is vague. “At least five out of ten managers will agree to connect their data in exchange for a weekly report” identifies the segment, behaviour and threshold.
How do you interpret the results?
Decide in advance which results will lead you to continue, modify or stop the experiment. Setting the threshold after seeing the data makes it easy to justify any outcome. Also record unexpected events and limitations of the sample.
A positive result does not automatically prove that the complete model works. It may support only one assumption. Similarly, a negative result may depend on the segment, message, experiment format or the assumption itself. The decision should explain which interpretation is most credible and which test should follow.
Avoid combining incomparable experiments. Changing the audience, proposition and channel at the same time makes it impossible to identify which element affected behaviour.
Quality, trust and risk
Minimum does not mean neglecting security, privacy, accessibility or reliability when a test exposes people and data to real consequences. An MVP for a healthcare or financial process requires different safeguards from a landing page that tests interest.
Reduce scope, not responsibility. You can limit the number of users, perform some activities manually or use fictional data. If a shortcut changes the behaviour you need to observe or creates an unacceptable risk, it is not a useful simplification.
How long should an MVP test run?
It should run long enough to observe the chosen behaviour, not for an arbitrary number of weeks. Establish the sample, period and threshold before beginning. If the buying cycle is long, you can measure intermediate signals while clearly stating that they are not yet equivalent to a sale or sustained use.
Stop early if a risk to people emerges, if the sample is clearly wrong or if a technical fault prevents the assumption from being observed. Extending an invalid experiment does not make its results more reliable.