Cutting scope like a surgeon, not a butcher
Scope-cutting isn't saying no to features. It's finding the one feature your users would ride a bike through rain to use.
Most “scope-cutting” exercises are just saying no to the cheapest features on the list. That's not scope-cutting, that's cowardice — and it's why those products feel like a worse version of everything.
The surgeon's cut
Real scope-cutting is surgery. You find the one organ the product can't live without, and you remove everything else. The scary part is that “everything else” includes features that feel essential: settings, admin panels, edge cases, occasionally even user accounts.
If your MVP has a “profile page” it is probably not an MVP.
The rainy-bike-ride test
Here's the test we use: if you could only have one feature, and a user had to ride a bike through rain to use it, would they?
If the answer is yes, that's the feature. Build it end-to-end. Make it sing. Everything else is noise until that one thing is painfully good.
“The product is the bike ride in the rain. Everything else is the umbrella you'll sell in year two.”
Common mistakes
Cutting the wrong axis
Cutting breadth (fewer features) is easy. Cutting depth (a shallower version of the one feature) is what kills products. Your one feature needs to be deep, polished, and end-to-end. A shallow version of ten features is worse than a deep version of one.
Saving “safety” features
Password reset. Two-factor auth. Cookie banners. These feel like hygiene, but in week one they're a distraction from finding out if the core idea works. Use magic-link auth, stub the rest, come back in month two.
Building for the second user
If your product only makes sense with roles, teams, permissions, billing seats, and SSO — you're building a v2. Find a way to make it valuable for one user first. The B2B gymnastics can wait.
How to run the exercise
- 1Write the whole feature list on a whiteboard. Every idea that's been kicked around.
- 2Circle the one feature that would make a user ride a bike through rain.
- 3Cross out everything that isn't required for that one feature to work.
- 4Look at what's left. If there's more than a week of work, cross out more.
If this exercise feels painful, you're doing it right. If it feels easy, you're not cutting enough.
Got a project like this?
Tell us in one paragraph. A real engineer replies within a day.
Keep reading
What we actually mean by “vibe coding”
It's not vibes instead of rigor. It's vibes plus AI plus senior taste, so the boring 80% of work gets compressed into a morning.
How we ship an MVP in three weeks (and why you should)
A play-by-play of our 21-day MVP process: what we cut, what we keep, and how we keep quality from collapsing.