How to Define MVP Scope
An MVP is not a small version of your product. It is the smallest thing you can build to test your riskiest hypothesis. Most teams build MVPs that are too large because they confuse minimum viable product with minimum feature set.
This guide covers how to scope an MVP that tests a hypothesis rather than just shipping fewer features.
Step-by-step guide
Step 1: Start with the hypothesis, not the feature list
Write your hypothesis: We believe [target users] will [behavior] if we [build this]. The MVP is whatever it takes to test this hypothesis. If you can test it with a landing page, your MVP is a landing page. If you need a working prototype, your MVP is a prototype. Do not start from a feature list and cut down.
Step 2: Identify the riskiest assumption
Every product idea has assumptions: users have this problem, they will pay for a solution, they will adopt this approach. Identify the assumption that, if wrong, kills the entire idea. Your MVP tests that assumption first.
Step 3: Apply the cupcake model
Do not build a partial car. Build a skateboard that provides complete (if basic) transportation. Each version delivers a complete experience at increasing quality: skateboard, scooter, bicycle, car. The MVP is the skateboard.
Step 4: Use the must-have test
For each proposed feature, ask: if we launch without this, will users reject the product? If yes, it is in scope. If no, it is out. Be honest: most features are nice-to-have, not must-have.
Step 5: Set a time constraint
MVPs should ship in 4-6 weeks. If your scope takes longer, cut more. The time constraint forces ruthless prioritization. If your team says the MVP takes 3 months, you have not cut enough.
Common mistakes
Building a minimum product instead of a minimum viable product
The V in MVP matters. The product must provide enough value that users engage with it and generate meaningful data. A product so stripped down that nobody uses it teaches you nothing.
Adding just one more feature before launch
Feature creep is the MVP killer. Once you have defined the scope, freeze it. New ideas go on a list for v2.
Tips
- Write the launch email before you start building: if you cannot describe the value proposition, you are not ready to build
- Define your success and failure criteria before building so you know what to measure
- Share the MVP scope with 5 target users and ask: Would you try this? Their reaction is the first data point
How Vantage helps
Vantage generates PRDs with structured requirements that make scope visible. When you need to cut an MVP down, the prioritized requirement list shows exactly what is P0 (must-have) versus P1 (next version). This makes scope decisions explicit rather than emotional.