Most MVPs are scoped in the same wrong direction. The cut rule is a single question: if this feature is missing on launch day, can the core hypothesis still be tested? Apply it honestly to a forty-feature list and you will find ten. Three questions applied in order will find the real eight.
This is not pessimism about product ideas. It is what happens when you treat the first version as a hypothesis test rather than a product launch. An MVP does one thing: generates evidence about whether your core assumption is true. Every feature that doesn't directly contribute to that test is pre-emptive — and pre-emptive work is what turns six-week builds into six-month ones.
How do you know your MVP is too big?
Three signals, each reliable on its own.
You can't describe it in one sentence. If the pitch requires "and then" more than once, you are describing multiple products. An MVP solves one problem for one user in one context. When the description needs preamble before the preamble, the scope is wider than the hypothesis.
No single feature owns the test. Every MVP is a test of one core assumption — the thing that, if true, makes the bet worth making. If you can't point to one or two features that directly surface evidence on that assumption, everything else is polish for a product that hasn't been validated yet.
Your build estimate is six months or longer for zero revenue. A well-scoped MVP at genuine product complexity runs 6–16 weeks with a competent team. Past that, the issue is almost never complexity. It is scope — features added to answer questions that first users haven't asked.
The three questions a feature must survive
Apply them in order. A feature that fails any one doesn't ship with the first build.
1. Does this feature let you test the core hypothesis?
The hypothesis is the one thing you need to learn: does this type of user want this solution to this problem badly enough to actually use it? If the feature doesn't generate direct evidence on that question, it is roadmap, not MVP.
2. Can the core experience exist without it?
This is not about desirability. It is about function. If a user could still reach the core feature, use it, and form an opinion about whether it solves their problem, the feature is optional at launch. Notification systems fail this test for most products. So do admin dashboards, export functions, and the mobile app for nearly every web product in the first build.
3. Did a real user ask for it?
There is a sharp difference between "five early users specifically requested this" and "this seems like something users would want." The second category is where most bloated feature lists live. Pre-answering questions users haven't asked is the defining habit of overscoped builds.
The audit table
Run every feature through this before a developer quotes the build.
| Feature | Tests hypothesis? | Needed for core UX? | User confirmed? | Ship? |
|---|---|---|---|---|
| Core workflow | Yes | Yes | Yes | Yes |
| Notifications | No | No | Rarely | No |
| Admin dashboard | No | No | Rarely | No |
| Mobile app | No | No | Sometimes | No |
| Export / reporting | No | No | Rarely | No |
| Social login | No | No | No | No |
| Onboarding flow | Sometimes | Sometimes | No | Trim to minimum |
The first column is the hardest one to be honest about. Most founders mark it Yes more often than the evidence warrants.
What the number actually looks like
On LaunchProd, the initial spec had forty-two items. After this exercise, four features went into the first shipped version — not four categories, four features. Thirty-eight were either untested assumptions, pre-emptive v2 work, or polish for a product with no users yet.
The product shipped in nine weeks. Those thirty-eight features were never rebuilt. Once users arrived, it was clear they didn't need them.
This is not a lucky outcome. It is what happens when you apply the three questions before you write a line of code.
What happens to the features that don't make it?
Write them down. Separate document. Revisit when users give you signal that they need something on the list.
A feature on a list costs nothing. A feature in a build costs development time, test time, and permanent maintenance overhead for every engineer who reads the codebase after you. The first version exists to answer a question. Once you have users, you will know which features on the deferred list actually matter — and it is almost always fewer than you expected.
The scope session at the start of an engagement is where this exercise happens — before a developer is hired, before a timeline is set, before anything is built. That is the right moment to run the cut. The wrong moment is six months in, when the build is overdue and the founder is still adding features.
Written 2026-07-07 by Naman Barkiya.