Most MVP scope conversations start with the wrong question. Someone asks how long it will take to build what we have described, an engineer produces a number, everyone negotiates the number downwards, and the project begins already behind.

The better question runs in the other direction: given what this answer is worth to us, how much time are we willing to spend getting it — and what fits inside that?

This is the distinction Basecamp's Shape Up draws between an estimate and an appetite. "Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?" The estimate starts with the solution and produces a duration. The appetite starts with a duration and constrains the solution. One of these is negotiable with reality. The other is not.

Start from the appetite

For an early-stage MVP the appetite is usually set by something outside the product: runway, a funding conversation, a seasonal window, a pilot customer's own timeline. Whatever it is, write it down as a hard number before anyone discusses features.

Six weeks is a reasonable default for a first build, and the reasoning in Shape Up is sound — "long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start." Eight to ten weeks is realistic for something with real integrations or compliance requirements. Past twelve, the pressure that makes scoping honest dissipates, and scope quietly reflates.

The appetite is not a prediction. It is a statement about how much this particular answer is worth.

Fix the date, flex the scope

Having set the appetite, the second commitment matters more than the first: when the two collide, scope gives way, not the date.

Shape Up calls the mechanism a circuit breaker — "if a project runs over, by default it doesn't get an extension." The value is not schedule discipline for its own sake. It is that a fixed date forces trade-offs to happen continuously, in the open, while there is still time to make them well. A movable date defers every trade-off to the last fortnight, where they get made badly by whoever is most tired.

This only works if everyone genuinely believes the date will hold. The first time it slips "just this once," you have an estimate again.

Cut along the journey, not the feature list

Here is where most scoping goes wrong, and it is a structural problem rather than a discipline problem.

A feature list has no natural stopping point. Every item sounds defensible in isolation, nothing on it is obviously the last one, and cutting always feels arbitrary. So teams cut by percentage — take the list, remove the bottom third — and end up with something that does several things partially and nothing completely.

A user journey does have a stopping point. It completes, or it does not.

So scope like this: name the single journey that has to work end to end for a real user to get real value. Then ask, of everything else, whether the journey completes without it. If it does, it is out of the MVP.

For a marketplace that might be: a buyer finds one relevant listing, contacts the seller, and completes a transaction. Not a seller dashboard, not reviews, not saved searches, not messaging with attachments. One journey, finished properly.

The discipline this creates is uncomfortable and correct. It is also the reason an MVP can feel embarrassingly narrow and still be complete, which is the right kind of embarrassing. We have written more about that trade-off in cutting MVP scope without cutting the value.

The three-list exercise

A scoping session that works, in about ninety minutes with everyone who will actually build the thing in the room.

First, write the journey on the wall as a sequence of steps. Plain language, from the user's first contact to the moment they get the value. Usually seven to twelve steps. Do this before anyone mentions a feature.

Then sort everything you were planning to build into three lists.

  • Required by the journey. Without this, the user cannot complete the sequence. Be strict: "the user cannot proceed" is the bar, not "the experience would be worse."
  • Required by reality. Not part of the journey, but you cannot ship without it. Authentication, payment handling, legal basics, whatever your sector genuinely requires. This list is where MVPs actually get expensive, and it is the one teams forget to count.
  • Everything else. Keep it visible. Do not delete it — teams cut more willingly when they can see that the idea was recorded rather than rejected.

Then check the first two lists against the appetite. If they do not fit, you have two honest options, and only two: narrow the journey itself, or lower the ambition of individual steps. What you may not do is keep the journey and hope.

Narrowing the journey means serving fewer cases — one user type instead of three, one geography, one integration, one payment method. This is almost always the better cut, because it preserves completeness.

Lowering the ambition of a step means doing something manually that would eventually be automatic. A human matching buyers and sellers. An onboarding call instead of a self-serve flow. A spreadsheet behind an interface. These steps look like debt and are often the most valuable part of the build, because they put the team inside the workflow at exactly the moment they need to understand it.

The second list is where budgets die

Worth dwelling on, because it is the most common source of overrun in early builds.

The journey work is visible and gets estimated. The rest does not: account recovery, email deliverability, error states, an admin view so someone can fix a stuck record, a privacy notice, cookie consent, basic analytics, staging and deployment, the hour lost to a payment provider's verification process.

None of it is optional and none of it appears on the feature list. In the builds we run, this material regularly accounts for a quarter to a third of the effort. If your plan does not have it written down, your plan is a third short.

Count it explicitly during scoping. It is far easier to argue for narrowing the journey when the true cost of shipping anything at all is on the wall next to it.

What "viable" has to survive

Cutting has a floor. Marty Cagan's formulation is the useful one: the smallest product where people choose to use it, people can figure out how to use it, and you can deliver it when you need it. Valuable, usable, feasible.

The usable constraint is the one that gets sacrificed under deadline pressure, and it is the one that ruins the experiment. If people drop out because the interface confused them, you have learned nothing about demand. You have spent the whole budget and bought no information — which is the only genuinely unrecoverable outcome in this whole process.

So when the cutting gets hard, protect comprehension over completeness. Fewer things, understood, beats more things, half-explained.

Write the scope as a decision, not a list

The document that comes out of this should be short enough to read in five minutes and should state:

  1. The appetite. The date, and what happens at the date.
  2. The journey. The sequence, in user language.
  3. What is in. Organised by step, not by feature.
  4. What is explicitly out, and why. The "why" matters — it prevents the same argument recurring every fortnight.
  5. What we will learn. The question this build exists to answer, and the result that would change the plan.
  6. What we will do manually. Named, with who is doing it.

If it runs longer than two pages, the scope is probably still too large — long specifications tend to be a symptom of unresolved decisions rather than thorough ones.

When to reopen it

Scope should be closed, not frozen. Two things justify reopening it mid-build: discovering that a step in the journey is technically much harder than assumed, or learning something from users that changes what the journey should be.

Neither of those is "we thought of something good." Ideas arriving mid-cycle go on the third list. That is what the third list is for, and keeping it visible is what makes the answer "not now" rather than "no."

Scoping is where most of the money in an early build is either saved or lost, and it is largely a judgement problem rather than a technical one — which journey, which cases, what to do by hand, what not to build at all. It is the part of product and UI/UX design we spend the most time on with founding teams, usually before a single screen is drawn.

If you are about to start a build and the plan is a feature list, the highest-value thing you can do this week is convert it into a journey and find out where it actually stops.

Common questions

How many features should an MVP have?

The wrong unit. Scope an MVP as one user journey that completes end to end, not as a count of features. A journey has a natural stopping point; a feature list does not, which is why feature-scoped builds grow by roughly a third during delivery.

What is the difference between an appetite and an estimate?

An estimate starts with a defined solution and produces a duration. An appetite starts with a duration you are willing to spend and constrains the solution to fit inside it. The first is a prediction that tends to expand; the second is a decision about what the answer is worth.

What should I do when the scope does not fit the deadline?

Two honest options: narrow the journey so it serves fewer cases, or lower the ambition of individual steps by doing them manually. Narrowing is usually better because it preserves completeness. Extending the deadline is the option that quietly removes every trade-off from the build.

How do I stop scope creep during the build?

Fix the date so scope has to give way, keep a visible list of deferred ideas so "not now" is recorded rather than rejected, and write down why each excluded item was excluded. Most creep comes from re-litigating settled decisions, and a one-line reason prevents that.

Should the MVP include an admin panel?

Rarely as a built product. For the first fifty users a spreadsheet and direct database access are usually sufficient. Internal tooling expands without limit and produces no learning about whether customers want the thing you are testing.

Sources and further reading