An MVP is not the first version of everything you plan to build. It is the smallest product that lets real users do something meaningful, so you can learn whether the idea works before investing in the rest. Deciding what to leave out is the main skill.
Start with the question the MVP must answer
Every new product rests on assumptions: that a particular group has a problem, that they will use this solution, and that they will pay for it or change how they work. Identify the assumption that, if wrong, would sink the idea. The MVP should test that assumption directly. Writing it as a question, such as “will clinic managers book appointments through a portal instead of by phone?”, keeps the scope honest.
Map one core journey end to end
Pick the single journey that delivers the product’s main value and map it from the first screen to the result the user wants. Everything on that path is a candidate for the MVP. Everything off it, such as advanced settings, secondary user types or rare edge cases, can usually wait.
- Who is the first user, specifically?
- What triggers them to use the product?
- What steps do they take, and what do they get at the end?
- What must happen behind the scenes for that result to be real?
Prioritise with a simple rule
Sort each candidate feature into must have, should have and later. A feature is a must have only if the core journey fails without it. Be wary of features added to reassure stakeholders rather than to serve the first users. Manual work behind the scenes, such as an administrator approving accounts by hand, can often stand in for automation until you know the product is worth automating.
Build so that the next step is easier
An MVP should be small, but it should not be a dead end. Choose a technology stack the team can grow, keep the code tested and readable, and record the shortcuts taken so they can be revisited. This avoids a rewrite just when the product starts to gain traction.
Decide in advance how you will judge it
Agree what signals mean the idea is working: sign-ups, completed journeys, repeat use or direct feedback. Plan how you will collect them, and set a date to review the results and decide whether to continue, change direction or stop.
What this means for your business
A clear learning goal, one core journey and a firm line between must have and later are what make an MVP useful. Our MVP development page explains how we help shape and build a first release, and our software project planning guide is a useful checklist before you start.
