← Back to all posts

Innovation

When to kill a project and how to survive it

Yellow caution tape reading 'Kill Project Early' across a chalk-outline project figure

I've killed projects I genuinely believed in. Each time, I waited too long. The signs were there months before I acted, but I kept telling myself the next sprint would fix things.

Here's what I've learned about when it's time:

  1. The original problem you set out to solve has changed, but the project hasn't

  2. You're spending more energy defending the work than doing the work

  3. Your best people are quietly asking to move to other teams

  4. Every update meeting starts with caveats and qualifications

  5. You can't explain the value in one sentence anymore

That last one is the killer. If you need a paragraph to justify why something still matters, it probably doesn't.

Killing a project feels like failure because it is failure. I don't buy the "fail fast, fail forward" cheerfulness. It hurts. People lose work they cared about. You have to look your team in the eye and say this thing we built together isn't going to ship.

But here's how you survive it. You be honest about why. Not a sanitized post-mortem that blames market conditions. An actual accounting of what went wrong and what you missed.

Then you protect your people. Reassign them before you announce the cancellation. Nobody should hear their project is dead and also wonder if they still have a job in the same conversation.

I think most leaders wait six months too long to pull the plug. The sunk cost math is brutal, but the opportunity cost of keeping zombies alive is worse. Every dollar and hour going to a dead project is stolen from something that could actually work.

What's the longest you held onto something you knew was already over?