How to sunset a feature: The approach I’d take
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
Sunsetting a feature feels political because it is. Low usage isn't always "delete it." High-paying customers on a dusty workflow aren't always a veto forever either.
Here's the approach I'd take—shaped by conversations I've seen in PM communities when someone asks: what's the usage threshold, and what if VIPs still rely on it?
Don't use a single metric
I'd look at a set:
- Adoption / active usage (absolute and trend)
- Depth of use (critical path vs occasional)
- Segment mix (SMBs vs enterprise; which personas)
- Support / incident cost
- Strategic fit (does it block a platform bet?)
- Opportunity cost (what we aren't building)
A feature at 2% usage that unlocks enterprise security reviews is not the same as 2% usage on a legacy export nobody remembers approving.
Talk to the people still using it
Before the kill decision:
- Why do they use it?
- What job does it do?
- What's the workaround if it goes away?
- Is the pain migration—or true unique value?
Chris-style horror stories are real: silent removals that break a customer's whole flow. Empathy and communication aren't optional.
When high-paying clients are the holdouts
Options I'd consider:
- Migrate them with white-glove help to the replacement workflow
- Time-box the old path with a clear end date and incentives
- Price the legacy honestly (support tax) if you must keep it temporarily
- Grandfather narrowly while blocking new adoption
- Rarely: keep it if the strategic cost of removal exceeds the tax—document why
What I wouldn't do: pretend the feature is fine because three logos scream.
A deprecation path that protects trust
- Decision memo (why now, what success looks like)
- Internal alignment (sales, CS, support, eng)
- Customer communication early—with migration steps
- In-product warnings and docs
- Parallel run / export tools when needed
- Remove from new signups first when possible
- Final removal + monitor support spikes
- Postmortem: did we learn about discovery gaps?
Thresholds are context
There isn't a universal "% usage = delete." Set thresholds per product tied to cost and strategy—and revisit them when the architecture changes.
My take
Sunsetting is product strategy with manners. Measure broadly, listen to holdouts, migrate with respect, and don't let zombie features tax the roadmap forever.
Build sharper prioritization judgment with the Product Manager Certification. More operator notes in the newsletter.
