Every product accumulates features that a few customers love, nobody new adopts, and the team quietly dreads maintaining. Killing one feels risky (someone will be angry); keeping it feels safe (nobody's angry today). That asymmetry is exactly why teams keep zombie features for years. Here's the worked decision brief — YourBrief's seven-section structure applied to a call most roadmaps avoid making.
The decision
Sunsetting is nearly irreversible in perception even when it's reversible in code: once you tell customers a feature is going away, un-deciding costs you credibility. So treat it as a one-way door on trust, a two-way door on code. That means the decision itself deserves rigor, but the execution can be staged (deprecate → hide → remove) to keep your options open. The real question isn't "does anyone use it" — someone always does — it's "does this feature earn the maintenance, support, and cognitive load it costs, versus what that capacity could do instead?"
Key questions to answer before deciding
- What does it actually cost to keep — not just eng maintenance, but support tickets, onboarding confusion, security surface, and the roadmap attention it steals? Zombie features tax every future decision, not just the sprint.
- Who uses it, and are they the customers you want more of? A feature used by 3% of accounts that happen to be your best, stickiest, highest-paying customers is a different decision than one used by 3% who churn anyway.
- Is usage declining, flat, or seasonal? A feature in structural decline is a different call than one with a small but loyal, stable base.
- Would removing it break a workflow the customer can't easily replace? "Rarely used" and "load-bearing when used" can be the same feature — check before you swing.
Recommended frameworks
Cost-to-serve vs value-captured. Put a real number on annual cost to keep (eng + support + security + opportunity cost) against the revenue genuinely attributable to the feature — not "accounts that touch it," but accounts that would leave without it. Most zombie features lose this comparison badly once opportunity cost is honest.
Quitting as a skill (Annie Duke). Duke's argument: we treat quitting as failure and so hold losing positions too long. A feature you'd never build today, knowing what you now know, is a position to close — the sunk cost of having built it is not a reason to keep paying rent on it.
Staged deprecation (preserve optionality). You rarely have to choose "keep forever" vs "delete now." Deprecate (stop investing), then hide from new users, then sunset for existing — measuring the scream at each stage. This converts a scary one-way decision into a reversible sequence.
Decision criteria
Sunset if: the fully-loaded cost to keep clearly exceeds the revenue that would actually leave without it; usage is flat-or-declining among non-strategic accounts; and no load-bearing workflow depends on it. Keep (and possibly invest) if a small user base is strategic (your best customers) and the feature is genuinely load-bearing for them. When it's cost-heavy but a few key accounts depend on it, the answer is usually neither kill nor invest — it's stabilize and stop developing: keep the lights on, add nothing.
Sources to consult
Pull the real usage cohort (who, how often, how strategic) and the real cost (eng time logged + support tickets tagged to it) — this decision is almost entirely an internal-data question. Then read Annie Duke's Quit on sunk cost, and ask the two engineers who maintain it what it actually costs them in a quarter — they know the number product often doesn't.
Next steps
This week: (1) build the cost-to-serve vs revenue-attributable table; (2) segment users by how strategic they are; (3) if you're sunsetting, announce a deprecation (not a deletion) with a long runway and a migration path, and measure the reaction before removing anything. Stage it so the irreversible part comes last.
When to escalate
Escalate to leadership if the feature touches a marquee customer's contract or a workflow tied to renewal, or if sunsetting has compliance/data-retention implications. And if the team has debated this feature for more than two quarters without deciding, that indecision is the escalation trigger — the cost of not deciding has quietly exceeded the cost of either answer.
The trap is treating "keep" as the safe default because nobody complains today — while the maintenance, support, and attention cost compounds invisibly. Run the real cost-vs-value numbers and the call usually clarifies fast. Generate this brief for your specific feature — $1 to start.
Related worked briefs: Layoffs or cut spending · Usage-based pricing · The decision brief template