The Killed List: Why Aggressive Scope Cuts Are a Scheduling Primitive

A rebuild is a chance to do it better. The temptation is always to keep what "mostly works" and cut only the parts that obviously broke.

Three days before we needed to ship, the old system had 40+ modules, two coexisting engine versions, a 12-factor scoring model, a dead staging phase, and a handful of experimental signal sources that nobody was sure whether to trust.

We cut it to six modules on day zero.

The Cuts Were Not Negotiable

They were in the product requirements document as an explicit "out of scope" list before any code was written. Not as a wishlist. As a contract.

The killed list named specific patterns: a staging phase that historically produced false confidence, an experimental model that would have been a scoring factor with insufficient calibration data, an optional auxiliary feed pitched as "required" by one stakeholder, a dual-engine coexistence path that was carrying two test suites for two codebases that no longer agreed on anything.

Every one of those cuts was pitched back at me during the build. Every one had a reasonable-sounding argument under deadline pressure.

"Can we descope that module to a stub to hit the deadline?"

"Can we add the auxiliary feed back to improve quality?"

"Can we do a staging phase to prove things work before production?"

Each pitch was reasonable in isolation. Each was refused with reference to the requirements document.

The Timeline Works Because of the Scope, Not Despite It

The three-day timeline was not achievable despite the aggressive scope. It was achievable because of it.

Six modules is three days of work. Forty modules is three weeks of work. The project survived because the killed scope was killed on paper before anyone felt the urgency to resurrect it.

The lesson: scope discipline requires pre-commitment that precedes the pressure window. Writing the killed list in the product requirements document, weeks before writing any code, is what makes the list defensible later. Writing it in a commit message during a rushed Saturday is not.

The Two Lists Do Different Work

The requirements document says two things: what we're building, and what we're not building.

The second list does most of the work.

Without it, every stakeholder with a tangentially-related wish-list item becomes a negotiation during the build. With it, every wish-list item has already been adjudicated — in writing, before the pressure window. The build-time conversation becomes refusal with a citation, not re-litigation.

The Transfer

"We built fast" is project-specific. Non-transferable.

"We built fast because the requirements document pre-committed the cuts and we defended the scope under pressure" is transferable.

That applies to any rebuild. Any time-boxed project. Any organization where deadline pressure compresses scope debates into the last 48 hours.

When you inherit a rebuild, write the killed list before the build list. Every item on the killed list is a future conversation where someone will pitch it as a shortcut or a safety add. Having the pre-commitment in writing is what lets you refuse without relitigating.

The killed list is a contract with your future, tired self. Sign it while you're rested.

Visual Summary

click to expand