How to Scope an MVP Without Killing the Idea

There are two ways to fail at scoping an MVP, and they look nothing alike. The first is overbuilding: multi-tenant architecture, a permissions system with six roles, an admin dashboard nobody asked for, all built before a single real user has touched the product. The second is underbuilding: cutting so aggressively that what ships doesn't actually demonstrate the thing that was supposed to make the business work.

The test we use is simple to state and hard to apply honestly: what is the one behavior a user needs to experience for this to prove or disprove the core hypothesis? Not "what would make this feel like a real product", that's a longer list, and most of it is deferrable. The core hypothesis is usually one specific thing: that people will pay for this, that they'll use it repeatedly, that it saves them enough time or money to switch from whatever they use today.

Once that's identified, everything else gets sorted into three buckets: required to test the hypothesis, required for basic usability (a password reset flow, for instance, not the hypothesis, but its absence will tank your retention data for reasons that have nothing to do with your idea), and deferred. The deferred bucket is usually 60-70% of what founders initially describe as "the product."

This is uncomfortable because founders are, correctly, attached to their full vision. The MVP isn't a smaller version of that vision, it's the fastest, cheapest experiment that tells you whether the vision is worth building at all. Conflating the two is how six-month builds happen for products that needed six weeks to validate.

The founders who get this right treat the MVP as a question, not a product launch. The ones who get it wrong treat it as a product launch and are surprised when the market's answer to their question costs them a year.