How to scope an MVP so it actually ships

Projects are rarely killed by bad engineering. They are killed by a scope nobody agreed on, discovered in week six, when changing it costs four times what it would have cost in week one.

Reading time · 7 min

Scope is a decision problem, not an information problem

Teams usually believe they need more research. Almost always they need fewer open questions. The list of things the product might eventually do is not hard to produce — every stakeholder has one. The hard part is deciding which small subset is worth shipping first, and saying so in a way that survives the next meeting.

A useful discipline: for every feature, ask what you learn by shipping it. A first release exists to answer a question — will people use this, will they pay, does the operation actually run on it. Anything that does not help answer that question is not an MVP feature, however reasonable it sounds.

The second discipline is sequencing. What has to exist before anything else can be tested? What can wait without forcing a rebuild later? Those are different questions from "what is most important", and confusing them is how teams end up building the admin panel before they know whether anyone wants the product.

Write the deferred list down

The cut features are more politically dangerous than the kept ones. If "we will do that later" lives only in someone's memory, it comes back in week six as a surprise, usually from whoever was least present when the decision was made.

So write them down, next to the reason each was deferred and what would have to be true to bring it forward. A visible deferred list converts an argument about scope into a conversation about sequence, which is a far easier conversation to have.

This is also what makes a quote meaningful. A price attached to a scope with an explicit exclusion list is a price you can hold someone to. A price attached to "the product" is a negotiation that has not happened yet.

Name the assumptions that could move the number

Every estimate rests on assumptions, and most go unstated — that a third-party integration works as documented, that the client can supply content by a given date, that a regulatory requirement is what everyone believes it is.

Writing them down does two things. It tells the buyer which risks are theirs, and it turns a scope change from a dispute into an arithmetic exercise: this assumption turned out false, here is what that moves. It also surfaces the one or two that deserve investigating before the estimate is given at all.

Bilingual delivery belongs in this list whenever it is in play. Retrofitting right-to-left support into a product designed left-to-right is not a translation task — it touches layout, iconography, input handling and formatting at once, and it is dramatically cheaper to decide at the start.

What a scoped plan should contain

The question the first release exists to answer.
An explicit feature list for release one, short enough to be uncomfortable.
The deferred list, with a reason beside each item.
A sequence, with the dependencies that drive it named.
The assumptions behind the estimate, written where the buyer can see them.
An honest note on what is risky, including anything that argues against building.

Common questions

How long should scoping take?

For a first release, about a week is usually right — the constraint is decisions, not information. Where a product depends on an integration or a regulation that needs real investigation, that should be flagged at the first call rather than at the end.

What if stakeholders will not cut anything?

Then sequence rather than cut. Agreeing an order is politically easier than agreeing a deletion, and it produces much the same first release. The deferred list does the rest of the work.

Should we scope with the team that will build it?

Strongly preferable. Scoping done by people who will not build it tends to produce plans that are optimistic in exactly the places that matter, because nobody in the room has to live with the estimate.

Related guides

Working on something like this?

Tell us what you're building. We send back a one-page response with scope, timeline, and a number you can plan around.

Send us a brief