How to plan an MVP in five simple steps

Most people plan an MVP the wrong way. They list everything the product will do one day. Then they remove items until it fits the budget. The result is a smaller version of the full product, still built on guesses.

A better way starts from the other end. What are you least sure about, and what is the smallest thing that would tell you?

Step 1: Write down your guesses

Every product idea is built on guesses. Write them as simple sentences:

• "Site managers will log jobs on their phones."
• "Customers will pay every month instead of each time."
• "Clinics will let us connect to their booking system."

Try to write ten to fifteen. Include guesses about users, price, how you will reach people and the technology.

Step 2: Find the riskiest guess

For each guess, ask two questions. How likely is it to be wrong? How bad would it be if it were wrong? The guesses that score high on both are the ones your MVP must test. Usually there are only one or two.

Step 3: Design the smallest real test

Ask: what would a user need to do in a working product to prove this guess? That journey, from start to finish, is your MVP. Build it properly. Everything else is done by hand for now, or left for later.

A clickable prototype can help here. This is a set of screens that looks real but has no code behind it. Show it to five or six target users before you build. It often finds big problems for very little cost.

Step 4: Decide what success looks like, before you build

Choose the numbers that will tell you to continue, change or stop. For example: "At least 4 in 10 invited users finish their first job in the app within a week." If you write this down before launch, nobody can explain away the results later.

Step 5: Cut, then cut again

Go through your feature list one more time. For each feature, ask: does this help test the riskiest guess? These things can usually wait:

• Big admin dashboards (a simple back office or a spreadsheet works at first)
• Many types of user and permission
• Connections to other systems that you can do by hand for a while
• Settings and personal options

These things should not be cut: a clear sign-up, the main journey done well, basic analytics and good security.

Your MVP on one page

At the end, you should be able to describe your MVP on one page: who it is for, the guess it tests, the one journey it supports, how you will measure success, and what you are leaving out on purpose. If it does not fit on one page, keep cutting.

Next steps

We use this method in the first week of every MVP45 project. The scope, the timeline and a fixed price are agreed in writing before we build. Read more about our MVP development, or talk to us for a second opinion on your plan.