Feature Deprecation
Everyone agrees that sunsetting old features is essential product hygiene. Almost nobody can actually do it without triggering a political crisis.
There’s a feature in a product I use that was deprecated in 2019. The sunset notice is still there. The feature still works. It’s been five years.
I asked someone on that team what happened. They laughed in a way that suggested I’d touched something painful.
“Three enterprise customers threatened to leave,” they said. “One of them knew our CEO personally.”
And that was that. The deprecation notice became a permanent fixture, a small monument to the gap between product strategy and organisational reality.
The Seductive Logic of Sunsetting
The case for aggressive deprecation is compelling on paper. Every feature you maintain is a tax on everything else. Bug fixes. Security patches. Documentation. Support tickets. Cognitive load for new users trying to understand why there are three ways to do the same thing.
Marie Kondo for product management: if it doesn’t spark value, thank it for its service and let it go.
I’ve sat through portfolio reviews where we identified features used by less than 2% of the user base consuming 15% of engineering maintenance time. The maths is obvious. The strategic recommendation writes itself.
“We should sunset this” is one of the easiest sentences to say in product management. Actually doing it is something else entirely.
The product management literature loves this topic. Ruthless prioritisation. Simplification as strategy. The discipline to say no, or in this case, to say “not anymore.” It sounds so clean.
What Happens When You Try
Here’s what the literature doesn’t adequately cover: the phone call.
You know the one. Three days after you announce the deprecation timeline, someone from the customer success team messages you. “Can we chat?” And you know before you even join the call that your carefully reasoned sunset plan is about to collide with commercial reality.
“So, Acme Corp uses this feature as the core of their workflow. They’ve built their entire process around it. And they’re up for renewal in two months.”
I’ve had this exact conversation maybe a dozen times across different companies. The details change. The dynamic doesn’t.
The strategy said: reduce maintenance burden, simplify the product.
The execution reality says: this feature is load-bearing for a customer paying us £400,000 annually.
The Translation Layer Failure
This is a classic strategy-execution gap, but not the kind people usually talk about. The strategy isn’t wrong. The execution team isn’t incompetent. The failure is in the translation layer, the space where high-level product direction meets commercial relationships, political dynamics, and the specific humans whose jobs depend on things staying exactly as they are.
Nobody in the strategy conversation modelled for the sales director who sold the feature as a differentiator. Nobody accounted for the VP of Customer Success whose bonus is tied to retention. Nobody mapped the three product managers before you who each tried to deprecate this same feature and quietly gave up.
The feature persists not because anyone thinks it’s valuable, but because the cost of removing it is distributed across too many stakeholders, each of whom can independently veto the decision.
Legacy features often survive not because they’re loved, but because killing them requires more political capital than anyone is willing to spend.
The Vocal Minority Problem
And then there are the users themselves.
Product managers learn quickly that usage data and user sentiment are different things. A feature used by 2% of your base might be used by the most vocal, most engaged, most likely-to-write-an-angry-tweet segment of that base.
Slack learned this when they tried to deprecate IRC and XMPP gateways. The actual usage numbers were tiny. The response from technical users was volcanic. They reversed course, then eventually did deprecate it, but the process took years longer than the usage data suggested it should.
The uncomfortable pattern: the users most dependent on legacy features are often your earliest adopters, your most technically sophisticated customers, the people who built workflows around your product before you’d figured out what it was supposed to be.
They’re also frequently the people who talk to other potential customers. Who write the blog posts. Who speak at conferences.
Sunsetting a feature they depend on isn’t just removing functionality. It’s signalling that their loyalty and investment in your product doesn’t protect them from your changing priorities.
The Honest Calculation
Here’s what I’ve learned, somewhat painfully: deprecation decisions are almost never actually about maintenance costs.
Or rather, maintenance costs are the stated justification, but the real calculation is political. Can we absorb the backlash? Do we have executive air cover? Is the customer success team going to fight us? Will sales blame us when renewals get harder?
The teams that successfully sunset features aren’t necessarily the ones with the best data or the cleanest product strategy. They’re the ones where product leadership has accumulated enough trust and political capital to weather the inevitable resistance.
I watched a PM at a growth-stage startup try to deprecate a feature that was objectively causing problems. Support tickets. Performance issues. Constant edge-case bugs. Every metric said it should go.
She built the case. She socialised it. She got approval.
Then a board member mentioned in passing that their portfolio company used that feature. Deprecation cancelled. No discussion.
What Actually Works (Sometimes)
The few successful deprecations I’ve seen share some common patterns.
First, they’re positioned as migrations rather than removals. “We’re moving you to something better” lands differently than “we’re taking this away.” Intercom did this well when they consolidated their product lines. Not “we’re killing this” but “we’re bringing you into the unified platform with new capabilities.”
Second, they involve absurd amounts of hand-holding. Not email announcements. Actual phone calls. Migration support. Dedicated resources. The cost of doing deprecation well often approaches the cost of just maintaining the feature, at least in the short term.
Third, and this is the one nobody wants to hear, they require someone senior enough to absorb the political damage. Deprecation needs air cover. Without executive sponsorship that won’t evaporate at the first complaint, you’re just creating a backlog item that will sit there for five years with a sunset notice that everyone ignores.
The Tension That Remains
I don’t have a satisfying resolution here. The strategic case for aggressive sunsetting is real. The maintenance burden is real. The product complexity is real.
But so is the political economy of established features. So is the asymmetry between concentrated pain for the users who lose something and diffuse benefit for everyone else. So is the career risk for the PM who picks the wrong fight.
Maybe the honest framing isn’t “PMs must ruthlessly sunset features” but “PMs must build the organisational conditions that make sunsetting possible.” That’s slower. Less satisfying. Harder to put in a strategy deck.
But at least it acknowledges what’s actually happening.
That deprecated feature from 2019? Still there. Still working. The notice says it’ll be removed “in a future release.”
I’m starting to think that’s the most honest thing about it.