Cutting scope

When a project is overstuffed, you still have to ship something that teaches. Cutting scope means dropping work that does not serve the core value, not shrinking quality until the product is uninformative.

Write a one-line core value proposition for the release: "A triage owner can see all open sev-1 issues assigned to their team in one click." Every scope cut is checked against that sentence. If the cut breaks it, it is not a cut — it is a different product.

Cut in this order

1. Nice-to-have personas — serve the primary job for the primary user first.
2. Secondary surfaces — admin, reports, APIs can wait if the core loop works.
3. Edge-case automation — handle rare cases manually at first.
4. Customization — one good default beats five settings.
5. Polish that does not affect comprehension — motion, themes, empty illustrations.

Do not cut:

• The moment of value (the aha) that justifies the product
• Trust basics: security of payments, data integrity, undo for destructive actions
• Instrumentation — if you cannot measure, you cannot learn

A practical trick: list every proposed capability. Mark each Must / Should / Delight for this appetite only. Musts are the core value proposition; Shoulds ship if time remains; Delights are explicitly cut when the schedule slips. Revisit the list mid-cycle once, not daily — constant re-litigation eats the appetite.

Walking through Must versus Should

Stakeholders want shared views, email digests, cross-project search and three themes. Core value: "A triage owner sees open sev-1s for their team in one click." Shared views are Must. Digests, cross-project and themes are Should or Delight. Ask for the Must-only estimate and the Must+Should estimate separately. If they want the full list on the Must-only date, they are asking for a contradiction.

When scope creeps mid-cycle, re-read the assumption under test. Does the new request test it, or is it a different product wearing the same epic name?

Common mistakes

• Cutting the aha to hit a date. You shipped a different product and learned nothing about the original bet.
• Cutting instrumentation. You cannot tell pivot from persevere.
• Relitigating Must/Should daily. Revisit once mid-cycle.

Check yourself

To hit the date, you drop undo on a delete-all action. Allowed? No. Undo for destructive actions is a trust basic, not polish.

A late request adds a second persona. How do you decide? Check the one-line core value. If the cut (or add) breaks it, it is a different product.

Key takeaways

• Cut personas, extra surfaces, rare-case automation, settings and non-comprehension polish first.
• Never cut the aha, trust basics, or instrumentation.
• Must / Should / Delight is for this appetite only. Revisit once, not daily.

Further learning

Next: decide pivot, persevere, or kill from evidence. Map: MVPs and scoping.