How to scope an MVP that stays minimum

"Minimum viable product" has been repeated so often that it's lost the part that made it useful. Most first-time founders read minimum as small and viable as good enough, and ship a broad, half-finished thing.

That's the worst of both. A wide, rough product tests nothing — because when users bounce, you can't tell whether they rejected the idea or the roughness. And you'll assume it was the roughness, because that's the answer that lets you keep building.

The useful reading: narrow in scope, complete in what it does. One thing, finished.

Start from the hypothesis, not the feature list

An MVP is an experiment, and an experiment needs a claim it could falsify. Write it down in this shape:

We believe that [specific person] will [specific action] because [specific reason]. We'll know we're wrong if [observable thing] doesn't happen.

If you can't fill that in, the problem isn't scope — you don't yet know what you're testing, and no amount of cutting features will fix that.

Once you have it, every feature gets one question: does this change the result of the experiment? Most don't. Settings pages don't. Onboarding tours don't. A second integration almost never does.

The out-of-scope list is the real artifact

Everyone writes the in-scope list. It feels productive and it grows.

Write the out list instead, explicitly, with the reason next to each item:

• Team accounts — single-user proves the hypothesis; teams are a pricing question, not a validation one
• Slack integration — nice, but nobody churns over its absence in week one
• Password reset — magic links only for now; five users, we'll do it by hand

Two things happen. Scope creep now requires moving an item across the list — a visible act with a stated reason, instead of a quiet Tuesday afternoon. And when someone asks "does it do X?", you have an answer that isn't "not yet": you have "no, deliberately, because Y."

Where the scope actually creeps

Edge cases discovered while building. You hit one, it's real, fixing it is twenty minutes. Twenty of those is a week. Keep a list; fix the ones that block the experiment; ship with the rest known.

"While I'm in here." The most expensive sentence in software.

Building for the user you want rather than the one you have. Enterprise-shaped features before a single enterprise customer exists is scope creep wearing a strategy costume.

AI making it cheap to say yes. This one is new and underrated. When a feature costs an afternoon of prompting instead of a week of typing, the natural discipline that used to come from effort disappears. Cheap to build is not the same as free — every feature is still surface area to maintain, explain, support, and eventually remove. The constraint has to be deliberate now, because the tooling no longer supplies it.

No definition of done. Without one, "almost ready" can last a quarter.

A test that works

Describe your MVP to someone in one sentence with no "and".

"It takes your standup messages and writes the summary." Fine.

"It takes your standup messages and writes the summary and tracks blockers and integrates with Jira and has a dashboard." Not an MVP — that's a product roadmap you're trying to ship at once.

Working it through

MVP Scope is the Groundwork project type for this: it works through the hypothesis, the feature set, and the explicit out-of-scope list in order, and ends with a scope you can hand to a builder.

Then MVP Scope Matrix turns it into the value-vs-effort visual that makes the cuts obvious to everyone else, and App Blueprint turns the surviving list into screens and flows you can hand straight to an AI coding tool — which is the step most people skip, and the reason the agent invents a generic navigation structure that fits nobody.

If you're not yet sure anyone wants it, do Product Validation first. Scoping an MVP for an unvalidated idea is a well-organised way to build the wrong thing.