Killing the Product You Love: How to Pull the Plug Before It Drains the Team

Most leaders treat shutdown like failure. So they wait. They wait for one more sprint, one more pivot, one more quarter, and the dying project keeps eating people and time the whole way down. The skill nobody trains for is the opposite of launching. It is knowing when to stop, and having the proof and the support to stop cleanly. That decision is just as strategic as the launch. Here is how to make it without flinching.

The hardest call you own is the one to stop

We celebrate launches. Nobody throws a party for a smart shutdown. That bias is the trap. Antonio da Fonseca Neto argues that knowing when to kill a product is as important as launching one, and he is right. A product that fades while you keep feeding it does not just waste money. It ties up your best people on work that will not pay off.

Think of the call to stop as a real deliverable, not an admission of defeat. You are reallocating your scarcest resource, which is your team's attention. That is the job.

Why your past spend keeps lying to you

The reason leaders cannot stop is sunk cost. You poured a year and a budget into something, so it feels insane to walk away. But the money and time are already gone whether you continue or not. Itay Sagie frames the fix plainly: escape the past to secure the future. The only question that matters is future value, not past spend.

Here is the test that cuts through it. Ask your team: if we were starting today, with no history, would we build this? If the answer is no, your past investment is holding your roadmap hostage. The honest move is to act on the answer you already know.

Build the case before you make the call

A gut call to kill a product will get torn apart in the room. You need data and you need buy-in, in that order. Gather the numbers first: engagement, retention, the cost to keep the lights on. Then line up the people who have to agree, because a shutdown with no buy-in becomes a fight that drags the project on longer.

Before you reach for the off switch, be honest about whether you have actually missed product-market fit or just under-built. Éamon Cullen lays out steps to recover a product nobody wants, pointing to Climate Corporation's pivot from WeatherBill. Sometimes the right move is a sharp turn, not a funeral. The data tells you which one.

Get the founders to say what winning means

A lot of dying projects survive because nobody at the top agrees on what success looks like. One person is chasing revenue, another is chasing a vision, and the gap stays hidden until the project is on life support. Finn Lawrence offers a single question to surface this: what does it look like when you win?

Ask each leader to describe their end state out loud. You will often find their pictures do not match. That mismatch is why the kill decision keeps stalling. Get aligned on the win condition first, and the call to keep going or stop becomes obvious instead of personal.

Stop building on a fixed list of features

The deeper fix is upstream. If your roadmap is a list of features the team has already committed to ship, every one of them becomes a sunk cost in waiting. Marty Cagan offers a cleaner frame with the opportunity backlog, a prioritized list of problems to explore rather than features to build. Cagan notes that teams doing real discovery find half of a roadmap is not worth building.

When you frame work as problems, not promises, dropping one feels normal, not like a loss. You did not kill a product. You learned the problem was not worth solving, and you moved on. That mindset makes the hard call routine.

The deep cut

The thing that is easy to miss: the cost of keeping a dying product alive is not mostly money, it is morale. Billy Sweetman's piece on design debt shows how dragging along work that should have been cleaned up grinds people down, where simple fixes take a whole day and developers burn out explaining why. A fading product does the same thing at a larger scale. Every month you delay the kill, your best people learn that effort here does not matter. When you finally do pull the plug, you are not just saving budget. You are telling the team that their time is worth protecting. That is the real return on a clean shutdown.

Three questions for your team

• If we were starting today with no history, would we build this product? If the answer is no, name the past decision that is holding the roadmap hostage and decide what to do this quarter.
• What does winning look like to each leader here, and where do our pictures stop matching? Get that on a whiteboard before the next kill-or-keep decision, not after.
• For the project we are unsure about: do we have the data to back a sunset call, and who has to buy in for it to stick? Assign someone to gather both this week.