Every PM book in the 2010s spent 200 pages on how to launch and zero pages on how to retire. The result was a generation of products bloated with features that never worked and never got removed, because removal required someone to admit the launch failed. In 2026 the cost of carrying a dead feature has gone up: each surface has its own model costs, eval maintenance, support burden, and attack surface. So the playbook for killing features has to get better.
Deprecate on signal, not politics
The thesis is simple. A feature whose data clears the kill threshold gets deprecated, with the PM who launched it as the executor. The decision is not a debate. The debate happened when the kill condition was written into the launch contract. Deprecation is the execution of a decision already made.
What is broken today is that the default is "let it linger." Nobody actively chooses to keep a dead feature and nobody chooses to kill it, so it stays. Killing is socially expensive because the PM who launched it is still in the role. And there are no triggers, so the conversation never happens. Inertia wins.
The kill condition, set at launch
Every feature ships with an explicit kill condition, stated as: if metric X stays below threshold Y for duration Z, the feature is reviewed for deprecation. For example, if weekly active usage stays below 2% of MAU for 8 weeks, if cost per successful action stays above $0.50 for 4 weeks without a viable optimization path, or if the eval score regresses below 0.7 and cannot be recovered in 2 weeks. "Reviewed for deprecation" is not "automatically killed." It is a forced conversation at a specific moment with the data already on the table. The decision can still be invest more, reposition, limit, or kill. The point is that the decision happens instead of being avoided.
The three tiers
Not every kill is equal. Tier 1, soft sunset: the feature stays accessible to existing users but is removed from default UI, docs, and onboarding. New users do not discover it, engineering stops investing. Often right for a small but loyal base. Tier 2, hard sunset with migration: the feature is removed by a date, active users get notice, a migration path, and proactive support. Used when the feature is incompatible with where the product is going. Tier 3, immediate kill: only when the feature is broken, dangerous, or unprofitable enough that further runtime is irresponsible. Comms is short and direct. Tier 1 is default, Tier 3 is rare, and Tier 2 is the one most teams under-use because it takes real comms work.
Comms and culture
The killer move on customer comms is individual notice, not a generic blast. Pull the list of users who used the feature in the last 90 days and send each a personal-feeling note: we are sunsetting this on that date, we saw you used it N times, here is what we recommend. It costs 30 minutes of agent setup and forces you to confront the actual scale of use. Sometimes the "tiny" feature has 200 paying customers, which changes the decision. Better to find out before the announcement than after.
The cultural move is to publicly track what gets killed. A page listing features killed in the last 12 months, what the data showed, and what you learned, framed as evidence of discipline rather than failure. Then the next conversation is not "do we kill this," it is "how do we add this to the killed-features page."
This week, pick the feature you have been quietly hoping would die. Write its kill condition now, pull the last 90 days of data, and see whether it already meets the bar. If yes, schedule the conversation.