Every feature has a launch plan, but almost none have a kill plan. In the AI era, that asymmetry is becoming dangerous.
Every product team I've worked with has a launch checklist with defined success metrics, stakeholder alignment, go/no-go meeting schedules, etc. They’ve got the marketing briefed, documentation updated, and overall, there's a shared understanding of what "ready to ship" looks like.
Now, if I ask the same team: what would have to be true for us to kill this feature in production or after launch? What metric, at what threshold, over what timeframe, would trigger a rollback?
The silence that follows is almost universal.
We have built an entire product management discipline around the art of launching features into production, but almost nothing around the discipline of removing underperforming features after launch. And in 2026, that gap has become the bottleneck.
The economics of shipping have inverted. AI-assisted coding has collapsed the cost of building a feature from weeks to hours; what used to be a quarterly bet is now a Tuesday afternoon.
Anthropic's Claude team is the cleanest illustration: they shipped 120+ features in 90 days, a cadence of roughly one every 18 hours, with engineers running multiple parallel agents instead of writing PRDs. The interesting part is what they do with it. Boris Cherny's team prototyped hundreds of versions of Agent Teams before shipping roughly 30 prototypes of the condensed file view; 80% never shipped. They build more prototypes, kill most before launch, and remain equally willing to retire features that don't prove their value in production.
That kill rate is the quality process. When building is cheap, deciding what doesn't deserve to live becomes the act that creates value. And most product orgs are still optimized for the old constraint, celebrating launches, instrumenting roadmaps, measuring shipped features, with no equivalent muscle for shutting things off.
Flags are the infrastructure that closes that gap.
The cost nobody calculates
Every feature that stays live has a cost, even if nobody's tracking it. There's the direct cost: engineering maintenance, bug fixes, edge cases, support tickets, documentation updates, and infrastructure overhead. A feature that serves 2% of your user base still needs to be tested against every release, still breaks occasionally, and still consumes attention when it does.
Then there's the cost nobody puts in a spreadsheet: opportunity cost. Every feature that lingers takes up cognitive space in the codebase, in the product surface, in the team's mental model of what the product is. It makes the next decision harder because there's more to consider, test against, and explain to a new hire trying to understand why this thing exists. Product complexity is a compounding tax on velocity, and every feature without a kill plan is a permanent addition to that tax.
The companies that ship fastest aren't just good at launching, but also ruthless about removing. They understand that a product's quality is defined as much by what's not in it as by what is. But ruthlessness without criteria is just chaos. You need a framework in place before launch, for when and how something gets pulled.
Components of a kill criterion
Kill criteria are the exit conditions that you define alongside your success metrics before a feature ships. They answer the question: if this feature doesn't work, how will we know, and what will we do about it?
A useful kill criterion has the following four components:
- What are you measuring?
- At what level does the metric signal a failure?
- How long are you giving it?
- What happens when the threshold is breached?
For example: "If checkout completion rate drops below 68% within 14 days of launch, we roll back to the previous flow and run a post-mortem before re-shipping." That's a kill criterion. It's specific, measurable, time-bound, and the action is pre-decided. There's no meeting required, no politics, no one has to be the person who says, "Let's kill this" in a room full of people who built it.
Killing a feature is politically and emotionally harder than launching one, as any PM would acknowledge. After all, someone in the team championed it, a team spent a quarter building it, and a VP mentioned it in a board deck.
Kill criteria remove the personal from the decision. The feature is killed because it didn't meet the bar the team agreed on before they had anything to defend. And the ways features fail are more varied than most teams realize:
- Adoption failures - nobody uses the feature
- Perception failures - an objective improvement feels like a downgrade
- Performance failures - the feature quietly degrades the product
- Monetization failures - revenue erodes instead of growing
- Trust failures - privacy or security lines get crossed
Kill criteria need to account for all of these.
How AI makes this non-negotiable
Everything I've described so far applies to deterministic software features that behave consistently every time. AI features don't work that way.
An AI feature works differently every time, generating a slightly different response, recommendation, or output for each user, session, and input each time. It can perform brilliantly during testing and degrade unpredictably in production when it encounters edge cases or distribution shifts that weren't present in your evaluation set.
This changes the risk profile of shipping. When you launch a traditional feature, the worst case is usually a bug that produces a consistent, identifiable error. When you launch an AI feature, the worst case is a subtle, inconsistent degradation that's invisible in aggregate metrics but damaging to individual user experiences. It could be a recommendation that's slightly off, a subtly wrong summary, a generated response that's appropriate 98% of the time and harmful 2% of the time.
Kill criteria for AI features can't just be about the average performance metrics. They need to include guardrail metrics, defining the thresholds for harmful outputs, hallucination rates, latency spikes, etc. For example, a 2.4% failure rate might be acceptable for a search ranking algorithm, but catastrophic for a customer-facing AI assistant that gives medical or financial information.
Every AI feature ships with a kill criterion, performance thresholds, and safety thresholds, defined before launch, and not after the incident.
Every kill criterion is wired to a flag, so shutting it down doesn't require a deploy, a war room, or an engineer at 2 a.m. And every flag has a named owner in product, not just in engineering.
If you can't draw that line from threshold to flag to owner, the feature isn't ready to ship, no matter how good the demo looked.
Shipping velocity demands killing velocity
There's a broader point here that goes beyond AI. The entire industry is moving toward faster shipping cycles with continuous deployment, weekly releases, and rapid experimentation. The philosophy is right because the speed of iteration is a genuine competitive advantage.
But shipping velocity without killing velocity is how products become bloated, confusing, and slow. If you can launch a feature in a week but it takes a quarter of internal debate to remove one, your product only grows. It never sharpens. Every fast-shipping team needs an equally fast mechanism for pulling things that didn't work, along with pre-committed criteria to trigger it.
How to start
If your team doesn't currently define kill criteria, start with your next launch. Add one section to your launch document, titled "Conditions for rollback."
Define the metric, threshold, timeframe, and action, and make it a required field.
Then do a retrospective audit. Look at the last ten features your team shipped. How many are still live? How many have been evaluated against their original success metrics? How many would you ship again, knowing what you know now? The gap between "features shipped" and "features validated" is the size of your kill criteria problem.
The discipline is simple. Every feature that is worth building is worth defining the conditions under which you'd stop building it. Every launch plan deserves a kill plan. The teams that build both will ship faster, operate leaner, and build better products.
The teams that only build launch plans will keep shipping. They just won't know when to stop.
