Your AI Rollout Is Missing a Kill Rate

I shut down AIM. Twenty years, and at its peak one of the most-used messenger apps. By the end the call to turn it off was mine, and it was a hard one. It was not the hardest one I made.

The hardest was Yahoo! Groups. At its peak, 115 million people had used it, ten million groups, two decades of communities that formed nowhere else. By the time the decision reached me it was in decline, but it was not dead. Millions of people still showed up. Real conversations, real history, in some cases the only place a particular community had ever lived.

I shut it down anyway.

Not because it failed. Because keeping it alive cost more than it was worth, in the only currency that actually matters, focus. Every engineer maintaining it, every security patch, every migration it complicated, was attention not spent on where we were going. The math was never really about the product in front of me. It was about everything we would not get to if we kept carrying it.

That is what a kill decision actually is. Not declaring something a failure. Deciding that a thing which still works, that people still use, is no longer worth what it takes from the rest. It is the least satisfying call a product leader makes, because there is no win to point to. You stop spending effort on the thing, you absorb the complaints, you redirect the people, and you move on.

That is what a kill decision actually is. Not declaring something a failure. Deciding that a thing which still works, that people still use, is no longer worth what it takes from the rest.

I made that call more than once across a career. It was rare, and the rarity was not an accident.

That is the part that changed.

The accidental governor

For most of my career, building was the expensive part. You wanted to ship something, you needed designers, engineers, weeks, sometimes quarters. That slowness was annoying. However, it was also a filter. Most bad ideas died in the friction before they ever reached a user, because nobody wanted to spend three months on a “maybe”.

AI removed the friction.

That is the part everyone celebrates, and they are right to. But the friction was doing a second job nobody noticed. It was the accidental governor. It quietly killed the wrong-direction bets before they cost anything, just by making them too slow to be worth it.

Now the governor is gone. Your team can build the “maybe” in an afternoon. So it gets built. And once it exists, once someone put real work into a thing that runs, killing it is a fight. You are not deciding whether to start. You are deciding whether to throw away something that already works.

That is why the rollout is not landing in the numbers. The tools work fine. The teams are shipping more than ever. They are shipping more of everything, the right things and the wrong things at the same speed, because the thing that used to sort them, slowness, is gone, and nothing deliberate replaced it.

Faster building without faster deciding does not compound. It just hands you a bigger pile to sort through in the end, and no more time to sort it.

The PM split

The individual wins are real. Plenty of people on your team have them already. What stalls is the jump from individual AI leverage to team AI leverage, because that jump runs through the org chart.

Marty Cagan famously draws three kinds of product teams: delivery, feature, and empowered. The product role is a different job in each, and on my org charts those jobs had names. The project/program manager, who keeps the trains running and the dependencies tracked. The feature PM, who owns a surface and ships against a roadmap someone above them set. The empowered product manager, handed a problem and trusted to decide what to do about it, including the decision to do nothing.

Where I part with the orthodoxy is what happens to the feature manager.

The program manager’s work is the first to get absorbed. Most of it was coordination, and coordination is what the machine is best at. The status doc writes itself, the dependency map updates itself, the red flag detection is automated, and that role thins out fast.

The feature manager is the one most people write off. The belief is that the role disappears, that once AI builds from a spec, you no longer need someone shepherding features. I believe the feature manager will change shape, not disappear. The job used to be writing the spec and coordinating the build. Now building is the cheap part, so the work becomes directing it. Stand up three versions before lunch, see which one holds, throw the other two away.

I believe the feature manager will change shape, not disappear.

Although throw away is the wrong frame. A prototype is rarely a mini-product waiting for a verdict. More often it is a pass in a loop. The two that die are input, and what they taught you shapes the next one. The whole flood of half-built things runs straight through the feature manager’s hands, which puts them exactly where the hardest decisions now get made.

That is the opening. Not to hand the feature manager the kill decision. To change what they run. They become the first filter, pruning three prototypes down to one against a standard someone above them set.

Setting that standard is the empowered manager’s job, and it is the brains of the whole system. What good looks like. What a prototype has to clear. When something that works still dies, because it is not worth what it takes from the rest. That is the one job AI did not make easier, and it is the job nobody is explicitly assigned. When building was slow, the roadmap did the filtering on its own, because you could only afford to build so much.

Now. Nothing filters on its own. Someone has to own the kill rate, on purpose, or the team ships every prototype that happens to work. That someone is the empowered manager, and if no one is named, the answer is nobody, and the pile just grows.

