How to scope an MVP: what to build first and what to leave out

Start with the question

Every new product rests on a belief that has not been tested. People will pay for this. Businesses will switch from what they use now. Drivers will accept jobs through an app.

Write down the one belief that, if it turned out to be wrong, would end the idea. That is the question your MVP has to answer. Everything in the scope should help answer it, and anything that does not can wait.

Find the one journey

Trace the shortest path a user takes from arriving to getting the value you promise. A customer finds a service, books it and pays. A manager uploads a document and gets a summary. That path is the MVP.

Build that journey properly, from the first screen to the last, and resist adding a second journey until the first has been used by real people.

What to leave out

• Admin panels. For the first weeks, a database tool or a spreadsheet does the job.
• Several user roles and permission levels, unless the question depends on them.
• Settings and preferences. Choose sensible defaults.
• Automated billing, if you can invoice the first customers by hand.
• Native mobile apps, if a web app that works well on a phone answers the question.
• Integrations beyond the one the journey cannot work without.
• Handling for scale you do not have yet.

None of these is unimportant. They are simply not what you are trying to learn first.

Do it by hand first

A surprising amount of a product can be done manually behind the scenes while you learn. Matching customers to suppliers, approving sign-ups, sending reports: a person can do these for the first fifty users.

The user sees a working product. You find out whether they want it before you spend money automating it, and you learn exactly what the automation needs to do.

Decide what a yes looks like

Before launch, agree on the result that would count as a yes. How many people complete the journey. How many come back within a week. How many pay.

Pick one or two measures, set the number, and build the tracking into the product from the first day. Without this, launch produces opinions. With it, launch produces evidence.

Where not to cut

• The quality of the core journey. If it is confusing or slow, you will not know whether people rejected the idea or the execution.
• The security of user data and payments.
• The measurements that answer your question.
• The basic structure of the data, which is costly to change once real users depend on it.

Minimum describes the scope. It does not describe the care taken over the parts that are in it.

How long it should take

We usually build an MVP in six to twelve weeks. If a scope does not fit in that range, it is often trying to answer more than one question, and it is worth splitting.

The first version is not the end of the work. It is the point at which you stop guessing and start deciding what to build next from what real users did.