Every MVP conversation starts with a long feature list. The useful question is not “what can we build in ten weeks?” but “what must be true after launch for us to learn something real?”
Name one primary outcome
Examples: “Clinic can publish slots and receive bookings” or “Fleet manager sees live driver status.” If the outcome needs three unrelated wins, it is not one MVP — pick the riskiest assumption first.
Write non-goals in the brief
Explicit cuts prevent scope creep: no admin analytics, no multi-language, no custom branding in v1. Stakeholders sign non-goals, not just goals.
Vertical slice over horizontal layers
A thin path through auth, data, and UI beats a perfect design system with no working flow. Polish follows proof.
Plan the second release before launch
Knowing what v1.1 contains reduces panic feature requests during UAT. Teams ship calmer when the roadmap is visible.
Measure one metric
Pick completion rate, time-to-first-value, or conversion — not twelve dashboards. Instrument it before launch, not after complaints.
MVPs fail when they try to be small products instead of learning tools. Scope ruthlessly, ship honestly, and iterate with data — not guilt.