The minimal viable product approach means building the smallest version of a piece of software that real people can use for a real task, putting it in front of them, and deciding what to build next from what you learn. Its main advantage is that you find out early, and cheaply, whether you are building the right thing. Its main disadvantage is that “minimal” is easy to get wrong: cut too much and the result proves nothing, cut the wrong things and you are left running a business on something that was only meant to be an experiment.
The usual name is minimum viable product, shortened to MVP. Minimal viable product means the same thing, and this article uses both.
What a minimal viable product is
The term was coined by Frank Robinson in 2001 and made widely known by Eric Ries, who defined it in 2009 as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. Ries added that, despite the name, it is not about creating minimal products. The point is learning. Small size is only how you keep the cost of that learning down.
Both words carry weight. Minimal means it does one job, or a few, and leaves the rest for later. Viable means a real user can complete that job without help and would choose to come back.
An MVP is different from a prototype. A prototype is a mock-up used to test a design or an idea, and is usually thrown away. An MVP is working software used for real work, with real data. Our article on wireframes, mock-ups and prototypes covers the earlier stages.
The advantages
You learn before most of the money is spent. Every software project rests on assumptions: that customers want the feature, that staff will change how they work, that the data in the old system is usable. An MVP tests the most important of these with a fraction of the budget. If the assumption is wrong, you have lost weeks instead of a year.
It forces a decision about what matters. Most requirement lists contain features nobody will use. Having to name the one task the first release must support exposes them, and the argument happens before anything is built.
Something useful arrives sooner. A small release that handles one process properly starts repaying its cost while the rest is still being planned.
It is easier to buy. A first release with a narrow, clearly described scope is the kind of work that can be quoted at a fixed price, because both sides can see where it starts and stops. A large project with an open-ended scope cannot.
Later decisions are based on evidence. After a few weeks of real use you know which requests keep coming up and which were only opinions in a meeting.
The disadvantages
“Minimal” gets used as an excuse for poor quality. Leaving features out is the method. Leaving out security, backups or testing is not, and an MVP that loses data or falls over teaches you nothing about the idea, because users reject it for the wrong reason.
The experiment becomes the permanent system. This is the most common way the approach goes wrong. The MVP works well enough, the second phase is never funded, and five years later the business depends on software built with shortcuts that were meant to be temporary. Those shortcuts are a form of technical debt, and it is repaid with interest.
It does not suit every kind of system. Where an existing system is being replaced, staff cannot do half their job in the new one and half in the old. In that case “minimum” is set by what the old system already does, and the safer route is usually to modernise it in stages. The same applies where there is a legal or safety floor: payroll that is right for most employees is not viable.
Learning takes effort. An MVP only pays for itself if someone watches how it is used, measures the result and acts on it. Without that, it is simply a small product.
The scope argument still happens. Every stakeholder believes their feature is part of the minimum. Without someone who has the authority to say “not yet”, the MVP grows until it is the full project under a different name.
First impressions count. Customers who try a thin first version and dislike it may not return for the second.
When the approach fits
| Situation | Does an MVP fit? |
|---|---|
| A new product or service where demand is unproven | Yes. This is what the approach was designed for. |
| A new internal system replacing spreadsheets or paper | Usually. Start with the one process that causes most trouble. |
| A customer portal added to an existing system | Usually. Begin with the request customers make most often. |
| Replacing a system that staff use all day | Rarely as a whole. Replace it in stages, each stage complete for the people who use it. |
| Regulated calculations, payments, safety | Only for the parts around the core. The core has to be right from the first day. |
How to decide what goes in
Start from the question, not the feature list. Write down the assumption that would sink the project if it were wrong, then ask what is the least you could build to test it.
Next, follow one type of user through one task from start to finish. A release that lets a dispatcher create a job, assign it and see it completed is viable. One that has half of the dispatcher’s screens and half of the engineer’s is not.
Sort everything else into what the first release must have and what can wait. The second list is the plan for the next stage.
Keep the things users never see out of the bargaining: access control, backups, an audit trail where money is involved, and the handling of personal data. If the system will hold personal data, check your data protection obligations before the first real user is added, and take advice if you are unsure.
Give each item in the first release acceptance criteria, so that “finished” is something both sides can check.
Finally, decide in advance what you will measure and what result would lead you to continue, change direction or stop. An experiment with no agreed outcome will always be declared a success.
Questions to settle before you commission one
Whether the MVP is built by your own team or a supplier, get written answers to these before work starts:
- What is the single assumption this release is testing, and how will we know the answer?
- Who are the first users, and have they agreed to take part?
- What has been deliberately left out, and is that list written down?
- Is the code being written to be kept and extended, or to be thrown away? Both are legitimate. Not knowing which is the problem.
- Is there a budget for the stage after this one? If there is not, treat the MVP as the finished system and specify it accordingly.
- Who owns the source code and the accounts it runs on?