After the MVP: how to decide what to build next

Read the evidence first

An MVP is built to answer a question, so begin with the answer. Did people complete the main journey? Did they come back? Did they pay, or say they would?

Look at behaviour before opinions. People are generous in conversation and honest in what they do. A feature everyone asks for and nobody uses is common, and so is a feature nobody mentions that everyone depends on.

Find where people drop out

Follow the main journey step by step and count how many users reach each stage. There is nearly always one step where most are lost: sign-up, the first setup, the payment screen.

Fixing that step is usually worth more than any new feature, because every improvement there applies to everyone who arrives afterwards. It is rarely the most interesting work on the list, which is why it gets postponed.

Treat requests as clues

When a user asks for a feature, ask what they were trying to do when they wanted it. The request describes their idea of a solution. The underlying problem is what you need.

• Several different requests often point at the same problem.
• The loudest users are not always typical of the rest.
• A request from a customer who pays weighs more than one from a visitor who left.

Three directions

• Improve. The core idea works, and the task is to make the main journey smoother and more reliable.
• Expand. The core works well for one group, and the next step is a nearby group or a second use.
• Change direction. The evidence says the original idea is not what people want, but something next to it is.

A change of direction is not a failure of the MVP. Finding it out in weeks and not years is exactly what the MVP was for.

Repay what you borrowed

A good MVP takes shortcuts on purpose: manual steps behind the scenes, a simple admin process, no handling for large volumes. Once the idea is proven, some of those shortcuts become the thing holding you back.

List them, and replace the ones that now cost you time every week. Leave the rest. Rebuilding everything to a high standard before you know what the product will become is the same mistake as over-building the first version.

Plan in short rounds

Keep the habit that made the MVP work. Choose one thing to learn or improve, build the smallest change that tests it, release it, and look at what happened.

A long roadmap written the week after launch is a guess. A short one, revised every few weeks against real use, is a plan.