The Hidden Liability on the Product Balance Sheet
A feature with users looks like an asset, and that is precisely the accounting error. The visible ledger shows engagement: someone opens the export dialog, someone toggles the legacy view. What the ledger omits is the carrying cost — every retained feature is a constraint on every subsequent decision. It widens the test matrix, occupies a slot in the navigation, constrains the data model, and claims a share of the limited attention any user can spend learning your product. The mechanism that makes sunsetting hard is that the benefit (usage) is measured and attributed to a name, while the cost (complexity) is diffuse, deferred, and paid by people who will never know which feature taxed them. A product that cannot retire anything compounds this liability until the cost of changing the system exceeds the value of any change worth making.
Usage Is Not the Question; Substitutability Is
The instinct to keep a feature because "it still has users" treats raw usage as the decision variable. It is the wrong one. The variable that governs a clean sunset is the cost a user bears when the feature disappears — and that cost is set by what they can do instead. A feature used by ten thousand people who each have a trivial workaround is cheaper to remove than one used by forty people for whom it is load-bearing and irreplaceable. Before deciding, separate the population:
- Casual users who touch the feature but could accomplish the underlying job another way — their usage is real but their switching cost is near zero.
- Dependent users who have built workflows, integrations, or institutions around it — for them removal is not a friction but a rupture.
- Phantom users whose "usage" is automated, accidental, or the residue of a default they never chose.
Aggregate metrics blur these three into a single number that justifies inaction. The discipline is to refuse the aggregate and ask, for the dependent minority specifically, whether the job they are doing still deserves first-class support inside this product or belongs somewhere else entirely.
The Two Failure Modes Are Symmetric
There are two ways to get this wrong, and naming both prevents over-correcting from one into the other. The first is hoarding: every feature survives because someone, somewhere, would complain, so the product accretes into an unnavigable museum where the cost of the next decision keeps rising. The second, the over-reaction to the first, is amputation: a team newly converted to simplicity cuts a load-bearing feature, discovers it was holding up the workflows of its most committed users, and converts loyalty into a migration to a competitor. The asymmetry that matters is that hoarding fails slowly and quietly while amputation fails fast and loudly — which is exactly why disciplined teams drift toward hoarding. The remedy is not courage; it is a sunset that is engineered rather than announced.
Sunsetting Is a Migration, Not an Event
The decision implication is that a sunset's quality is determined almost entirely by what you build for the people you are removing it from. A defensible sunset names the destination before it names the deadline: the replacement path, the export, the equivalent job done elsewhere. It deprecates in stages — first to new users, then by removing discoverability, then by removing the feature — so that the dependent minority has both warning and a road out. It treats the loudest objection as data about a real job to be re-homed, not as a veto. The product organization that can do this acquires a capability most never develop: the ability to spend down its own complexity deliberately, which is the only thing that keeps the cost of future decisions from rising without bound. A team that can only add is not actually deciding what the product is; it is merely recording every request it ever received. The mandate of the Product Lens is to keep the surface small enough that the next decision is still cheap to make — and that mandate is unenforceable without the will to remove what people are still using.