What Is a Minimum Viable Product (MVP)?
A minimum viable product is the smallest usable version of a product that tests an important business assumption with real users. The scope depends on what you need to learn.
An MVP is a learning decision expressed as a usable product. You choose the assumption that could invalidate the business, then build enough for real users to test it. It is not automatically a subscription app, a particular number of screens or a fixed feature checklist.
Start with the assumption
For a booking product, the assumption might be that owners will use a shared availability calendar instead of a spreadsheet. For a restaurant, it might be that customers will order through a direct website. Those questions need different first releases.
Write the expected behaviour before choosing features: who will use the product, what task they will complete and what result would make you continue or change direction. Payment is a useful test when willingness to pay is the assumption, but not every first experiment requires an integrated billing system.
MVP, prototype and production product
A prototype explores an interaction or demonstrates an idea. An MVP lets people perform the workflow that tests the assumption. A production release adds the reliability and safeguards appropriate to that workflow. These categories can overlap: a small MVP that handles real orders still needs reliable order handling.
The minimum scope should reduce features, not remove necessary access controls, error handling or protection of customer data.
A practical way to cut scope
- Pick one user group and one task.
- Keep the steps required to complete that task.
- Defer extra dashboards, themes, advanced roles and integrations that do not test the assumption.
- Decide how to observe results and collect feedback.
- Set a review point and a criterion for the next investment.
In a restaurant ordering MVP, a menu, cart, order submission and an owner notification may matter more than loyalty points. The Pizzeria Bestek case study shows the operational requirements of a real ordering website; it is an example to inspect, not a universal feature list.
Common mistakes
Building for every possible audience makes it hard to learn what any one audience needs. Calling a broken workflow an MVP produces feedback about bugs instead of demand. Adding features without a learning question increases cost without making the experiment clearer.
For subscription products specifically, see SaaS MVP. For a scoping exercise, use the MVP scope template.