On March 13, 2013, Google announced it would retire Google Reader on July 1. The official post gave the reason in one sentence: “While the product has a loyal following, over the years usage has declined.” By the next day, a single change.org petition had passed 30,000 signatures. Within weeks, the most popular one had climbed past 127,000. Reader shut down on schedule anyway, and more than a decade later it still comes up whenever someone wants an example of Google abandoning its users.
The usage data was probably right. It just answered the wrong question. Declining usage tells you how many people will notice a removal. It says almost nothing about how they will react, who they will complain to, or how long they will remember it.
That gap is why feature deprecation belongs on the stakeholder side of a product manager’s job, not the engineering side. Deleting the code is usually the easy part.
Low usage tells you who will notice, not how loudly
Most products carry a lot of dead weight. Pendo’s 2019 Feature Adoption Report, built on usage data from 615 of its customers’ products, found that about 80% of features in the average product are rarely or never used. Pendo sells adoption analytics, so read the number with that in mind, but nobody who has worked on a mature product will find it surprising.
So the case for removal is often strong. Every unused feature still has to be tested, secured, documented and supported. The trap is assuming that because almost nobody uses something, almost nobody will care when it goes.
Two things break that assumption.
The first is loss aversion. Tversky and Kahneman’s 1991 paper on riskless choice built a model around a simple observation: losses and disadvantages weigh more heavily on preferences than equivalent gains. A user who opens a feature twice a year felt nothing when you shipped it. They will feel its removal, because now it is something they had and lost.
The second is concentration. The 3% of accounts still using an old export might include your largest customer, whose finance team runs a quarter-end process on it that nobody on your team has ever seen. Usage dashboards count clicks. They don’t weight them by contract value or by how painful the workaround is.
Four removals, four very different notice periods
The single biggest variable in how a sunset lands is how much runway you give people. Four well-documented cases show the range:
| Company | What was removed | Announced | Effective | Notice |
|---|---|---|---|---|
| Free API access | Feb 2, 2023 | Feb 9, 2023 (then delayed twice) | About one week | |
| Heroku | Free dynos and data plans | Aug 25, 2022 | Nov 28, 2022 | About three months |
| Reader | Mar 13, 2013 | Jul 1, 2013 | About three and a half months | |
| Atlassian | Server products | Oct 2020 | Feb 15, 2024 | More than three years |
Twitter’s case is the cautionary one. Its developer account announced that free API access would end on February 9, giving app makers a week to decide whether to pay for something with no published price. Then the date slipped to February 13 with a day’s warning, and then slipped again with no new date at all. A short deadline is bad. A short deadline that moves teaches every stakeholder that your dates are not real, which makes the next announcement harder to land.
Heroku gave three months and told developers why: fraud and abuse of the free plans. It also staged the change, deleting long-inactive accounts first on October 26 before the main cutoff, and it published a detailed FAQ on what would happen to existing apps and databases. Developers still complained, mostly about price, but the complaints were about the decision rather than the handling.
Atlassian went the other way. It told Server customers in October 2020 that support would end in February 2024, then stepped through intermediate milestones: no new Server licences from February 2021, no new Server app sales from February 2023, and a 100-day countdown in November 2023 with migration trials, webinars and dual licensing. Plenty of customers hated the decision. Very few could claim they were surprised by it.
The lesson isn’t that every removal needs three years. A minor setting in a self-serve app does not need a migration program. The lesson is that notice should scale with what the customer has built on top of the thing you are removing. An API that other businesses run on is not the same as a button in a settings menu.
The people who find out last work in your building
When a removal goes badly, the external reaction gets the headlines. The internal damage is quieter and lasts longer.
The usual failure looks like this: the product team announces the sunset in release notes, and the first time an account manager hears about it is when a customer forwards the notice with an annoyed question. Support learns about it from the ticket queue. Sales discovers mid-negotiation that a feature in their pitch deck has a shutdown date. Each of those people now has to defend a decision they had no part in, to a customer who assumes they knew.
That is how a reasonable product decision turns into an argument about whether product and sales are on the same side. And if the affected account is one of the large ones, the conversation can quickly become about who actually owns the roadmap.
The order matters. Internal stakeholders who face customers should hear first, with enough time to ask questions, see the list of affected accounts and plan their own conversations. Customers come second. Release notes come last, as the public record of something the people closest to customers already know about.
The sunset sequence I would run again
Years ago, while running IT operations at a large telecom, I owned the retirement of an internal reporting tool that had been replaced by a newer platform. The usage logs said a handful of people still opened it. The logs were accurate. What they didn’t show was that one of those people pulled a monthly extract from it that fed a regulatory filing.
We found that out because we asked before we announced, not after. That experience shaped the sequence I have used for every removal since, in operations work and in fractional COO engagements with product companies:
- Name the remaining users, not just the count. Pull the accounts and people still touching the feature in the last 90 days, and look for anything that runs on a schedule. Monthly and quarterly jobs hide in usage averages.
- Talk to the heaviest few directly. A short call tells you what the feature is really doing for them and what a replacement has to cover. Sometimes it reveals that the removal should wait.
- Brief the customer-facing teams before any customer hears. Give account managers and support the date, the reason, the affected account list and a plain answer to “what do they use instead?”
- Pick a date you will not move. If you are uncertain, choose a later date. Moving a date once costs you some trust; moving it twice, as Twitter did, tells everyone your dates are negotiable.
- Give the reason in one honest sentence. “Usage has declined and we are focusing on fewer things” is fine. Vague language about “improving the experience” reads as spin, and customers can tell.
- Provide an exit path for their data. Google got this part right with Takeout, and it was the reason Reader users could move to an alternative in an afternoon.
- Stage the shutdown. Hide the entry point first, then stop new usage, then remove it. Each step surfaces users the data missed while the change is still cheap to reverse.
Teams that already practise cleaning up feature flags will recognise steps six and seven. The engineering discipline is the same. The difference is that a stale flag has no constituency, and a feature someone relies on does.
Removal is a product decision, so own the conversation
There is a reason some companies avoid removal almost entirely. Stripe wrote in 2017 that it had kept every version of its API compatible since 2011, pinning each account to the version it started on so nobody receives a breaking change by accident. That is an expensive promise, and it is a deliberate strategic choice for a company whose customers build businesses on its interface.
Most products can’t afford that, and shouldn’t try. Removing what isn’t earning its place is one of the most useful things a product manager can do for a team’s focus, and it fits naturally alongside a written list of what you won’t build. But treat every sunset as a piece of bad news to be delivered well, because to somebody, it is.
Google Reader’s usage really had declined. Nobody remembers the usage numbers. People remember how the decision was handled.