Cutting Scope

The Cut Is Already Coming

Scope cuts happen on every game, at every budget level, across every genre. The illusion that a full feature list survives to ship is one that teams build themselves, usually because committing to cuts early feels like admitting failure. It isn't. It is the core skill of production.

The problem with deciding late is arithmetic. A feature that exists only in a design document costs nothing to remove — delete the paragraph, move on. A feature that is designed, blocked out, partially built and integrated into the level flow costs something closer to the sum of everyone who touched it, plus the time to unpick the dependencies it has already accumulated. Who decides what gets cut is a separate question from when, but the when is almost always what determines how much the cut hurts.

Early cuts preserve budget. Late cuts eat it.

What Gets Cut, and Why

The candidates are broadly predictable: the feature that was always "ambitious," the mode that only one person on the team was championing, the level that never quite worked in the blockout phase, the system that was speculative from the start and never resolved into something playable. These are not necessarily the worst ideas — sometimes the ambitious feature would have been the best thing in the game. But they are the features that arrive at milestone reviews with the most open questions, and open questions late in a project are expensive to answer.

There is a useful distinction between cut and defer. A feature officially deferred — moved to DLC, a sequel, a patch — often stays in the codebase and the build, costing integration overhead and test surface right up to ship. A clean cut removes the thing. Studios that defer rather than cut frequently carry that weight into crunch, because "defer" is emotionally easier to agree to in a room than "cut," but functionally it is often the same thing with worse logistics.

A feature that exists only in a design document costs nothing to remove — delete the paragraph, move on.

What survives a cut is usually whatever is already load-bearing for something else: the mechanic that three levels depend on, the system the tutorial is built around. Those things are expensive to remove even when they are underperforming, because they have dependencies below them. This is why scope reduction conversations should happen before the dependencies solidify — before the levels are lit, before the tutorial is written around the system, before the asset pipeline has generated work that assumes the feature exists.

The vertical slice is often when the first real cuts happen, because it forces specificity. Until a team builds something to finished quality, estimates for everything else on the list are optimistic. Once that slice exists, the time-per-feature cost becomes visible, and the list that looked feasible in pre-production looks different under that light.

Deciding Early, Even When It Hurts

The discipline is making the call before the work accumulates. That means regular, honest reviews of the feature list against actual velocity — not planned velocity, actual. It means a culture where proposing a cut is not a political act, but a production one. And it means whoever holds scheduling authority having current, accurate information about what is done, what is partially done, and what is only described.

Milestone builds exist partly for this reason: they force a state-of-the-project that is inspectable rather than reported. When the build runs and reviewers play it, the gaps are visible in a way that a status spreadsheet cannot replicate. Features that are not in the build are, for practical purposes, not in the game — and seeing that early is exactly what creates the room to make a decision rather than absorb a cost.

The hardest cuts are the ones nobody disagrees are right but everyone delays. Delay is itself a decision, and it is almost always the most expensive one available.

Something always goes. The only real choice is when.