What to kill

The instinct of every operator is to keep adding. Add features, add hires, add initiatives, add pricing tiers. The hardest operator skill, and the one that separates excellent operators from good ones, is deciding what to subtract. What to kill. Good strategy is almost entirely about what you won't do.

Why killing is hard

• Sunk cost. Someone spent 6 months building this. Killing it feels like admitting waste.
• Identity. People define themselves by what they own. Killing a project threatens identity.
• Hope. "It just needs a little more time." It rarely does.
• Political cost. Someone executive sponsored it. Killing it is a political act.
• Absence of a forcing function. Nothing forces you to cut unless cash or capacity runs out. So most teams don't.

The kill criteria, set them in advance

The single most effective move: write kill criteria before you launch. "This initiative will be killed if, by month 6, we haven't hit X or Y." Then when month 6 arrives, the decision has been made. You're just executing on it.

Example kill criteria.
Initiative: Launch new SMB self-serve tier.
Kill if by month 6:
- Conversion rate from free trial < 4%
- MRR from self-serve < $20K
- CAC payback > 18 months
Any single one of these triggers the kill conversation. Two or three = automatic shutdown.

The quarterly kill review

Once a quarter, the leadership team does a "kill review." The format:

1. List every active initiative > 1 person-month of investment per quarter
2. For each: impact to date, cost to date, cost to continue, signal on whether it's working
3. Each leader proposes 1–2 to kill
4. Discussion: kill, continue, or modify

The rule: every leader must propose at least one kill. No exceptions. If you can't, you're not being honest with yourself.

Categories of things that need to be killed

Zombie projects

Still technically funded. No clear owner. Nobody remembers why it started. Shipping 0 value per quarter.

Pet projects

An executive sponsor loves it. Team hates it. Not actually connected to strategy. Continues only because the sponsor has political power.

Things that were right a year ago

Great idea in Q1 2024. World has changed. Still running on autopilot because no one has done the work of closing the loop.

Scope creep within still-good projects

The core initiative is fine. Three add-ons bolted onto it are not. Kill the add-ons, not the core.

Small customers costing more to serve than they pay

Usually 10–15% of a customer book. Kill by raising price or formally sunsetting.

How to kill without trauma

• Frame as a choice, not a failure. "We're redirecting this capacity to X" lands better than "this didn't work."
• Credit the effort. The team on the killed project did the work. Publicly acknowledge it.
• Explain the decision. People accept hard decisions when they understand the reasoning. They resent decisions handed down without context.
• Offer the next job. Wherever possible, the team gets a clear next assignment immediately, not a layoff or limbo.
• Document the learning. A killed project should generate a one-page post-mortem: what did we learn that we didn't know before we started?

The meta-discipline

The highest-leverage thing you can do is build a culture where killing is normal. Where every project starts with "what would make us stop?" Where quarterly kill reviews are expected, not dramatic. Where proposing a kill doesn't make you disloyal, it makes you a good steward of capacity.

What good looks like

• Every major initiative has written kill criteria at start
• Every quarter, at least one meaningful thing gets killed
• Killed projects produce a learning document, not a dead Jira board
• Teams accept kills without feeling punished

Related: Pre-mortems · OKRs without the cult · Decision logs