A minimum viable product is not a small version of the finished product. It is the cheapest thing you can build that answers the question you are least sure about. When teams skip that distinction, the MVP grows into a six-month project that launches late, costs more than planned and still leaves the important question unanswered.
This is the method we use with founders and product teams to keep a first release focused.
Start with the bet, not the feature list
Every new product rests on a handful of assumptions. Write them down as plain statements:
- Customer: small clinics will book patients online if it takes less than a minute.
- Problem: missed appointments cost them enough to pay for a fix.
- Solution: automated reminders reduce missed appointments.
- Business: clinics will pay a monthly fee per location.
Now rank each assumption by two questions. How much evidence do we already have? And if we are wrong, does the whole idea fall over? The assumptions that score low on evidence and high on impact are what the MVP exists to test.
Turn the riskiest assumption into a question
A useful MVP question is specific and has an answer you can measure within weeks. "Will people like it?" is not a question. "Will at least 30% of patients at three pilot clinics book online in the first month?" is.
Write the question down with a threshold before you build anything. It forces agreement about what success looks like and stops the goalposts moving after launch.
Cut scope with three lists
With the question agreed, sort every proposed feature into one of three lists:
- Needed to answer the question. Without it, you cannot run the test.
- Needed to be safe and legal. Security, data protection, accessibility and anything a regulator would expect.
- Everything else. Useful, possibly important later, but not needed now.
Only the first two lists go into the MVP. The third becomes the backlog you revisit once you have evidence. In our experience, this exercise removes between a third and a half of the original scope.
Fake what you can, build what you must
Many parts of a product can be handled manually at first. An admin dashboard can be a shared spreadsheet. A recommendation engine can be a person making choices behind the scenes. Payments can be invoiced by hand for the first ten customers.
This is sometimes called a "concierge" or "Wizard of Oz" approach. It is not cutting corners: it is spending engineering effort only where it changes the answer to your question.
What you should not fake is anything that affects trust. Logins, data handling and the core experience your customers touch need to be built properly from the start.
Choose a foundation that can grow
A focused MVP does not have to mean throwaway code. We choose a mainstream stack, set up automated tests and deployment from the first week, and keep the data model clean. If the experiment succeeds, you build on it. If it fails, you have spent weeks rather than months finding out.
Plan the learning, not just the launch
Before release, decide how you will measure the outcome. Set up analytics events for the key actions, schedule conversations with early users, and agree a date to review the evidence. Then make one of three decisions: continue, change direction, or stop.
That review is the real deliverable of an MVP. The software is simply the instrument that made the measurement possible.
A realistic timeline
For most business products, this approach produces a working MVP in six to ten weeks:
- Week 1 to 2: assumptions, question, scope and a clickable prototype tested with users.
- Week 3 to 8: build in two-week sprints with a demo at the end of each.
- Week 9 to 10: pilot launch, measurement and the first review.
If you are planning a new product and want help shaping the first release, our MVP and product strategy service is designed for exactly this.