Cut the Spec Until Removing One More Thing Breaks the Job
MVPs aren't defined by what's in them. They're defined by what removing one more thing would break.
The most useful definition of an MVP isn't 'minimum viable.' That phrase is too soft. People interpret 'minimum' as 'small.' They interpret 'viable' as 'works.' So the team ships something small and working, and calls it an MVP, and moves on.
The sharper definition: an MVP is the version of the product where removing one more thing breaks the user's job-to-be-done. Not 'feels incomplete.' Not 'feels rough.' Actually breaks. The user cannot complete the task. The transaction fails. The signup never finishes.
If you can remove a feature and the user can still do the thing they came to do, that feature wasn't part of the MVP. It was something you added because you couldn't bring yourself to ship a v1 that felt this small.
The procedure is simple. Take your current scope. Go feature by feature. For each one, ask: if I removed this, could a real user still complete the core flow end-to-end?
If yes — that feature is not MVP. It belongs in the Later list. Move it. Don't argue with yourself about whether it's 'really' optional. If a real user can complete the flow without it, it's optional by definition.
Do this until the answer for every remaining feature is no. That set is your MVP. It will feel uncomfortably small. That's the correct feeling.
MVP scope hurts. If it doesn't, you haven't cut enough.
Over-scoping isn't a discipline failure. It's a confidence failure. The team isn't sure the MVP will be enough, so they pad it with 'in case' features. The padding is a hedge against the possibility that the small version flops.
But the padding doesn't help in the case you're hedging against. If the small version flops, the padding flops too. Padding only helps in the case where the small version succeeds — and in that case, you wasted weeks building features the user didn't need to validate the bet.
The correct hedge against MVP failure is shorter cycles, not bigger MVPs. Ship the small version, see what's missing, ship the next version. Two two-week loops beat one six-week loop almost every time.
The reason teams resist cutting is the fear that cut features will never come back. So they pad scope to make sure things ship together.
Fix this with a Later list that the team trusts. Three columns: Now, Next, Later. Every cut feature goes to Later with a date and a reason. Every cycle, items graduate from Later → Next → Now based on signal, not on calendar.
When the Later list is real — when items actually move when the signal supports them — the team will cut more aggressively. They're not deleting features. They're queuing them with a clear path back to the build queue.
When the Later list is fake — when items go in and never come out — the team will pad scope every time. They can't trust the queue, so they grab everything they can while they have the chance.