What an MVP is and how to scope it

An MVP, or minimum viable product, is the smallest working version of a product idea that is enough to test its riskiest assumption with real users. The important word in that definition is not “smallest”. It is “test”. That is why most MVPs grow: the team starts listing what to build before writing down what it is testing.

What an MVP is not

An MVP is not a prototype. A prototype is built to show an idea and then thrown away; an MVP does a real user’s real work.

An MVP is not the first release either. A first release ships to be sold; an MVP ships to learn. The two can be the same code, but different questions decide the scope.

And an MVP is not “half of every feature”. Building all ten features halfway means testing none of them. Running a single flow end to end, with nothing missing, is smaller and teaches more.

Write the assumption first

When a scope meeting starts with a feature list, the list only gets longer. Every feature is reasonable on its own.

A better start is one sentence: “These people, for this problem, will use this and do that in return.” The last part matters. “Will use it” is one assumption; “will pay”, “will invite their team”, “will come back the following week” are each different assumptions, and each calls for a different product.

Once the assumption is written, one question remains for every feature: can the assumption be tested without it? If it can, the feature belongs to the second version.

Build one flow end to end

In a SaaS product, the value usually rides on a single flow: the user arrives, enters something, gets a result. The MVP is that whole flow.

The whole flow means sign-up, the core task, and the result reaching the user. If one of the steps in between is missing, the user never gets to the result, and what you are testing is not the product but the missing step.

What sits outside the flow can be postponed to a surprising degree: detailed permission roles, a settings page, notification preferences, export, a second language. All of them are real needs and none of them tests the first assumption.

Do not automate what can be done by hand

For the first ten users, many steps can be run by hand. You open the account, you issue the invoice, you prepare the report and send it.

That does not change the product the user sees, but it puts off weeks of development. More importantly, it shows which step is actually worth automating. Writing automation for a step nobody uses is the most common waste in MVPs.

There is one limit: a manual step must not delay what the user was promised. If the promise is “instantly”, there cannot be a person waiting behind it.

What cannot be postponed

Not everything can be postponed. Three things, when they are not set up right from the start, cost more to fix later than the product itself.

The first is the data model. In a product that will serve more than one customer, separating data by customer has to be designed in from day one.

The second is identity and permissions. Who can see what is not a feature added later; it is part of every query.

The third is measurement. A product built to test an assumption misses its purpose if it does not record the events that show whether the assumption held.

The five lines of an MVP scope

1. The assumption being tested, in one sentence.
2. The single flow that tests it, step by step.
3. The steps that will be run by hand.
4. What is deliberately postponed, as a list.
5. The measure that shows the assumption held.

The fourth line is the one most often skipped. When the postponed items go unwritten, each one comes back during development as “a small addition”, and the MVP turns into a first release nobody decided on.