MVP Scoping: How to Decide What to Cut

August 5, 2026

Everyone agrees on building a minimum viable product. Nobody agrees on what to cut. Here is a framework that settles it.

A team planning a product on a shared workspace

Scope arguments are rarely about features. They are about risk: everyone is protecting the thing whose absence would embarrass them. A framework helps because it moves the discussion from opinion to a testable question.

The three-question test

  1. Does the core promise break without it? If a user cannot complete the one job the product exists for, it stays. Everything else is negotiable.
  2. Can a human do it manually at current volume? Reporting, approvals, onboarding and invoicing frequently can, for the first hundred customers. Manual is not failure; it is a decision you can reverse cheaply.
  3. Does it get harder to add later? Anything touching the data model, permissions or billing gets more expensive with time. Those earn a place in version one even when the interface for them does not.

The test is not 'is this valuable'. Everything on the list is valuable — that is why it is on the list. The test is 'what breaks, and how expensive is it to add in three months'.

What to cut first

  • Admin interfaces. A database view and a competent person outperform a half-built admin panel for months.
  • Configuration options. Every setting is a branch to build, test and support. Pick a default and change it when someone complains.
  • Secondary user roles. Each additional role multiplies permission combinations and testing surface.
  • Bulk operations, exports and integrations nobody has explicitly asked for yet.

What never to cut

Authentication done properly, a coherent data model, error handling that tells you what broke, and the ability to export your own data. These are invisible in a demo and ruinous to retrofit. Cutting them is not scope reduction — it is borrowing against next year at a punitive rate.

  • 1 core job the product must do
  • 100 customers a manual process can usually serve
  • 3 months the horizon that makes cuts reversible

Frequently asked questions

How small should a first version be?

Small enough to reach real users within about three months. Beyond that, the feedback loop is too slow to correct a wrong assumption, and the sunk cost makes the correction politically hard.

What if the client insists on every feature?

Price them separately and sequence them by dependency. Presented as phases with visible costs, most feature lists shrink on their own — because the conversation shifts from wanting to paying.