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 Two Ways Founders Get This Wrong

Overbuilding rarely announces itself as overbuilding, it shows up disguised as diligence. The symptoms are consistent enough to recognize in advance:

• Building infrastructure for a scale you don't have yet (multi-tenancy, complex role permissions, horizontal scaling) before proving anyone wants the product
• An admin panel with more functionality than the customer-facing product, because it felt more concretely useful to build
• "We might need this later" as the justification for a feature, rather than a specific near-term requirement
• Months spent on integrations or edge cases before the core workflow has been used by a single real customer

Underbuilding is the opposite failure, but just as damaging: it produces a demo instead of a product. Its symptoms:

• Cutting a feature that's actually part of the core hypothesis because it was hard to build, not because it was optional
• Shipping without basic usability (password reset, empty states, error handling) and blaming poor retention on the idea instead of the execution
• A v1 so thin that early users can't tell what problem it's supposed to solve for them

The One Question That Actually Matters

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, and it looks different depending on the type of business:

• Marketplace: will a supplier and a buyer both show up and complete a transaction without heavy manual matchmaking?
• B2B SaaS: will a team actually change a daily workflow to use this, or will it get used once and abandoned?
• Consumer app: will someone come back a second time without being reminded to?

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, one of those is the actual hypothesis. Everything in the product either tests it or doesn't.

Sorting Everything Into Three Buckets

Once the hypothesis is identified, every feature on the wish list 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."

A Worked Example

Take a hypothetical scheduling SaaS for service businesses, its core hypothesis is that customers will book appointments online without a phone call, and businesses will save enough admin time to pay for it. Sorting a typical feature wish list against that hypothesis looks something like this:

• Required to test the hypothesis: a public booking page, a calendar view, automatic confirmation emails
• Required for usability, not the hypothesis: password reset, a way to cancel or reschedule, basic error states
• Deferred: multi-location support, staff-level permissions, SMS reminders, custom branding, reporting dashboards

Almost every one of those deferred items feels essential to the founder describing their full vision. None of them determine whether a customer will actually book online instead of calling. That's the distinction the exercise forces.

Why This Feels Uncomfortable, And Why That's A Good Sign

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.