What an MVP is and why yours should be smaller
A minimum viable product proves one thing with the least software. Why most first versions are too big, how to cut scope, and what a good MVP looks like.
The short answer
A minimum viable product is the smallest piece of working software that lets real users do the one thing you need to learn about. It is not a rough draft of the final product and it is not a demo. It is an experiment with real people and real data, built to answer a specific question as cheaply as possible.
First versions we are asked to quote come in three times too large. Cutting them is the most valuable work in the project.
Why first versions are too big
- Everyone adds one thing. Each stakeholder has a feature that “obviously” must be in. Nobody removes anything.
- Fear of looking unfinished. A product with three features feels risky to show. So it grows until it feels complete, and it ships a year late.
- Confusing the vision with the test. The five-year picture is useful for direction and useless as a build list.
- Building for the exceptions. The edge case that happens twice a year gets designed in before the daily case has been used once.
How to cut
- Write the question. One sentence. “Will our customers book and pay online instead of calling?” If you cannot write it, you are not ready to build.
- List everything proposed. All of it, without arguing.
- Apply one test to each item. If this were missing, would the answer to the question be invalid? Booking flow: yes. Payment: yes. Account history, loyalty points, admin dashboard with charts: no.
- Keep what passed. That is the MVP. Usually a third of the original list or less.
- Park the rest with a date. Not deleted, not forgotten: a list to reconsider once real usage data exists.
- Build the kept items properly. Working, secure, measured, with real data. Small does not mean sloppy.
What a good MVP looks like
| Characteristic | What it means |
|---|---|
| One clear question | Everyone can say what the MVP is meant to prove |
| Embarrassingly few features | If nobody is a little uncomfortable with how little it does, it is too big |
| Solid core | The features that exist work, handle errors and are secure |
| Real users, real data | Not a demo for the board; actual customers or staff doing actual work |
| Measured | You know what people did, not just that they logged in |
| Cheap to change | Built so the next version is a step, not a rewrite |
After the MVP
The point of the MVP is what happens next. You look at what people actually did, which is almost always different from what was predicted, and build the next smallest thing the evidence supports. Sometimes the answer is that the idea does not work. That is not a failed project; it is the cheapest possible version of finding out.
What this means for you
Before you ask anyone for a quote, write the one question your software must answer and run every proposed feature through the “would the test be invalid without it” filter. Take what survives to a scoping conversation. You will get a smaller, faster, cheaper first version, and an answer months earlier than the full build would have given you.
Frequently asked questions
Is an MVP a cheap, low-quality version?
Small in scope, not low in quality. The parts that exist must work properly, be secure and handle real data, because real people will use them and you will make decisions on the results. What is cut is features, not craftsmanship.
How do we decide what goes in?
Write the question the MVP must answer, for example 'will customers book online instead of calling'. Then for each proposed feature ask whether the test would be invalid without it. Booking, yes. A loyalty programme, no. What is left is the MVP; everything else goes on a list with a date to reconsider.
What happens after the MVP?
You look at what people actually did, which is usually different from what everyone predicted. Then you build the next smallest thing the evidence supports. Many MVPs grow into the product; some prove the idea does not work, which is the cheapest possible way to learn that.
Can we skip the MVP and build the full product?
You can, if you are certain about what users need and how they will behave. In our experience nobody is, including us. The full build costs several times the MVP and locks in every wrong assumption. The MVP is how you avoid paying for those.