I have shipped a lot of things across twenty years at Microsoft, Adobe, Salesforce, and 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, because there was nothing to give an award for. That is the whole problem with how we evaluate product leadership.
The kill that mattered
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. Then the ground moved: the customer problem got smaller, a competitor partially solved it for free, and our own strategy shifted toward a different bet. None of those changes were dramatic in 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. 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. The answer was clearly no. So we killed it, reassigned the team to the bet that actually mattered, and that redirected work became one of the better outcomes of the 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.
Why the industry rewards backwards
Launches are legible. A launch is a date, a press release, a metric, something 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: an absence, a cost you did not pay, a quarter you did not waste. It is invisible by construction, so it never lands on a review or a board update, and never becomes the thing a leader gets promoted for. This is expensive. 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.
The enemy is sunk cost, and it wins by default because it disguises itself as commitment. The work already invested is gone either way. The only question that matters is forward-looking: is finishing this worth more than the next best thing this team could do instead. The discipline is to separate the two cleanly, out loud, every time.
Why this matters more now
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 because nobody had the engineering to spare. That filter is gone. When an agent produces a working, finished-looking prototype in an afternoon, you can make far more than you should ever ship. The bottleneck moves off building and onto deciding what not to ship. The leaders who add the most value are the ones who can look at a polished, working, the-team-loves-it artifact and still say no.
Pick the one thing on your roadmap you would not start today. 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.