MVP Scope That Actually Ships (Most Don't)

Ask ten founders to define their MVP and you'll get ten lists that are really just the full product with a few features removed. That's not minimal — it's just smaller.

The actual question an MVP answers

An MVP exists to answer one specific question as cheaply as possible: will people do [the core behavior] for [the core reason]? Everything that doesn't help answer that question is scope creep, even if it would obviously be needed eventually.

A test that filters scope fast

For every feature on your list, ask: "If this didn't exist, would the experiment still tell us whether the core hypothesis is true?" If yes, cut it. Authentication, polished onboarding, settings pages, and edge-case handling almost always fail this test in week one — they matter for retention, not validation.

What's allowed to be embarrassingly manual

Manual processes behind the scenes are fine in an MVP as long as the user-facing experience tests the real hypothesis. A waitlist that triggers a manual email, a "dashboard" that's really just you checking a spreadsheet, an "AI feature" that's you answering messages yourself for the first 20 users — all valid, as long as you're honest with yourself about what's manual and have a plan to automate once it's validated.

The real failure mode

Most MVPs don't fail because they were too minimal. They fail because they were never minimal enough to ship in the timeframe that would have let the founder learn something while they still had the energy and runway to act on it. Smaller and shipped beats comprehensive and still in development.

If you can't describe your MVP's single hypothesis in one sentence, you don't have an MVP yet — you have a small product.