Every founder I've worked with agrees, in principle, that an MVP should be minimal. The agreement lasts right up until it's their feature on the cutting block. Then the M in MVP quietly becomes "Marketable", then "Mature", and eventually you're nine months into a "minimum" product with a settings page.
The problem isn't discipline. It's that "minimum" has no defence attached. When someone asks "surely we need user profiles?", no needs an argument, and most scoping exercises don't produce arguments. They produce lists.
Start from the bet, not the product
An MVP exists to test exactly one bet: the riskiest assumption that, if wrong, kills the business. Not "can we build it"; you almost certainly can. Usually it's "will this specific person pay to solve this specific problem this specific way."
Write the bet down as a sentence. For a recent fintech client it was: finance teams will pay to eliminate one reconciliation step they currently do in spreadsheets. Every scoping decision for the next six weeks traced back to that sentence.
If you can't write the sentence, you're not ready to scope; you have a strategy gap, not a scoping one. That's what a product strategy sprint is for: name the bets, then come back and cut.
The three columns
Now take your feature wishlist (all forty items, be honest) and sort every one into exactly three columns:
Proves the bet. Remove this feature and the MVP can no longer test the assumption. This column is shockingly small. For the fintech it was four features.
Table stakes. The product is unusable or untrustworthy without it: auth, the billing path if you're charging (you should be), whatever your industry regulates. Be brutal here: "users expect it" is not table stakes, it's column three wearing a disguise.
Later. Everything else. Not "phase two", not "fast follow". Later, meaning after the bet is proven, re-prioritised against what you learn.
Defend the middle column
Column two is where MVPs go to die, because everything feels like table stakes to the person who suggested it. The test I apply: what actually breaks if we ship without it? Not "what looks unpolished". What breaks.
Password reset? Breaks trust with real users, so keep it. Email notifications? Nothing breaks; your first fifty users will check the dashboard. Later. Admin analytics? You have twelve customers; a spreadsheet works. Later. Native app? A responsive web app tests the same bet for a third of the cost. Later, maybe forever.
At the end of a good scoping session, the "later" column should hold 50–70% of the original list. If it holds less, you haven't scoped, you've reformatted.
Make the cut list public
The most underrated artefact of scoping isn't the roadmap. It's the explicit not-now list, signed by the founders. Written down, with the reasoning, where the whole team can see it.
This does two jobs. It stops relitigating: when the feature request comes back in week three (it will), you point at the list instead of re-arguing. And it converts scoping from a loss into a plan: stakeholders accept "later, once the bet is proven" far more gracefully than "no".
The wishlist isn't wrong. It's just not first. That's the entire discipline of MVP scoping: sequencing, defended in writing.