Scope is the most negotiated surface in product management. Every sprint, someone wants to add something. Every quarter, someone wants to cut something. And occasionally, the evidence arrives that the entire initiative should stop. This page covers the discipline underneath those decisions: how to set scope clearly, how to defend it without being rigid, and how to recognize when the right move is to halt rather than narrow.
The hardest scope decision is not cutting a feature — it is stopping a build that is already in motion. Sunk cost pressure is real. Team emotional ownership is real. The difficulty of writing a halt note to senior stakeholders is real. But a feature that is not working is not a neutral presence on the roadmap; it consumes attention, burns runway, and trains users to expect something that may not be ready. Scope management is ultimately about protecting the team's capacity to work on things that matter.
When to halt, not narrow
The instinct when a feature is underperforming is to narrow scope — ship a smaller version, cut the risky parts, find the 80% of value in 20% of the work. That instinct is often right. But there are three situations where narrowing is the wrong answer:
The core premise is broken. If the unit economics are wrong by 2x, not 20%, a smaller version of the feature still fails. Swiggy's Instamart dark store expansion at 180 orders/day against a 320 breakeven is not a sample-size problem — it is a structural failure. No trimming of scope changes the math.
Users are actively worse off. If a beta is running and users who encounter the feature are churning at higher rates than users who don't, the beta is doing harm, not just failing to help. The right response is to halt the beta, not to run it more quietly.
The hypothesis is unfalsifiable. If the only way to test the next version of the thesis is to ship to all users first, you have a discovery problem, not a scope problem. Halting to restructure the discovery approach is more useful than shipping a scoped-down version of something you don't yet understand.
You're the PM for Swiggy Instamart's Tier-2 expansion. You ran a 3-month dark store pilot in Nagpur and Coimbatore. Order frequency per dark store is 180 orders/day against a breakeven of 320. Marketing spend to acquire the first 500 households in each city ran 2.8x the Bangalore acquisition cost. Your head of expansion says the data is 'early' and wants to push to 5 more cities by Q3.
Your task: Do you halt the expansion and propose a focused fix-before-scale plan, or proceed to the next 5 cities on the grounds that the data is still thin?
your reasoning:
Where to go next
- Running the experiments that inform scope decisions: Experimentation
- Writing the PRD that captures scope clearly: Writing PRDs
- Understanding product-market fit before scaling: Product-Market Fit
- Measuring whether what you shipped actually worked: Measuring Outcomes