Almost every first version of a product starts too big. Each feature on the list feels essential, the launch date moves, and the money runs out before real users have tried anything. The point of a minimum viable product is the opposite: the smallest thing that real users will use, and that teaches you whether the idea works.
Here is how we help founders and product teams cut a first version down to something they can actually launch.
1. Start with one user and one problem
Write one sentence: who the product is for, and what problem it solves for them. “Small clinics that lose bookings because patients cannot book outside office hours” is a scope. “A platform for healthcare” is not. If there are several kinds of users, such as buyers and sellers, decide which side the first version must win.
2. Describe the one journey that must work
Write the main journey step by step, from the user arriving to the moment they get value. For a booking product: find a slot, book it, get a reminder, turn up. Everything in the first version should serve that journey. Features that do not are candidates for later.
3. Rank the feature list honestly
Put every idea on a list, then sort it into three groups:
- Must have: without it, the main journey does not work.
- Should have: valuable soon after launch.
- Could have: worth keeping, not worth delaying the launch for.
A useful test for each “must have”: would a real user refuse to use the product without it? If the answer is “they would be a bit annoyed”, it is a “should have”.
4. Replace features with manual work
Many features can be done by a person behind the scenes at the start. Approving new accounts, sending a weekly report, matching buyers and sellers, issuing refunds: an admin screen or even a spreadsheet can carry these until volume proves they are worth automating. This is often the biggest single saving in an MVP.
5. Use what already exists
Payments, sign-in, email, maps, search and file storage are solved problems. Use proven services instead of building them. Spend the budget on what makes your product different, not on rebuilding a login page.
6. Decide what “good enough” means for quality
An MVP is small, not careless. Security, data protection and the core journey must be solid, because a data leak or a broken payment can end a product. Polish, edge cases in secondary features and admin comfort can wait. Agree this in advance, so the team knows where to spend care.
7. Define what you want to learn
Before launch, write down what would tell you the idea works: sign-ups, repeat use, a number of paying customers, time saved for users. Add the analytics to measure it. Without this, launch day becomes a celebration instead of an experiment.
8. Plan the version after
A good MVP is built so it can grow: sensible architecture, tests on the core journey, and code your team can keep working on. You should not need to throw it away if it succeeds; you should be able to extend it with what users ask for.
A quick check
- Can you describe the user and the problem in one sentence?
- Does every feature serve the main journey?
- Have you replaced features with manual work where you can?
- Do you know what you want to learn from launch?
If the answer to all four is yes, the scope is probably small enough to launch.
We help founders and product teams with product discovery and MVP development: a first version small enough to finish and good enough to sell. See also software development for startups and our guide on how to write a software brief.