How to Define MVP Scope: Cut Down to What You Can Prove

October 19, 2026 · 6 min read

To define MVP scope, start from the one business question the first release must answer, then keep only the features without which you cannot answer it. Everything else goes on an "out" or "later" list, written down and agreed. The result is a short set of requirements you can estimate and build in weeks, not a smaller copy of the full product.

What an MVP is for

Eric Ries, who made the term popular, defined the minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The key word is learning. An MVP is an experiment with a product attached.

That changes how you scope it. A feature belongs in the MVP if the experiment fails without it. A feature that would make the product nicer, more complete or easier to sell belongs later, however good the idea is.

Two common misreadings to avoid:

• "Minimum" does not mean low quality. The parts you build should work properly. Users who hit bugs teach you about the bugs, not about the product.
• "Viable" does not mean complete. It means a real user can get real value from it, in a narrow case, without your team stepping in.

Start from the question, not the feature list

Most MVP scoping goes wrong because it starts with the full feature list and tries to shrink it. Start instead with one sentence:

We believe [user] will [do something] because [reason]. We will know we are right when [measurable signal] within [time].

Examples:

• "We believe field technicians will close visits on a phone instead of paper, because it saves them the evening paperwork. We will know when 70% of visits in the pilot regions are closed in the app within six weeks."
• "We believe small clinics will book a paid onboarding call after a free trial, because setup is the main hurdle. We will know when 1 in 10 trial sign-ups books one within a month."

The numbers in these examples are illustrations. Pick your own threshold before launch, so the result cannot be argued afterwards.

This sentence comes straight out of discovery: the problem statement says who is affected and why, and the goals give you the metric. If you cannot write it, the MVP is not ready to scope. You still need the discovery work, which the discovery phase in software development covers.

Cut-down questions for every feature

Take each candidate feature and ask these questions in order. Stop at the first one that removes it from the MVP.

1. Does the business question fail without it? If the experiment still works, it is not MVP scope.
2. Can a person do it by hand for now? Manual onboarding, a spreadsheet report, an admin who approves accounts by email. If a human can cover it for the first hundred users, do not build it yet.
3. Can an existing tool do it? Payments, email, sign-in and analytics rarely need to be built for an MVP.
4. Can it be narrower? One user type instead of three, one region, one language, one payment method, one platform.
5. Is it a constraint you cannot negotiate? Legal, security and data-location requirements stay in, however small the MVP. "Data stays in the EU" is not optional just because it is a first release.
6. What does it cost compared with what it teaches? A feature that takes a third of the budget and tests a side question should wait.

Question 5 is the one most often skipped. A non-functional requirement such as working offline, or a constraint such as where data is stored, can be the most expensive line in the MVP and still be required.

In, out and later

Write the result as three lists and get them agreed. The "out" and "later" lists matter as much as the "in" list, because they are what stop scope from creeping back.

If you use MoSCoW priorities, "in" is roughly your Musts, "later" your Shoulds and Coulds, and "out" your Won'ts for this release. DSDM guidance, where MoSCoW comes from, is often summarised as keeping Musts to no more than about 60% of the effort, so there is room to drop Shoulds and Coulds if the schedule slips. In an MVP the Musts are usually closer to the whole release, which is exactly why the list has to be short.

This is what that looks like in the requirements of the Discovery Phase AI example report, made for an invented field-service project called Fieldwise. Most rows are Musts, one is a Should, and the EU data rule appears as a Constraint rather than a feature:

Turning the MVP into requirements and an estimate

The three lists are a decision. To build from them, turn each "in" item into a requirement a developer can test:

• A short title and one sentence: "A technician records work done, parts used, photos and a customer confirmation, then closes the visit."
• Type: functional, non-functional or constraint.
• Priority: Must for everything on the "in" list. If something on it feels like a Should, it probably belongs on "later".
• Acceptance criteria: how you will know it works. "A visit closed offline appears on the dispatcher's board within one minute of coverage returning."
• The goal it serves: every requirement should trace to the business question. One that does not is a sign that scope crept back in.

Then estimate in ranges, not single numbers, with the assumptions written next to them: team size, which integrations exist, what you are handling manually. If the range is larger than the budget, go back to the cut-down questions, not to the estimate. Squeezing the estimate is the slow way to cut scope; cutting a feature is the fast one.

Finally, write the date or signal at which the MVP will be judged and what happens next for each outcome: build the "later" list, change direction, or stop. That decision is what the MVP is for.

The discovery phase template has the requirements and roadmap sections in a form you can copy. The discovery phase checklist has the questions to check them against before the build starts.