What Is an MVP? How to Define the Scope of the First Version
An MVP is not a half-finished product; it is a way of testing an assumption with the least effort. How do you decide what goes into the first version and what does not?
Alp3 min read
An MVP (Minimum Viable Product) is the first version that makes it possible to test the core assumption of a product idea with real users, with the least effort possible. The concept became widespread through Eric Ries's “The Lean Startup” approach, and its purpose is learning, not sales.
What an MVP is not
- It is not a half-finished product. It has few functions, but it performs the functions it has end to end and properly.
- It is not a prototype. A prototype is for demonstrating an idea; an MVP does real work for real users.
- It is not a scaled-down version of the final product. Rather than a version containing a little of every module, it is a version that fully delivers a single value.
Five steps to defining the scope
1. Write down the assumption
Complete the sentence “This user group will use our product to solve this problem.” The MVP's only job is to show whether this sentence is true.
2. Choose a single core flow
Identify the shortest path by which the user gets value from the product. In a reservation product, this is seeing an available time, selecting it and receiving confirmation. Everything outside this flow is a candidate, not a requirement.
3. Prioritize the requests
A common method is to divide requests into four groups: must have, should have, could have and won't have in this version. Only the first group goes into the first version. Shortening the list is hard, but every additional function delays learning.
4. Set the success criterion up front
What will you need to see in order to accept that the assumption has been validated? What proportion of those who sign up complete the core flow, and whether they come back a week later, are good starting criteria for most products.
5. Do not automate work that can be done by hand
For the first users, tasks such as issuing invoices, giving approvals or preparing reports can be carried out by hand for a while. It is safer to invest in automation after the demand has been shown to be real.
What can be postponed and what should not be
| Can be postponed | Should not be postponed |
|---|---|
| Advanced reports and dashboards | Secure sessions and authorization |
| Multiple language and theme options | A properly designed data model |
| Rarely used settings | Backups and error monitoring |
| A detailed admin panel | Basic usage measurement |
| A large number of integrations | Legal requirements for personal data |
The items in the right-hand column are foundations that are expensive to add later. Giving them up for the sake of launching quickly can mean a rewrite when the product grows.
Common mistakes
- Adding functions because competitors have them,
- Launching without setting up measurement and being unable to interpret the results,
- Adding every request to the list instead of changing direction at the first feedback,
- Treating the MVP as “temporary” and disregarding quality entirely.
A good MVP is the answer not to the question “what else can we add?” but to the question “what can we take out and still have something that works?”
If you are planning a subscription-based product, you can see how we build the path from MVP to scalable product on our SaaS product development page.