A good MVP is not a shortened feature list. It is a small, complete product that tests one assumption by the shortest route.
Key takeaways
- An MVP exists to test your riskiest assumption, not to shrink the product.
- Scope is set by the question you want answered, not by features.
- Every feature you cut needs a written answer to 'when do we come back to this'.
- Small scope does not mean careless architecture; the first release must be something you can build on.
In this article5 sections
The sentence we hear most often in an MVP meeting is: "Let's add this too, it's only a small thing." Looked at one by one, they are all small. Added together, they make a six-month project and an idea that is still untested. The hard part of an MVP is not deciding what to build but what not to build.
An MVP is not a shrunken product
The common mistake is to list the whole imagined product and then cut the list in half. What you get this way is not an MVP but an incomplete product. There is a bit of everything, and nothing works end to end.
We start from the other side. First we ask: which is the riskiest assumption that has to be true for this product to succeed? Do people really have this problem, will they pay for a solution, will they change a habit? An MVP is the product that answers one of these questions by the shortest route.
The question sets the scope
Once the assumption is clear, the scope narrows by itself. When we discuss a feature we use a single test: can we get our answer without it? If we can, the feature stays out of the first release.
- One type of user: the first release does not try to serve everyone. We pick the group that feels the problem most.
- One main flow: the path from opening the app to seeing the benefit must work flawlessly. Side paths can wait.
- Whatever can be done by hand is done by hand: admin panels, automated reports and advanced notification rules can usually be handled with a spreadsheet and a few emails in the first months.
Do not lose what you cut
Features labelled "later" tend to come back in one of two ways: never, or at the worst moment and unplanned. To prevent this we tie every cut item to a condition, such as "when monthly active users pass this level" or "when five of the first ten customers ask for it". The team knows why something is waiting, and the founder does not feel it has been abandoned.
Small scope does not mean careless work
The idea that an MVP is a throwaway prototype is an expensive misconception. Once the idea is validated, the last thing you want is to stop for three months to rewrite everything. So in the first release we cut the number of features, not the foundation: the data model, authentication, analytics and release process are set up properly from day one.
The sign of a good MVP
If you have a decision in hand four weeks after launch, the MVP has done its job. Continue, change direction or stop: all three are valid outcomes. If all you have is a feeling that "it will work with a few more features", the scope was set by wishes rather than by a question.
If you have an idea and are weighing where to start, let's use our first conversation to talk about the assumption you want to test, not the feature list.
