How do you scope an MVP?

Scope it from the outcome, not the feature list: find the smallest version that delivers the core result to one real user, and cut everything else. An MVP isn't the smallest thing you can build — it's the smallest thing that's actually useful. So you define the one outcome the product must deliver, build the minimum path to it, and ruthlessly leave out everything that isn't required to reach that outcome, even if it's obviously nice. If a real user can get the core value, it's a viable MVP; if they can't, it's just unfinished.

What is the most common MVP mistake?

Two opposite ones. The first is building too much — treating the MVP as a slightly-smaller version of the full vision, so it's neither minimum nor shipped quickly. The second is shipping something that's minimum but not viable — so stripped down that it doesn't actually deliver the core value, so users get nothing useful and you learn nothing. The fix for both is the same: define the core outcome first, then build the smallest thing that genuinely delivers it — no more, no less.

What should you cut from an MVP?

Everything that isn't required to deliver the core outcome to a real user — however reasonable or nice it seems. Secondary features, edge cases, polish beyond usable, settings, integrations, and 'while we're here' additions all get cut from the MVP and parked. The test for each is simple: can a user get the core value without it? If yes, it's not in the MVP. Ruthless cutting is what keeps the MVP minimum; the parked list is where the good-but-later ideas wait.

How I Scope an MVP | Tan Gravam

Everyone knows the MVP is the smallest thing you can build and ship. That's the textbook line, and it's the half that gets people in trouble. Here's the version I've earned: an MVP isn't the smallest thing you can build — it's the smallest thing that's actually useful. I scope mine from the outcome — the one core result the product must deliver to one real user, built by the shortest path, everything else cut. Not minimum-and-broken. Not the-whole-vision-slightly-smaller. The smallest thing that genuinely delivers the core value. Get that framing right and the scope almost draws itself. Get it wrong and you either over-build for months or ship something too stripped to matter.

The two ways MVPs fail

They fail in opposite directions:

Too much. The MVP quietly becomes "the whole vision, a bit smaller" — neither minimum nor fast, and you're still building when you should be learning.
Minimum but not viable. So stripped down it doesn't deliver the core value at all — users get nothing they can use, and you learn nothing except that a broken thing gets no traction.

Both come from scoping by feature count instead of by outcome. The word doing the work in "minimum viable product" is viable — it has to actually work for someone.

Scope from the outcome

I start where I always start: what's the one core result a user should walk away with? For Delivery Sheet, that's turning a raw leadership ask into a decision-ready one-pager. That outcome is the definition of the MVP. Everything else sorts into one of two piles — required to deliver it, or not. The first pile is the MVP. The second is parked.

Cut ruthlessly, park honestly

The hard part isn't finding what to build — it's cutting what not to. Secondary features, edge cases, settings, integrations, polish past usable, every "while we're here" — out. Not deleted: parked, on a list, for later. It's the same ruthless subtraction that makes any product sharp, only now under a deadline. A cut feature you can always add back. A bloated MVP you can't un-build.

Why AI makes this harder, not easier

Here's the modern trap. AI makes building so cheap that over-building feels free. When a feature costs an afternoon instead of a week, the discipline to not add it quietly erodes — and you end up with an MVP that's secretly a V3, still unshipped, still teaching you nothing. The cheaper building gets, the more scope discipline matters, because the natural brake — cost — is gone. Cheap to build was never the same as worth building.

The test of a good MVP

A well-scoped MVP passes one test: can one real user get the core value? Not "is it impressive." Not "is it complete." Can a genuine user, with the actual problem, reach the outcome and find it worth using? If yes, ship it and learn. If no, it isn't minimum-viable — it's just unfinished, and shrinking it further won't help. Only making it actually deliver will.

What usually goes wrong

Scoping by features, not outcome. Choosing what to include from a list instead of from what delivers the core result.
Over-building. Treating the MVP as the full vision slightly smaller, so it's slow and bloated and late.
Under-delivering. Stripping past viable, so it doesn't provide the core value and teaches you nothing.
Letting cheap building erode discipline. Adding "just one more" because AI makes it easy, until the MVP is a V3.

Define the core outcome, build the shortest path to it, cut everything else to a parked list, and ship the moment a real user can get that value. That's the MVP doing its job: the smallest useful thing, out fast, telling you what's true. It's rule two of my operating system under a stopwatch — outcome first, everything non-essential cut.

Part of Building AI Products. See also why I write the expected output before the screen and my product operating system. The newsletter sends one practical build lesson every two weeks.