Almost every MVP scope that lands on our desk is at least twice the size it needs to be. Sometimes four times. The cost of shipping an oversized MVP is not just time; it's the quality of the learning that comes back from users, which is the whole point of the exercise.
Here is how we cut the scope in half, reliably, without losing the core.
Ask three questions
Before a single feature is cut, run the scope through these.
- What is the one thing a user must be able to do for this product to be worth logging into? Anything that doesn't feed that one action is optional.
- Which features exist because of a competitor's feature list, not a user need? These are the cheapest to cut, because nobody will miss them.
- What are you building because you're afraid the product looks "too simple" without it? This is the hardest cut, because it's emotional. It's also the most important.
The rule: if a feature doesn't survive at least one of those three questions, it doesn't ship with the MVP. It goes on the post-launch list.
The before/after on a recent engagement
The founding team of LaunchProd, a Carnegie Mellon founded creator-economy AI startup, came to us with a scope that listed forty-two features across three user personas. Six weeks of engineering. Marketing site. Analytics dashboard. Email campaigns.
After question one: thirty-one features dropped. The core was "a creator uploads a product and gets an AI-generated landing page in under a minute." Everything downstream of that, the analytics, the campaigns, the multi-persona views, was important, but it was not what made the product worth logging into.
We shipped the core in four weeks. The features we cut are now a prioritised backlog, re-ordered by what users actually asked for in the first month of usage. Four of the original forty-two features were never rebuilt. Users didn't miss them.
Why simple is the hard choice
Founders equate scope with seriousness. A forty-feature spec feels like a serious business; a four-feature spec feels like a weekend project. This is backwards.
A serious founder ships the one thing their product is actually for and waits for users to tell them what comes next. An unserious founder ships everything they can imagine and hopes something sticks.
The second approach is expensive, slow, and blind. The first is cheap, fast, and instrumented.
What to do in the meeting
When you walk into a scoping meeting, bring a sharpie and a printed spec. Cross out every feature that doesn't survive the three questions. Show it to the founder. Resist the instinct to reassure them that "we can add those later." You can, and you will, but only after users have told you which of those features was the right second thing to build.
Heuristics
- An MVP is one thing done well plus the scaffolding required to use it. Not two things. Not eight.
- Cuts made before the first commit are free. Cuts made in week six cost a week.
- The feature you're afraid to cut is the one you most need to justify.
If the conversation gets stuck on what to cut, the problem is earlier: you don't have a scoped project yet, you have a wish.
Written 2025-01-18 by Abhiraj Sakargaye.