Why nobody kills anything

Naming the owner is the easy part. Getting the kill to actually happen is where it breaks down, and the reason is not capability. It is incentives.

Think about what killing a prototype requires. Someone built it. They are proud of it. It works, it demos well, a few people already depend on it. Ending it means telling a person their good work will not ship, and absorbing the disappointment that follows. I have made that walk more than once. There is no launch to point to afterward, nothing to announce. The reward for a good kill is that something quietly did not happen, and nobody puts that in a performance review.

Part of the problem is the frame. The team treats each prototype like a small product, with an owner and a roadmap and a future, so every kill feels like a funeral. In a working loop it is nothing of the sort. The prototype was a pass. The kill is the lesson. What it taught you is the deliverable, and it shows up in the next version. Teams that hold that frame kill faster and carry less grudge. But that frame does not install itself.

The prototype was a pass. The kill is the lesson. What it taught you is the deliverable.

And the incentives fight it. Look at what the organization celebrates. Shipping, velocity, features out the door, the demo that got applause. Credit flows to building. Almost none flows to the discipline of not building, and none at all to the lesson extracted from a thing that died. So the person you just put in charge of the kill rate is being asked to do the one thing the system around them punishes.

That is why, by default, the kill belongs to nobody. Not because product leaders are weak. Because the reward structure was built for a world where building was the expensive, scarce act worth celebrating. That world paid out on output. This one bleeds out on it. Until a good kill counts like a good launch, the owner you named will keep doing the safe thing, which is letting the prototype live.

Two ways in

None of this fixes itself, and it does not fix with a memo either.

You will hear that the mess is just the cost of transformation, that it gets worse before it gets better. As a description of what usually happens, fair enough. Most rollouts speed up the old workflow, twenty things strain at once, and the team spends a year cleaning up. But usually is not the same as inevitably. The mess is the default path. It is not the only one.

Be honest about what the old system did for you. The spec reviews, the resourcing fights, the queue for engineering time. All that friction forced you to slow down, and slowing down forced you to choose. You could not build everything, so you argued about what deserved to exist, and weak ideas died in that argument before they cost real money. That was the governor. Nobody designed it. The old system imposed it, and it quietly did your deciding for you.

AI tore it out. Which leaves two ways into this era.

The first is to let AI flood in, watch what breaks, and bolt on the checks afterward. That is what most companies are doing right now, mostly without choosing it.

The second is to design the replacement before you flip the switch. Decide where AI enters and where it does not. Define what good looks like, in your context, before the prototypes pile up. Make the kill criteria explicit while everyone can still think straight, so the hard decisions are owned before they are urgent.

And do not let the definition live in one person’s head. Criteria only govern when the team holds them together. Same tools with different definitions of good just makes a team faster at disagreeing. Slowness governed by accident. The replacement has to be designed on purpose, and owned by someone with a name.

Criteria only govern when the team holds them together. Same tools with different definitions of good just makes a team faster at disagreeing.

Both paths end at the same place, a team that builds fast and decides deliberately. The difference is what it costs to get there, in time, in trust, and in the pile of half-dead prototypes nobody wants to talk about.

The deliberate path starts with an audit. Where does the time actually go. Which workflows change, which teams get pulled in, what gets optimized before the switch flips. It is the least glamorous work in the building, and it is how you opt out of the mess.

If you run a team, you can start smaller this week. Pick one prototype in flight and ask three questions out loud. What would have to be true for this to ship. What kills it. Who decides. The silence after the third question tells you where to start.

What the killing buys you

The point of owning the kill is not control. It is what the killing buys you.

Every prototype you end on purpose is attention returned to something that deserves it. The team that decides deliberately is not the slower team. It is the only team whose speed compounds, because all of it points one direction. And the people on that team get to spend themselves on the work that actually needs them. The judgment, the craft, the direction, the outcomes.

AI did not take that work away. It revealed it, by absorbing everything around it.

Shutting down Yahoo! Groups, the hardest part was knowing what it cost the people who loved it. What made it right was what it bought everyone else. The room to focus. That trade has not changed. It just stopped being rare.

Your team is making it every week now, whether anyone owns it or not. So start at your next review. Define what a kill looks like, and put a name on who owns it. And do not just celebrate the launches. Celebrate the kills, say why, and share what they taught. Those are success stories too.