Most MVP scopes are argued over features. The question that actually decides whether you ship is a different one entirely.
Every MVP scoping conversation I've been in starts the same way: a list of features, and an argument about which ones are cut. It feels like the right conversation. It rarely is.
The question that actually determines whether you ship on time isn't which features make the cut. It's this: what is the one thing about this product that we do not yet know is true?
Scope follows the unknown
An MVP is not a small version of your product. It's an instrument for answering one question. Once you name the question, the scope stops being a negotiation and starts being a deduction — you build exactly what is required to get an honest answer, and nothing else.
Two products with identical feature lists can have completely different correct MVPs, because the risk sits in different places:
- If the unknown is whether people want this at all, the MVP is a landing page and a manual back end. No auth, no dashboard, no database schema you'll regret.
- If the unknown is whether the hard technical thing is even possible, the MVP is that one capability behind an ugly interface — and you skip onboarding entirely.
- If the unknown is whether people will pay, the MVP includes checkout on day one, even when the product behind it is half-manual.
If you can't name the unknown, you're not scoping an MVP. You're building version one of a product you haven't validated.
The features that quietly eat the timeline
In practice the schedule doesn't go on the thing you're testing. It goes on the surrounding machinery everyone assumed was free: roles and permissions, team accounts, notification preferences, an admin panel, billing edge cases, an onboarding flow with six states.
None of these answer your question. All of them are real work. Most can be replaced for the first few months by a spreadsheet, a Slack channel, or you doing it by hand — and the ones that can't will announce themselves loudly enough that you'll know.
What still has to be real
Cutting scope is not the same as cutting quality. There are a few things that are cheap now and enormously expensive to retrofit, and they stay in every MVP I build:
- A data model you can live with. Migrating a wrong schema after launch costs more than getting it roughly right up front.
- Deploys that take a minute, not an afternoon. Everything downstream depends on iteration speed.
- Enough logging to answer 'what happened to this user' without guessing.
- Auth done properly, if you have auth at all. It's the one place where a shortcut becomes an incident.
Everything else can wait for evidence. That's the whole point — you're buying information, and the cheapest version that produces a trustworthy answer is the right one.