At some point in almost every project, the plan and the calendar stop agreeing. The launch date is fixed, the scope has grown, and someone has to decide what goes.
I've been on both sides of this. As a project manager on the Travelxp OTT launch, my job was to hit an aggressive global date, which meant constant conversations about what could move. Later, as a product manager, I was the one deciding what the first version actually needed. The cuts that worked well had one thing in common: they protected the reason the MVP existed.
Know what the MVP is meant to prove
Before cutting anything, be clear about what the first version is for. Is it testing whether people want this at all? Whether they'll pay? Whether a specific workflow is usable?
I wrote about framing this as a learning objective in product discovery before an MVP. Once that's clear, scope decisions get much easier. Anything that doesn't help answer that question is a candidate for cutting.
Cut breadth before depth
| Cut this first | Keep this |
|---|---|
| Extra platforms | One platform done properly |
| Multiple user types | The one user type you're learning about |
| Edge-case configurations | The common path, working reliably |
| Settings and preferences | Sensible defaults |
| Admin tools | Manual processes behind the scenes |
| Nice visual polish | Clear, usable basics |
A thin feature that works well for one group teaches you more than a broad feature that works poorly for everyone. If you launch on four platforms and it's shaky on all of them, you won't know whether the idea failed or the execution did.
Fake the back office
A lot of MVP scope goes into things users never see: admin panels, reporting, automated workflows. Early on, many of these can be done manually.
If the first version needs an operations team to review submissions, maybe that's a spreadsheet and a person instead of a review dashboard. It doesn't scale, but you don't need it to scale yet. You need to find out if anyone submits anything.
Watch out for false cuts
Some cuts look like savings and create bigger problems:
- Cutting analytics. If you can't measure the MVP, you can't learn from it.
- Cutting error handling. The first users hit an error, get stuck, and you learn nothing except that it's broken.
- Cutting security or privacy basics. These are not optional, even for a test.
- Cutting the thing that makes it different. If the core idea is a better recommendation, shipping without it tests nothing.
Make cuts with the team
Engineers often see smaller ways to deliver the same value. Ask them: "If we had half the time, what would you build?" The answer is often surprisingly good.
Shape Up, Basecamp's approach to product development, talks about setting an appetite, a fixed amount of time, and shaping the work to fit it, instead of estimating a fixed scope. 1 I find that framing helpful when time is the real constraint.
Write down what you dropped
Every cut should be recorded: what it was, why it was dropped, and what would make you add it back. This stops the same debates from coming back every week and gives stakeholders a clear answer when they ask.
It also protects the team. When early users say "it doesn't do X," you can point to a deliberate decision instead of an oversight. If you want to feel the pressure of capacity trade-offs in a lighter way, Sprint Rush is built around it. The sprint planning version of this conversation is in my sprint planning post.
Launch, then decide
After launch, look at what users actually do. Some of the things you cut will turn out to matter. Many won't. The ones that matter will usually make themselves known quickly, through support requests or obvious gaps in behaviour.
That's a much better way to decide what goes into version two than guessing upfront.