Key answer: A good MVP is the smallest version of a product that solves one key user problem well enough to measure whether the idea works. Planning starts from a hypothesis to verify (not a feature list), and the scope is set by one question – "without what does the product make no sense in the first week of use?"
Table of contents
The short answer
An MVP (minimum viable product) is the smallest version of a product that genuinely solves a problem and lets you measure whether the idea works. Both halves matter: a hollow shell verifies nothing, and a feature-packed combine harvester verifies too late and too expensively.
The most expensive mistake: building a wish list
The typical story: a founder has a vision, writes down the features, gets a quote, trims a little "for later" – and builds for twelve months. Launch. Silence. Users touch 20% of the features, and the key hypothesis ("will anyone pay for this?") still awaits its answer – except the budget is gone.
The problem isn't the execution; it's the starting point: an MVP is planned from a hypothesis, not from a feature list.
Step 1: name the hypothesis
Complete the sentence: "We believe that [who] has the problem [what] and will pay for [solution]". Example: "We believe small accounting firms lose hours manually reminding clients about documents and will pay to automate that process."
Everything follows from a well-named hypothesis: who the first user is, what the product must do – and, just as important, what it doesn't have to do.
Step 2: find the core
For every feature on the wish list, ask: "without this, does the product make no sense in the first week of use?". The answers sort features into three baskets:
- Core: no product without it (in our example: client list, reminder schedule, sending).
- Boosters: helpful, but they can wait (statistics panel, accounting integration, mobile app).
- Fantasies: "wouldn't it be cool if" (AI predicting delays, a template marketplace).
Brutal practice: the core is usually 20–30% of the original list. And it is enough – early users forgive missing statistics, but they don't forgive a weak core.
Step 3: prototype before code
Before a line of code exists, a clickable prototype of the key flows tested with five users will catch most wrong assumptions. Cost: days of work. The same discoveries in a working product cost weeks. In our anonymised SaaS case study, prototype testing overturned two flows that looked great on paper.
Step 4: plan measurement before launch
An MVP without a measurement plan is a shot in the dark. Before release, decide: what signals success (activation? second-week return? payment?), what numbers count as "it works", and build product analytics in from day one.
The usual traps
- The monster MVP: a "minimal version" built for 18 months. Antidote: a hard 3–6 month horizon.
- The hollow MVP: so much cut out that the product doesn't solve the problem and only "verifies" that nobody wants a husk.
- Cutting quality instead of scope: a slow, buggy product tests patience, not the hypothesis. Cut features, never core quality.
- No decision owner: MVP scope drifts when every stakeholder adds "just one more thing".
Where to start
With a scoping workshop: a day or two with the decision-makers, producing the hypothesis, the feature core, flow sketches and a realistic budget. That is exactly how we start product projects at Sweet Lava – see the process, or simply tell us about your idea.