How do you scope an MVP correctly?
The right MVP scope is defined by the riskiest assumption you need to kill, not by the smallest version of your full product. Most teams build too much because they confuse "minimum" with "incomplete" — the real job is to identify the single most dangerous unknown and build only what forces a real answer. Scope is not a product decision; it's an epistemological one.
Start with the question, not the feature list
Before writing a single line of code, write down the one thing that would kill your startup if it turned out to be wrong. This is your scoping constraint. If you can't name it in one sentence, you're not ready to build yet — you're still in idea space.
Garry Tan's engineering judgment, compressed in the gstack framework, emphasizes that context must drive every implementation decision: what exists today, why it's insufficient, and who is actually affected. The same discipline applies to MVP scoping. A feature without a clear "why now" and a named stakeholder problem is scope creep before you've even shipped.
That means your MVP doc shouldn't start with a feature list. It should start with: the assumption you're testing, the user behavior that would confirm or deny it, and the minimum surface area of product needed to trigger that behavior. Everything else is waste — not technically, but strategically.
Separate what you're learning from what you're building
There are two failure modes in MVP scoping. The first is building too much — including features that feel essential but don't test the core assumption. The second is building something so stripped-down that real users can't engage authentically with it, which gives you garbage signal.
The distinction that resolves this tension: separate the learning goal from the delivery artifact. The learning goal is the hypothesis you're validating (e.g., "enterprise ops managers will change their workflow to get real-time inventory alerts"). The delivery artifact is the smallest possible experience that puts a real user in a real situation where that hypothesis is tested under real conditions.
This means some features that feel "non-MVP" are actually load-bearing for valid signal. If your hypothesis requires that a user trusts the data, you may need to build a basic data integrity layer even in v0 — not because it's a feature, but because without it the test is contaminated. Scope decisions made on this basis are defensible. Scope decisions made by guessing which features "feel" core are not.
Apply effort decomposition to every proposed scope item
One of the most underrated scoping tools is honest effort breakdown — not a total estimate, but a per-component breakdown. A feature estimated at "two weeks" often decomposes into two days of UI, three days of backend logic, four days of edge case handling, and three days of testing and QA. That decomposition reveals which components are load-bearing for the test and which are just polish.
The gstack engineering framework makes this explicit: breaking effort by component (schema, service layer, tests, frontend) enables both planning and task splitting. For MVP scoping, the same decomposition lets you ask: which of these components is genuinely required to get valid user signal, and which is required to feel like a real product? Honest answers to that question routinely cut 30–50% of scope without compromising the learning objective.
The practical move: for each proposed feature, write out its component breakdown, then ask whether removing or stubbing each component would invalidate the test. If stubbing the backend with hardcoded data still produces authentic user behavior, do that. If it would make the test a theater exercise that tells you nothing, build the real thing. The framework keeps you honest about which corners are actually safe to cut.
Define done before you start, and name what's not included
Scope creep during an MVP build almost always originates from an undefined completion condition. Teams that start building without a crisp "done" definition end up in perpetual polish mode, adding edge case handling and secondary flows that feel important in the moment but push the launch — and the learning — indefinitely into the future.
Write a one-page MVP spec that includes two sections most teams skip: a "not in scope" list with explicit reasons, and a defined success condition stated as user behavior, not feature completion. "Done" is not "the feature is built." Done is "we have ten users who went through the core flow and we observed whether X happened." When the team has this written down before building starts, every scope addition has to pass the test: does this change what we'd observe in those ten sessions? If not, it's not in scope.
The rollback equivalent for product scope: decide in advance what you'll cut if you're two weeks from your target launch and still not done. Naming the fallback scope explicitly — before you need it — prevents the panic compromises that produce genuinely broken MVPs. A staged scope plan (full version, acceptable version, minimum valid version) lets you ship on time without abandoning the learning objective.
The common mistakes that bloat or break MVP scope
The most common scoping error is confusing MVP with beta. An MVP is an instrument for learning; a beta is an early version of a product you're mostly confident about. When founders treat an MVP like a beta, they feel obligated to handle all the edge cases and polish the experience — because they're imagining real customers, not test subjects. This is a category error that consistently produces over-built MVPs that take three times as long and tell you half as much.
A second failure pattern: scoping by what competitors have, rather than by what your hypothesis requires. The fact that a competitor's product has five core features doesn't mean your MVP needs to match that surface area. Your job is to test whether your specific insight — the thing you believe that they don't — is real. That insight rarely requires feature parity to validate.
A third pattern worth naming: building for the demo rather than for the test. Demo-driven scope optimizes for a convincing walkthrough of a happy path. Test-driven scope optimizes for encountering the real friction points and behavioral choices that reveal whether your assumption holds. These produce different products. The demo-optimized MVP will look better in a pitch and teach you almost nothing about whether the business works.
“Frame from the stakeholder perspective — who is affected and why they care.”
— Garry Tan, source
The one thing to do
Write the one assumption that would kill your startup if wrong, then build only the minimum surface area needed to force a real user to confirm or deny it — anything else is out of scope.
Frequently asked questions
How do you know when your MVP is too small to generate valid signal?
If the experience you're testing is so stripped down that users are reacting to the incompleteness rather than the core proposition, you've cut too much. The test is contaminated when users are evaluating the prototype rather than making authentic behavioral choices about the underlying product idea.
Should your MVP include onboarding and documentation?
Only if confusion in those areas is what would invalidate the test. If you can white-glove your first users through setup manually and still observe the behavioral signal you need, do that — it's faster and you learn more from the conversation. Build self-serve onboarding when you're validating scale, not the core assumption.
How do you handle stakeholders or investors pushing for more features in the MVP?
Reframe the conversation around the learning objective, not the feature count. Ask: which specific assumption would the additional feature help us test? If the answer is the same assumption the simpler version already tests, the feature adds cost but not clarity. Feature requests that can't be tied to a testable hypothesis are out of scope by definition.
What's the right size for an MVP team?
Small enough that every person on the build has the learning objective memorized and can articulate it unprompted. If team members are making daily implementation decisions without knowing what behavior you're trying to observe in users, the team is too large or the objective is too unclear — and usually both.
Sources
- gstack: spec/SKILL.md — Garry Tan