The most common problem with an MVP isn’t technical. The feature list grows at every meeting, because each feature seems essential, and a few months later you have a product that does many things in a mediocre way and doesn’t answer the most important question: does anyone want to use it.
Start with a hypothesis, not features
Before you list features, write down in one sentence what the MVP is meant to test. For example: “Project managers at construction companies will report progress by phone every week instead of emailing spreadsheets.”
Add a metric that will confirm or refute the hypothesis. Not “users like it” but a behavior you can count: how many of the invited users came back in the second week, how many reports were created, how many companies want to pay.
One path from start to finish
An MVP should let a user walk one main path from the first screen to the result they came for. It’s better for one path to work completely than for five to work halfway.
List every feature that comes to mind and put each one in one of three groups:
- Essential for the main path. Without them the user can’t reach the result.
- Done by hand. Things a person can do behind the scenes at first: setting up accounts, sending reports, handling payment by invoice.
- Later. Everything else.
The second group is the most valuable. Serving the first customers by hand takes time, but it shows what’s actually worth automating.
What you can usually postpone
- An extensive admin panel. At first, a simple data view or direct database access for the team is enough.
- Roles and permissions. One account type is often enough for the first tests.
- Languages. Unless you’re testing the product in several markets at once.
- Notifications across many channels. Email is enough.
- Native apps. If the main path works in a phone’s browser, an app store app can wait.
- More integrations. One, the most important one, is usually enough.
What not to postpone
“Minimum” refers to scope, not quality. Even the first version needs:
- secure login and data protection, because a breach in an MVP is just as real as in a mature product,
- analytics that measure the hypothesis metric, because without it the MVP tests nothing,
- a polished main path, because users judge a product by what works, not by the roadmap,
- basic accessibility and a privacy policy.
Prototype first
Before writing code, test the main path on a clickable prototype with a few people from the target group. A change in a prototype costs a fraction of a change in code, and the first conversations usually change the order of the screens and what the user wants to see first. We described who to talk to and what to ask in the article on B2B personas.
Fixed time, flexible scope
It works best to fix the deadline and budget up front and treat scope as the variable. If something turns out harder than expected, it drops out of the first version instead of pushing back the launch. With us, an MVP is usually 6–8 weeks: one user path, one integration and deployment to production.
After launch
A few weeks after launch, go back to the hypothesis and the metric. There are three honest decisions: build on it, change direction or stop. Each of them is an MVP success, because each was made on data rather than gut feeling.
If you’re planning a digital product and want to scope its first version, see how we build apps and SaaS.
Let’s talk about your project
The first call takes 30 minutes and is free. After it, you know whether we can help and what it will cost.
Book a call
