My Best Product Decision Was a Kill, Not a Launch

The short version

The best product decision of my career was a kill, not a launch. I stopped something that was already built, already loved by the team that made it, and already on the roadmap, because the honest answer to "would we start this today" had become no. The industry rewards exactly backwards: launches get announced and celebrated and put on reviews, while kills get buried and quietly resented, even though a good kill often creates more value than a mediocre launch. Killing well is the rarest leadership skill in product, because every incentive points the other way and sunk cost fights you the whole time. In the AI-native present this matters more, not less, because when building collapses to nearly free, the scarce skill moves from building things to deciding what not to ship. Here is the kill that mattered most, and why the kill decision is becoming the core of product leadership.

I have shipped a lot of things across twenty years. Microsoft, Adobe, Salesforce, four startups. The launches blur together. The one decision I am most certain was correct, the one I would defend in any room, was a thing I made sure never shipped at all. Nobody gave me an award for it. There was nothing to give an award for. That is the whole problem with how we evaluate product leadership, and it is the point of this post.

The kill that mattered

I will keep this sanitized, because the specifics belong to a former employer, but the shape is exact and it is one a lot of you will recognize.

We had a feature that was most of the way built. Real engineering invested, a team that believed in it, a slot on the roadmap, and a VP who had championed it publicly. It had been the right idea when we started. And somewhere in the building of it, the ground had moved. The customer problem it solved had gotten smaller, a competitor had partially solved it for free, and our own strategy had shifted toward a different bet. None of those changes were dramatic on any given week. Together they had quietly turned a good idea into a thing we were finishing only because we had started it.

The room wanted to ship it. Of course it did. People had poured months in. Killing it meant telling a team their work would not see daylight, telling a VP their public bet was off, and walking into the next review with nothing shiny to show. Every social and political force in the building pushed toward shipping. The only thing pushing the other way was the answer to one question: knowing everything we now knew, would we start this today. And the answer was clearly no.

So we killed it. Reassigned the team to the bet that actually mattered, took the short-term hit of disappointing people, and moved on. The thing we redirected them to became one of the better outcomes of that year. Nobody ever connected the two, because you cannot see the launch that did not happen, and you cannot celebrate the months you did not waste.

“

You cannot see the launch that never happened. You cannot celebrate the months you did not waste. That is exactly why killing well is the rarest skill in product.

”

Why the industry rewards exactly backwards

Launches are legible. A launch is a date, a press release, a metric, a thing you can point to in a review and a thing a board can understand. So the entire org learns to optimize for the things it can celebrate, which means it learns to optimize for shipping, regardless of whether the thing should ship.

A kill produces nothing visible. It produces an absence, a cost you did not pay, a quarter you did not waste, and none of that shows up on a slide. It is invisible by construction. So it never makes it onto a performance review, never makes it onto a board update, and never becomes the thing a leader gets promoted for. The most valuable decision a product leader makes is also the one the org is structurally blind to.

This is backwards and it is expensive. A good kill frequently creates more value than a mediocre launch, because it frees a team from a losing bet and points them at a winning one. But the org has no instrument to see that value, so it under-rewards the harder, scarcer, more valuable skill, and over-rewards the easier, more visible one. We end up with product cultures full of people who are excellent at shipping and terrible at stopping, which is how roadmaps fill with things nobody would start today.

Sunk cost is the enemy, and it always wins by default

The reason kills are hard is not really politics. It is sunk cost, and sunk cost is one of the most powerful forces in any product organization because it disguises itself as commitment.

The work already invested is gone either way. The money spent, the months burned, the engineering done, all of it is sunk, and none of it should weigh on the decision in front of you. The only question that matters is forward-looking: is finishing this worth more than the next best thing this team could do instead. But that is not how it feels in the room. In the room, the months invested feel like a reason to finish, when they are nothing of the kind. They are a reason it is hard to think clearly, not a reason to keep going.

The discipline is to separate the two cleanly, out loud, every time. Here is what is already spent, and it is gone regardless. Here is the value of finishing, judged fresh, as if we were deciding to start today. If the fresh decision would not clear the bar, you kill it, no matter how full the thing already is. This is the same logic underneath why I argue you should kill the roadmap as a fixed commitment: a roadmap that cannot kill its own items is just sunk cost with a Gantt chart.

“

The only question is: knowing what we now know, would we start this today. The months already spent are not a reason to finish. They are a reason it is hard to think.

”

Cheap building makes the kill the scarce skill

For most of my career, the build itself was a filter. You could not afford to make many things, so the cost of building forced you to choose, and a lot of bad ideas died simply because nobody had the engineering to spare on them. The expense did some of the killing for you.

That filter is gone. When an agent can produce a working, finished-looking prototype in an afternoon, you can make far more than you should ever ship, and nothing about the cost stops you anymore. The bottleneck moves. It moves off building, which is now nearly free, and onto deciding what not to ship, which is now the scarce thing. The leaders who add the most value in an AI-native org are the ones who can look at a polished, working, the-team-loves-it artifact and still say no, because the question was never whether you could build it. It was always whether you should.

This connects directly to the failure mode I wrote about in the prototype graveyard: cheap building does not make teams more correct, it makes them more prolific, and a flood of buildable things is only an asset if you have the judgment to kill most of them. The kill decision is becoming the core of product leadership, not a sad footnote to it. In a world where anything can be built, the person who decides what dies is doing the most important work in the room.

What to do this week

Pick the one thing on your roadmap that you would not start today. You know which one it is. It is the thing that was a good idea once, that has quietly stopped being one, that you are finishing mostly because it is already partly built and stopping it would be awkward. Name it, out loud, to yourself first.

Then do the hard thing: separate the sunk cost from the forward value in writing, and if the fresh decision is no, kill it this week and redirect the team. You will get no award and no applause, and the value you create will be invisible to everyone but you. Do it anyway. The launch nobody sees is the rarest and most valuable thing a product leader ever ships.

Sources: Silicon Valley Product Group on product decisions and prioritization; Harvard Business Review on sunk cost and decision making; First Round Review on killing projects and roadmap discipline.