The Deprecation Playbook

The topic every PM book skipped

Every PM book in the 2010s spent 200 pages on how to launch and 0 pages on how to retire. Result: a generation of products bloated with features that never worked, never reached scale, and never got removed because removal required someone to admit the launch failed.

I've lived inside these products. At Adobe, at Salesforce, at three startups. Everyone on the team knew which features were dead. Nobody would say it. So the bloat compounded.

In 2026 the cost of carrying a dead feature has gone up. Each surface has its own model costs, its own eval maintenance, its own support burden, its own attack surface, its own cognitive load on every customer who sees a menu item that doesn't work the way they hoped. Carrying ten dead features in an AI product is materially expensive in a way that carrying ten dead features in a CRUD app was not.

So the playbook for killing features has to get better. This is it.

The thesis

Deprecate on signal, not politics. 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 that was already made.

What's broken about how features die today

Default is "let it linger." Nobody actively chooses to keep a dead feature. Nobody actively chooses to kill it. It stays. Engineering complains occasionally that they have to maintain it. Customers complain occasionally that it doesn't work right. The PM nods and moves on. After a year, it's part of the furniture.

Killing is socially expensive. The PM who launched it is still in the role, often with a promotion built on the launch. Killing the feature feels like criticizing them. So the conversation gets avoided. The longer it gets avoided, the more entrenched the feature becomes.

There are no triggers. No specific metric, no specific timeframe, no specific decision date forces the conversation. So the conversation never happens. Inertia wins.

Customer comms feel scary. Some unknown number of customers might use it. Killing might create a churn event. Conservative move: do nothing. But nothing has its own cost, invisible until it's huge.

The kill condition, set at launch

Every feature ships with an explicit kill condition. Written in the instrumentation contract (see Ship With Observability). Stated as: if metric X stays below threshold Y for duration Z, the feature is reviewed for deprecation.

Examples:

• "If weekly active usage stays below 2 percent of MAU for 8 weeks, the feature is reviewed for deprecation."
• "If cost per successful action stays above $0.50 for 4 weeks without a viable optimization path, the feature is reviewed for deprecation."
• "If the eval score regresses below 0.7 and can't be recovered in 2 weeks, the feature is reviewed for deprecation."

"Reviewed for deprecation" is not "automatically killed." It's 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.

Without a written kill condition, no feature crosses an objective threshold for the deprecation conversation. With one, every feature has its own clock.

The three deprecation tiers

Not every kill is equal.

Tier 1: Soft sunset. Feature stays accessible to existing users but is removed from default UI, docs, and onboarding. New users don't discover it. Existing users keep using it. No customer harm. Often right for features with a small but loyal user base. Engineering maintains it but stops investing.

Tier 2: Hard sunset with migration. Feature is being removed by date X. Active users get N weeks of notice, a migration path, and proactive support. Used when the feature is incompatible with where the product is going. High-touch comms. Rare but sometimes correct.

Tier 3: Immediate kill. Used only when the feature is broken, dangerous, or unprofitable to a degree that makes further runtime irresponsible. Comms is short and direct: "This feature is being removed because [specific reason]. Here's what to use instead." Burn the bandage in one move. Painful for two days. Better than three months of slow death.

The PM picks the tier based on usage, customer impact, and strategic reason. Tier 1 is default. Tier 3 is rare. Tier 2 is the one most teams under-use because it requires real comms work, but it's often right for retiring meaningful surfaces gracefully.

Customer comms that actually work

The killer move: individual notice to active users, not a generic email blast.

Pull the list of users who used the feature in the last 90 days. For each, send a personal-feeling note (templated but customized): "We're sunsetting [feature] on [date]. We saw you used it [N] times in the last quarter. Here's what we recommend instead, and here's how to get help if you need it."

This costs 30 minutes of agent setup and converts more goodwill than the launch announcement did. It also forces you to confront the actual scale of use. Sometimes you'll find the "tiny" feature has 200 paying customers, which changes the kill decision. Better to find out before the announcement than after.

Internal comms that make the culture easier

The single move that makes deprecation culturally easier: publicly tracking what gets killed.

A page in your team space, updated continuously: "Features killed in the last 12 months." For each: what it was, why, what the data showed, what we learned. Make it celebratory rather than apologetic. Reframe deprecation as evidence the team is operating with discipline, not failure.

When the next feature crosses its kill threshold, the conversation isn't "do we kill this?" It's "how do we add this to the killed-features page?" Frame change does most of the work.

The mortality dashboard (the spicier version)

For the truly committed: a public-internally page where every feature has a mortality risk score visible to the whole company.

The score is a function of: weeks since kill condition was last evaluated, distance from threshold, recent trend, cost per action, support ticket volume. Updated daily. Visible to engineering, support, sales, and the C-suite.

This will be deeply uncomfortable for people who launched the high-mortality features. That's the point. Discomfort is the friction that makes deprecation inevitable. Without it, hope masquerades as strategy and dead features stay in the product forever.

A more diplomatic version: keep the dashboard internal to product. A more cowardly version: private to the PM. Pick the level your culture can handle, but don't skip it entirely.

Pick one thing this week

Pick the feature you've been quietly hoping would die. Write its kill condition now, in retrospect, and see where it lands.

1. Open the feature's page.
2. Write: "If weekly active usage stays below X for Y weeks, this feature will be reviewed for deprecation." Pick numbers you can defend.
3. Pull the actual data for the last 90 days. Does the feature already meet the kill condition?
4. If yes, schedule the deprecation conversation. If no, commit to the kill condition going forward and put a reminder on your calendar for the review date.
5. Tell your manager you did this.

Do it for three features this quarter. By the end of the year, your team has killed more dead code than it shipped in the prior year, and your product is meaningfully less bloated.

Kill the feature on signal. The team that kills bravely outships the team that hopes politely, every time.