Scoping & cutting
Deciding what NOT to build. The most underrated PM skill.
The short version
Shipping is mostly subtraction. The skill is finding the smallest slice that delivers the core value and tests the core risk — then having the nerve to cut everything else to a later phase. Scope is the one lever a PM fully controls; learn to pull it deliberately.
Why it matters
Every feature you add multiplies cost: more to build, test, document, support, and maintain forever. The instinct to add is natural and almost always wrong. The discipline to cut is learned and almost always right.
Cutting well is not cutting quality — it is cutting surface area. A small thing done completely beats a large thing done partially, because the small thing can actually ship, be measured, and inform the next slice.
How to box it
Common mistakes
Confusing "minimum" with "low quality" — the slice should be small but complete.
Cutting by feature gut-feel instead of by core-job and risk.
Leaving cuts implicit, so they quietly creep back in during build.
Gold-plating the first version when you should be learning from it.
In a startup
Cut harder than feels comfortable. Speed-to-learning is the only metric; a rough slice in users’ hands beats a polished one in two months.
In an enterprise
Cuts need a paper trail — stakeholders will ask where their feature went. Frame "later" as a sequenced roadmap decision, not a rejection.