What is a Kill List and how do you run one?

THE SHORT ANSWER

A Kill List is the standing counterpart to a roadmap: a maintained, revisited list of features, projects, and rituals that are candidates to stop. You run it on a recurring cadence with one entry test applied to everything already shipped or in flight: would we start this today, knowing what we now know? If the honest answer is no, it goes on the list, and the default becomes killing it unless someone can defend keeping it. The list exists because every incentive rewards launching and punishes stopping, so a good kill needs a structural home or sunk cost wins by default. When building collapses toward free, deciding what not to ship becomes the scarce skill, which makes the Kill List more valuable, not less.

The industry rewards launches and buries kills, even though a good kill often creates more value than a mediocre launch. A Kill List is the structural fix for that imbalance. It gives stopping a home, a cadence, and a test, so the kill decision gets the same fair hearing a launch gets by default.

What it is

A roadmap is the list of things you intend to start. A Kill List is its missing counterpart: the maintained list of things you should stop. Features that no longer earn their maintenance. Rituals that survive only by habit. Projects that were a good idea under conditions that no longer hold. The list is not a graveyard of things already dead. It is a working queue of candidates, revisited on a cadence.

The one entry test

Everything on the list gets there the same way. Apply one question to anything already shipped or in flight: would we start this today, knowing what we now know?

That test is the whole trick, because it points at the future instead of the past. The usual argument against killing something is the effort already spent building it, and sunk cost is a bad guide to a forward decision. "Would we start this today" launders the sunk cost out of the question. If the honest answer is no, it belongs on the list, and the burden flips: the default is to kill it unless someone can make the case to keep it.

How to run it

Give it a cadence, monthly or quarterly, on the same calendar as your planning. Put candidates on the list from three sources: things that fail the entry test, things whose maintenance cost is climbing without matching value, and things a direction metric says are quietly decaying. Then, for each one, force the keep-or-kill decision rather than letting it drift. A kill you decide is worth more than a kill that happens by neglect two quarters later.

The reason this needs to be a named list with a named owner is that every incentive fights it. Launches get announced and celebrated; kills get buried and resented. Without structure, the kill never gets proposed, and the surface area only grows.

Why it matters more now

The best product decision of my career was a kill, not a launch. I stopped something already built, already loved by the team that made it, and already on the roadmap, because "would we start this today" had become no. Nobody gives you an award for that. There is nothing to give an award for. That is exactly why it needs a list.

In the AI-native present this matters more, not less. When building collapses to nearly free, the scarce skill moves from building things to deciding what not to ship. The Kill List is where that skill lives. Start one this week with a single line: pick the one feature you would not start today, and decide.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read