The kickoff deck said "simple internal tool." Three weeks later the requirements doc listed twenty-four must-have features from eleven stakeholders, each annotated critical in a comment thread nobody would admit to starting. Four roles, five dashboards, a notification system, and, because someone had once worked at a bank, an audit log.

Asked what question the tool should answer, the room went quiet the way rooms do when everyone assumes someone else knows. This is how MVPs eat six months: a feature list that answers every question except the one that matters. Learning how to cut MVP scope is mostly learning to have that awkward conversation early, on purpose, with a pen.

Here's the whole method in three sentences. An MVP is a question with a UI, not a small product, so write down the one question you're trying to answer. Keep only the features that answer that question, and park everything else in a written parking lot where stakeholders can see it isn't deleted, just deferred. If a feature wouldn't change what you do next month, it isn't in the MVP; it's in the museum of good intentions.

The MVP that ate six months

Back to our twenty-four-feature tool. It was a job tracker for a services firm, and the actual business question was embarrassingly small: are we losing work between quote and scheduling, and if so, where? Everything else, the roles, the dashboards, the exports, the notifications, was speculation about what people might want after the tool existed.

Scope creep has a sound, and the sound is "while we're at it." While we're at it, add a permissions model. While we're at it, an activity feed. Each addition is small, reasonable, and individually defensible, which is exactly the problem: scope never arrives as a villain. It arrives as a series of perfectly sensible fifteen-minute conversations, and then your six-week build is a six-month build with the same uncertain payoff.

The costs aren't just calendar time. Every extra feature is more surface for bugs, more UI to explain, more reasons for first users to bounce off. A bloated MVP doesn't fail bigger than a small one; it fails slower and more expensively, and it teaches you less, because you can't tell which part nobody wanted.

Needed to learn vs needed someday

My cleanest test separates two piles. Needed to learn: the features without which you cannot answer the question. Needed someday: the features a real product would eventually want, which is a different list and a longer one. Almost everything stakeholders call must-have belongs in the second pile. They're not lying; they're answering a different question than the one an MVP exists to ask.

Say the question is "will dispatchers actually assign jobs from this screen?" Needed to learn: the screen, the job list, the assign button, and enough real data flowing in that the list isn't a mockup. Needed someday: drag-and-drop reordering, keyboard shortcuts, dark mode, a mobile app, SSO. The someday list is real work, worth pricing and parking. It's just not this month's work, and confusing the two lists is how prototypes turn into quarters.

How to cut MVP scope: the exercise, step by step

This is a ninety-minute workshop, not a vibe. You need the stakeholders in one room, a whiteboard, and a facilitator willing to be briefly unpopular.

  1. Write the question. One sentence, plain language, observable answer. "Are jobs stalling between quote and scheduling?" qualifies. "Improve operational visibility" does not; that's a horoscope, not a question.
  2. Map every feature to the question. For each of the twenty-four, ask: without this, can we still answer the question? If yes, it moves to the parking lot. Most features lose this argument in under a minute once someone says it out loud.
  3. Make the parking lot real. Write the cut features where everyone can see them, each with an owner and a revisit date. People don't fight for features; they fight against being forgotten. A written parking lot ends arguments that a verbal "later" never will.
  4. Run the "who screams?" test. For anything still on the bubble, ask who, specifically, screams if it ships without this. If the answer is a hypothetical person, cut it. If the answer is "Diane, and she'll scream at me," keep it or call Diane.

Expect the room to go quiet around feature nine, when someone realizes their pet item can't map to the question. Let it be quiet. That silence is the sound of six weeks coming back.

What to cut first: the usual suspects

Some features are statistically guilty. When I open a bloated scope doc, I look for these first, and I am rarely disappointed:

Cut all five and a typical internal tool loses half its estimate without touching the core workflow. Nobody's week gets worse. The same discipline powers the one-week prototype, where the constraint isn't cruelty; it's the mechanism that keeps the question sharp.

What you should never cut

Ruthlessness has limits, and the limits matter more than the cutting. Never cut the one workflow that answers the question; if dispatchers can't actually assign the job, you haven't built an MVP, you've built a screenshot. Never cut data integrity, because numbers nobody trusts produce learning that's wrong with confidence, which is worse than no learning. And never cut the feedback loop itself: the analytics events, the weekly user call, the "tell us what's broken" link. An MVP without a feedback loop is just a small product with missing features.

The rule of thumb: cut features, never instrumentation. You can ship without exports. You cannot learn without knowing what users did.

After the cut: ship and learn

So what happened to the twenty-four-feature tracker? It shipped with four: the job list, the status field, one filtered view of stalled quotes, and a weekly export someone ran by hand. The other twenty went into the parking lot with dates. Two stakeholders sulked. One still mentions the audit log at parties.

Two weeks in, the data answered the question, and the answer was a surprise: jobs weren't stalling between quote and scheduling at all. They were dying earlier, at intake, where half never got quoted in the first place. The roadmap pivoted to intake within the month, and not one of the parked features would have helped. The cut list didn't just save time; it stopped the team from perfecting the wrong tool. That's the pattern inside every rapid prototyping playbook worth the name, and it's why teams that ship in days instead of months keep ending up right while looking lucky.

Your MVP is a question with a UI. Ask a sharper one.