Amey-Thakur Feature sunsetting
Every feature costs maintenance, support, testing surface, and cognitive load forever; removal is a product skill equal to shipping. The craft is proving the cost-benefit honestly and moving the affected users, not just deleting their workflow.
Method
- Build the case on usage and cost. Instrument actual usage (users, frequency, segments: see product-metrics), count the carry cost (bugs, support tickets, test time, the features it blocks: see tech-debt-register), and check strategic fit. "Low usage" alone is not the case: who uses it matters more than how many: 2% usage that is your top revenue accounts is a different conversation.
- Segment the affected before deciding. Pull the actual list: which accounts, which plans, what they do with it, what they would do instead. Talk to the heaviest users (see customer-interviews): sometimes you find the workaround that makes removal safe; sometimes you find the use case that saves the feature (or becomes its replacement's spec).
- Provide the path before the deadline. A replacement flow, an export (their data leaves with them: see data-retention's erasure sibling), or a documented alternative: with migration tooling where the users are many (see api-deprecation for the API twin, including sunset headers and usage tracking). No path means you are not sunsetting, you are breaking.
- Stage the removal. Hide from new users (flag off for new signups: see feature-flags-hygiene), announce with dates to existing users (in-product where they use the feature, not just email), read-only period, then removal: with timelines proportional to workflow depth (a report format: weeks; an API or data format: quarters: see api-versioning's sunset program). Enterprise contracts may pin timelines: check before announcing (see Boundaries).
- Communicate the why, absorb the anger. State the reason plainly (focus, low usage, replaced by X), acknowledge the cost to affected users, and give the escalation path; a visible "what we removed and why" changelog keeps trust (see roadmap-communication's change-loudly rule). Expect the loudest feedback of the feature's life at removal: measured in support volume, budget for it (see product-launch's support staffing, inverted).
- Actually delete, then verify. Remove the code, the flags, the docs, the tests, the marketing pages (see dead-code-removal, docs-maintenance); watch the metrics and support themes through the removal window for the damage you missed; record the outcome against the case you made (see decision-journals): sunsets that were wrong teach your usage instrumentation something.
Boundaries
- Contractual and compliance obligations override product logic; legal review joins any sunset touching paid commitments, data retention, or regulated workflows.
- Deprecating-but-never-removing ("zombie mode") accrues the full carry cost plus broken trust when it finally dies; if you announce a sunset, finish it.
- Sunsetting a whole product (with revenue, migrations, and PR surface) is this method at 10x ceremony with executive ownership; do not run it from a feature-level playbook alone.