How do you sunset a feature nobody uses?

Sunsetting a feature is a product decision, an engineering task, and a communication challenge all at once. Done right, it tightens your product, reduces maintenance burden, and sharpens user focus. Done carelessly, it erodes trust and occasionally breaks something critical that your metrics said was idle.

First: Confirm it's actually dead

Usage metrics lie in two predictable ways. They undercount silent power users—people who rely on a feature infrequently but would scream if it disappeared—and they miss indirect dependencies, where Feature A appears unused but is a prerequisite for Feature B that everyone loves. Before you write a single deprecation notice, audit the feature at three levels: raw event data (who triggered it and when), downstream dependencies (does anything else call or depend on it?), and qualitative signal (have any users mentioned it in support tickets, reviews, or interviews, even once?).

Pay special attention to enterprise or high-value customers. A feature used by one customer who represents 30% of revenue is not a dead feature—it's a contractual obligation masquerading as low adoption. Run a quick revenue-weighted usage analysis, not just a head-count one. If no segment of meaningful business value touches the feature, you have your answer. If even one does, you have a conversation to have before you have a deprecation to write.

A useful heuristic: if you can't articulate who specifically would miss this feature and why, you probably don't understand your users well enough to remove it safely yet. That's a signal to do one more round of customer discovery, not to delay indefinitely.

Design the sunset as a product decision, not a cleanup task

The framing you use internally shapes the quality of the work. When a feature sunset gets filed as a tech-debt ticket, it tends to produce a rushed removal with a terse changelog entry. When it's treated as a product decision—with a rationale, a replacement path if applicable, and explicit owner accountability—you get a cleaner outcome for users and the team.

Start by writing a one-paragraph internal brief: what the feature was supposed to do, why adoption was low (wrong users, poor discoverability, solved problem no longer exists, better alternative exists), and what users should do instead. This brief forces you to answer the hard question: is low usage a signal that this feature is useless, or that it was never properly surfaced? If it's the latter, the right call might be a relaunch, not a removal. Only proceed with the sunset once you're confident the feature failed on merit, not on distribution.

This document also becomes the foundation for your external communication. Users deserve a real explanation, not a vague 'we're streamlining the product' platitude. Specificity builds trust even in bad news.

Execute the removal in stages, not all at once

The safest removal sequence is: announce, gate, remove. Announce the sunset with a firm date—typically 30 to 90 days out depending on how embedded the feature is. Gate it by making it opt-out or visually flagged as deprecated so users who see it in their workflow are nudged toward the alternative. Then remove it cleanly once the date passes.

During the gating period, monitor closely. A feature you were certain was dead will occasionally reveal itself to have real users the moment you flag it for removal. That's useful information—treat it as a discovery event, not an embarrassment. Either those users confirm they can migrate to the alternative, or they surface a use case that changes your calculus. Either way, you're better informed than before.

On the engineering side, don't leave feature corpses in the code. Partial removals—where the UI is gone but the backend still runs—create hidden maintenance surface and security exposure. Commit to a complete removal: deprecate the API endpoints, clean the database columns on a migration schedule, and delete the dead code paths. Garry Tan's gbrain project offers a useful model here: the changelog documents a `stub_guard_24h` check with an explicit sunset criterion—when a guard fires fewer than 5 times per week for 3 consecutive weeks, it earns removal in the next version. That kind of evidence-based exit criterion is exactly the discipline to apply to feature sunsetting too.

Communicate to users like a founder, not a legal team

Most deprecation notices are written defensively—dense with caveats, light on empathy. The ones that preserve trust are written by someone who remembers that a real person built a workflow around this feature, and that removing it costs them something real even if it costs you nothing.

A good sunset communication does four things: explains the why honestly (not 'to improve the product experience' but 'this feature had very low adoption and maintaining it was pulling engineering time from X'), states the exact date clearly, offers a concrete migration path or alternative, and provides a direct channel for questions. Email is better than a changelog entry for anything that touches active users. For API deprecations, in-response headers that flag the deprecated endpoint on every call are more reliable than any announcement.

For B2B products, pick up the phone for your top 10 accounts before any public notice goes out. Finding out your 'unused' feature was load-bearing for an enterprise workflow from a support ticket is far worse than finding out in a proactive conversation where you can actually help.

Treat the sunset as a feedback loop, not a conclusion

After the feature is gone, do a short retrospective. Why did the feature fail to get adoption? Was it a discovery problem, a positioning problem, a timing problem, or did it simply solve the wrong problem? The answer changes what you build next. A feature that failed because it was buried in a settings menu teaches a different lesson than one that failed because users never had the problem you thought they had.

First-principles thinking—questioning why the original assumption existed in the first place—is more valuable here than post-mortem theater. The goal isn't to assign blame or to document what went wrong for its own sake. It's to update your model of what your users actually need so the next feature you build earns its place. A startup that learns faster from what it removes than from what it builds has a real competitive edge. Every sunset is a chance to sharpen your understanding of the core problem you exist to solve.

“The sunset criterion is wired in: when the 24h reads stay below 5/week for 3 consecutive weeks, the guard can be removed.”

— Garry Tan, source

The one thing to do

Announce the sunset with a firm date, gate the feature with visible deprecation warnings, monitor for surprise users during the window, then remove it completely—UI, API, and database—rather than leaving an unmaintained corpse in your codebase.

Frequently asked questions

How much notice should you give users before removing a feature?

30 days is a minimum for most consumer features; 60–90 days is appropriate for anything embedded in B2B workflows or accessible via API. The right number is however long it actually takes your users to migrate, not whatever is administratively convenient for you.

What if a low-usage feature turns out to have a vocal user during the deprecation window?

Treat it as a discovery event. Talk to that user, understand the use case, and make a deliberate decision: extend the timeline, build a migration path, or explain clearly why the sunset still makes sense. Never silently reverse course without communicating the change.

Should you keep the backend running after removing the UI?

No. Partial removals create hidden maintenance burden, undocumented API surface, and potential security exposure. Commit to a full removal—deprecate endpoints, run the database migration, and delete the dead code on a clear schedule.

How do you avoid accidentally sunsetting a feature that's critical but underreported?

Layer your analysis: combine raw event counts with revenue-weighted usage, downstream code dependency checks, and a direct question to your top customers before you commit to a timeline. Metrics alone are not sufficient.

Sources

More playbook answers · Growth Prophet home