Every project has four variables: scope, time, cost and quality. In practice, three of them are nailed to the floor.
Time is usually fixed by something external — a funding round, a trade show, a regulatory date. Cost is fixed by a budget approved months ago. Quality is the one nobody will admit to trading, and rightly so; the "we'll clean it up later" version of quality is just deferred cost with interest.
That leaves scope. It is the only lever with any real travel in it, and it is the one teams reach for last.
Why teams resist cutting scope
Cutting scope feels like failure. Every feature on the list has someone attached to it who argued for it, and removing it reads as a judgement on them.
So instead, teams do the things that feel like progress:
- Add people. Brooks was right in 1975 and is still right. A new engineer costs a productive engineer a fortnight of onboarding before returning anything.
- Work longer hours. Buys perhaps two weeks of apparent speed, then pays it back with interest in defects and attrition.
- Cut testing. Converts a visible schedule problem into an invisible quality problem that surfaces after launch.
All three are worse than the conversation nobody wants to have.
How we run the conversation
In the first workshop of any engagement, we do a forced ranking. Every proposed feature goes on one list, in strict order, with no ties permitted. Not "high, medium, low" — an actual ordered list, because tiers are where teams hide from making decisions.
Then we draw a line at what the timeline supports, and everything below it is explicitly out. Not "phase two" — out, unless something above the line gets cut to make room.
The number of features nobody can defend once they are forced to rank them against each other is consistently around a third.
For Atlas we cut 40% of the original scope in week one. They launched on time, raised their Series A on the traction, and shipped six of the cut features over the following year — with real user data telling them which six mattered.
The test for a feature
One question usually settles it: if this shipped and nobody used it, would we notice?
If the answer is no, it belongs below the line. You can always add it later, informed by what real users do. What you cannot do is get back the six weeks you spent building it before launch.