Kill

the four levels

Anchored at every rung. The blockquote at each level is panel-authored and pulled live from the rubric — edit anchors via the panel tooling and they appear here.

how to develop it

The most leveraged move for developing Kill is to build the trigger *before* you need it. When you're pitching a bet, add a line to the brief: "we'll kill this if X hasn't happened by Y." Then hold yourself to it publicly. The pre-committed trigger does two things: it separates the kill decision from the ego at the time you're making it (you're not deciding you were wrong, you're just honoring a prior commitment), and it makes the kill legible — your team understands you were applying a standard, not acting capriciously.

• Read. [Prioritization Frameworks](/manual/core-skills/strategy/prioritization) — especially the sections on opportunity cost and what deprioritization actually means. [Roadmapping](/manual/core-skills/strategy/roadmap-prioritization) — how to make space on a roadmap visible to the team so a kill is understood as creating capacity, not admitting failure. [Creative Destruction](/manual/core-skills/strategy/creative-destruction) — the strategic frame that makes kill feel like product hygiene rather than personal defeat.
• Practice. Retrospective scenarios where you're handed a 6-month project with mixed evidence and asked to make the call. The question to test yourself: "am I still defending this because the evidence supports it, or because I own it?"
• Write. The canonical Brief test for Kill: "You championed this bet 6 months ago. Here's the data since launch. Make the call, name the failure mode, and describe the next thing you'd build — and why it's different, not just a pivot."
• Coach yourself. After every quarterly planning cycle, ask: "What did I keep alive this quarter that I was privately uncertain about? What would it have taken for me to name that uncertainty in the room?"

how to spot it in others

• In a planning review, they're the ones who say "I think we should stop" when the evidence is early but directional — not waiting for the inevitable.
• They can name the specific moment they changed their mind about a bet, and they're specific: not "it wasn't working" but "retention at day-30 was 4%, and we'd modeled 18% — nothing we tried moved that needle."
• When they announce a kill, the tone is matter-of-fact. No excessive apology, no blame-shifting to market conditions. "We were wrong about the assumption. Here's what we learned. Here's what's next."
• They distinguish cleanly in conversation between a kill, a pivot, and a descope. If you probe, they can tell you which one they're doing and why.
• After a kill, they do something with the freed capacity quickly. The kill is in service of something, not just an act of discipline.

three failure modes we see often

1. The slow leak. The most common kill failure — defunding without announcing. The budget gets redirected, the engineers get re-allocated, the sprint board stops getting updated, and the feature just quietly ceases to exist. Nobody says it's dead; it just stops being mentioned. The feature is killed but the PM never owned the call, which means no one learned anything and the team's trust in the PM's candor is quietly eroded. Slow leaks are especially common for features a PM is personally attached to — the silence feels protective, but it reads as cowardice.
2. The rebrand kill. Calling a failed bet "v2" instead of "dead." The original bet failed to achieve its goal; instead of naming that and returning the resources, the PM proposes a "significant rework" that keeps the original investment alive under a different name. The rebrand kill is seductive because it lets you feel like you're still moving forward. It costs the team a second lap of work on something that the first lap already answered, and it trains the people around you that the PM can't say when they're wrong.
3. The executive bury. Waiting for leadership to name the kill for you, and then presenting that as a joint decision or an external mandate. "Leadership decided to shift priorities" as the explanation, when the PM has known for months that the bet wasn't working. The executive bury is particularly damaging because it costs the PM the one good thing a clean kill produces: trust. When you wait for someone else to say what you already knew, the people who were watching know exactly what happened.

adjacent competencies — how this differs

what good looks like in the wild

The PM had been running the in-app recommendation engine for eight months. It had shipped on time, the infrastructure was solid, and the team had worked hard on it. Usage data showed it was being seen — the widget loaded, the recommendations appeared — but click-through was running at 0.6%, against a modeled 4%. They'd run three rounds of iteration: A/B tested the copy, changed the placement, tried personalization. Nothing moved the number more than a fraction of a percent.

At the six-month mark, quietly, the team stopped talking about the feature in standups. Engineers had moved to other things. The PM kept including it in the roadmap update slides — listed under "optimization in progress." Leadership had stopped asking about it.

The call came at month 8, not from the PM, but from a VP who was cleaning up the quarterly review deck and noticed the widget was still consuming 12% of the backend's personalization budget. "What's the plan here?" The PM explained. The VP said "let's park it." The PM agreed. It was logged as a "strategic deprioritization."

That's not Kill.

Kill looks like this: at month 5, same PM, same evidence. The PM writes a short doc — two paragraphs, not a post-mortem, not a lengthy autopsy. "Here's what we thought would happen. Here's what happened instead. The gap is too large to close with iteration — the underlying assumption about how customers discover content inside the app was wrong. I'm proposing we kill the recommendation engine, move the two engineers to the search refactor, and use the personalization budget to test a different surface. Here's the spec for that test." Sent to the team. Sent to the VP. Posted in the product channel.

Reaction: one person pushed back, asked for another month. The PM said: "I understand the instinct. I had it too. But we set our signal threshold before we started, and we've passed it. If we find evidence in six months that I was wrong about the surface, I'll be the first to propose we revisit." The conversation was over in one thread.

The recommendation engine was off the roadmap by month 6. The search refactor shipped by month 9. Two of the engineers from the original team contributed to it. In the retro, one of them said: "I trusted the call because she made it before she had to."

“

That is Kill at L4. The value wasn't in being right. It was in owning the wrong, early, clearly, in writing, in a way that freed the team to build the right thing.

Map — the other two in this skill