How to scope an MVP that actually tests your idea

An MVP is not a smaller version of the final product. It is the smallest product that can answer the question you are most unsure about. Getting that distinction right is the difference between a first version that teaches you something and one that just burns runway.

Start with the riskiest assumption

Write down every assumption your business depends on. Then rank them by two things: how uncertain you are, and how badly the business breaks if you are wrong. The top item is what your MVP must test.

• Demand risk — will people want this? Test with a landing page, a concierge service, or a narrow product for one segment.
• Usability risk — can people use it? Test with a clickable prototype before code.
• Feasibility risk — can it be built? Test with a technical spike, not a full product.
• Viability risk — will they pay enough? Test with real pricing on day one.

Cut by journey, not by feature

Instead of listing features and crossing some out, map the single journey that proves your assumption — sign up, do the core thing, get the result — and build only what that journey needs. Everything else goes into a ranked backlog.

Don't cut the boring parts

Authentication, payments, an admin panel and analytics feel unglamorous, but they are what let you run the product and learn from it. An MVP without analytics answers no questions.

Decide what success looks like before launch

Write the metric and threshold that would make you continue, pivot or stop. If you only decide after launch, every result will look encouraging.

A checklist

1. One riskiest assumption, written down.
2. One core journey that tests it.
3. The operational basics: auth, payments if relevant, admin, analytics.
4. A success metric decided in advance.
5. A backlog for everything else.