Deprecating a Feature
Removing something is a feature with its own users, launch and success measure: announce it, measure who still depends on it, remove it, and say what you learned about why it did not work.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
How do you remove a feature that a few people still use without breaking their trust — or never getting round to it?
The tech lead, looking at the checkout code: "Saved carts touches every change we make to the cart, and I think about four people use it. Can we just delete it?"
Check the usage numbers, confirm they are low, delete the code in a cleanup PR. If anyone complains, point them to the wishlist, which does roughly the same thing.
The "four people" turn out to be forty, and several are the shop's biggest repeat customers — a café that reorders the same supplies weekly from a saved cart. They find out when the button disappears on a Tuesday.
- The "four people" turn out to be forty, and several are the shop's biggest repeat customers — a café that reorders the same supplies weekly from a saved cart. They find out when the button disappears on a Tuesday.
- Support has no warning and no answer. The café's owner reaches the account manager, who escalates, and the feature is restored under pressure — now with less trust and still with its maintenance cost.
- Or the opposite: the team decides to deprecate it "properly", nobody owns the steps, and eighteen months later the feature is still there with a "deprecated" comment in the code and every cart change still pays for it.
- Nobody writes down why saved carts did not take off, so the next team proposes "reorder from a previous order" without knowing it is the same job and what was learned the first time.
What is really going on
- Every feature has a maintenance cost after launch — it shapes every change near it, it appears in tests, it has edge cases support has to know. Deprecation is how that cost is stopped, and it is usually the cheapest way to speed up the area (The Cost of a Feature).
- Low usage is not the same as low value. A feature used by few people can be critical to those few, and they are often your most engaged customers. The usage number tells you how many to talk to, not whether to talk to them.
- Deprecation has its own users: the people who depend on the thing. They need what any launch gives its users — notice, a reason, an alternative, and a date — or it is not a deprecation, it is an outage you planned.
- The phases are announce, measure, remove, learn. Announcing changes behaviour, so usage after the announcement tells you who really depends on it. Removing is a deploy. Learning is the part that pays back: why did the feature not find its users?
- A deprecation without an owner and a date does not happen. It is the least exciting work on any roadmap, and it will lose every priority contest unless it is scheduled like a launch (Sequencing Work So Value Lands Early).
Deprecation is a feature with its own users
Saved carts has forty-one users in the last ninety days. They are not a rounding error; they are the users of the deprecation. Like any launch, the deprecation needs to know who they are, what job they were doing with the feature, what they will do instead, and when the change happens.
Framed that way, the work is familiar: a small launch with a clear audience. Framed as "cleanup", it is either done carelessly or never done.
Who, not how many
The dashboard says 0.2% of carts are saved carts. That number is how many people to talk to, not whether to proceed. Pull the list: which accounts, how often, what they buy. In this case, the café that reorders weekly accounts for a noticeable share of repeat revenue on its own.
Then talk to the heaviest two or three. The café owner does not care about saved carts; she cares about reordering the same twelve things every Monday in under a minute. Reorder-from-previous-order does that. What she needs is her current list exported and a heads-up, not the feature (Users and the Jobs They Hire Features For).
You are calling the café owner, who uses saved carts every week, before the announcement goes out.
"Hi, we are deprecating saved carts because usage is low. You can use the wishlist instead."
"You use saved carts every Monday to reorder supplies — we are planning to retire it at the end of next month. Can I show you reorder-from-previous-order? It puts last week's items in your cart in one click. If there is anything saved carts does for you that this does not, I want to hear it before we decide. We can also send you your saved list as a file."
Announce, remove, and hold the date
The announcement is short and specific: what is going, when, why in one sentence, and what to use instead. It goes in the product next to the feature, by email to recent users, and to support and account managers first so they are not surprised by the first reply.
After the date is announced, pressure will arrive to move it. Move it only for a reason that changes the decision — a use case the alternative really does not cover — and never for "someone complained". A date that moves on complaint teaches everyone that deprecation dates are suggestions.
1saved_carts:2 owner: checkout-team3 state: deprecated # live -> deprecated -> removed4 announce_date: 2026-10-015 remove_date: 2026-10-316 banner: "Saved carts retire on 31 Oct. Use Reorder on any past order."7 enabled_for: all # switch to [] on remove_date, delete flag a week later8 on_remove:9 export_saved_lists: true # email each user their list as CSV10 ticket: PE-1182 # the code and table removalThe remove date and the ticket for the code removal live next to the switch. A flag without them becomes a permanent "deprecated" feature.
Say what you learned
The last phase is a short note: what the feature was for, who used it, why it did not find more users, what replaced it, and what the team would do differently. Saved carts was built for "save for later"; the people who used it used it to reorder. The job was right, the shape was wrong, and reorder found the shape.
That note is what stops the next team building saved carts again under a new name. It is also the most honest measure of the product engineer's ownership — saying, in writing, what did not work and why (Outcome vs Output).
Remove saved carts (deprecated). -1,840 lines.
Saved carts removed 31 Oct. 41 users; 36 moved to reorder, 4 lists exported, 1 account churned (had not ordered since July). Built for "save for later" in 2024; used for weekly reorders instead, which reorder-from-order does better. Next cart change is ~2 days simpler. If someone proposes save-for-later again, start from the reorder data.
The PR tells engineers the code is gone. The note tells the next person what the users were really doing and what it cost to find out — which is the only reason the feature existed at all.
How to do it
Most important first.
- Find out who uses it, not how many: list the accounts, their order frequency and value, and read their last few sessions. Talk to two or three of the heaviest users before deciding anything.
- Decide the alternative for each group — the wishlist, "reorder from a previous order", nothing — and be honest where there is none. "We are removing this and there is no replacement" is sometimes the right answer; say it plainly.
- Announce with a date, in the product and by email to the people who used it recently. Tell support and account managers first, with the list and the answer.
- Put the feature behind a flag, watch usage after the announcement, and follow up with anyone still using it the week before removal (Feature Flags as Product Tools).
- Remove it on the date: the flag, the code, the tests, the data (after an export if the users need one). Then write a short note on why it did not work and what the team would do differently.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with who it affects and what they will do instead: "Saved carts is used by 41 customers in the last 90 days. 30 of them also use reorder-from-order, which does the same job."
- Then the cost of keeping it: "Every cart change has to account for saved carts. It added about two days to each of the last three cart changes and was in the March promo incident."
- Then the plan and the dates: "We announce on the 1st, remove on the 31st. We have spoken to the three heaviest users; two are fine with reorder, and the café wants its list exported, which we will do."
- And what we learned: "People wanted to reorder the same things, not save a cart for later. Reorder does that better. The next idea in this space should start there."
- "What if the customers who use it are important?" Then we talk to them first and make sure they have a way to do what they need. If there is no way, that is a reason to keep it — decided with them, not assumed.
- "It is not hurting anyone, just leave it." It is hurting every cart change. Here are the last three and what saved carts added to each. If that cost is acceptable, we keep it and stop complaining about it — deliberately.
What can go wrong
- Announcing without a date, so nobody changes behaviour and the announcement is ignored.
- Moving the date every time someone complains, until the deprecation is permanent and the feature is both unmaintained and still there.
- Deleting user data along with the feature without offering an export — the café loses the list it built over two years.
- Removing the UI but leaving the code "in case", so the maintenance cost stays and the only thing gone is the value.
- Treating the learning note as optional. It is the only part that helps the next feature succeed.
- "Nobody uses it" from a dashboard. Check who, not how many, and check the right event — the café loads the saved cart via a bookmarked URL that the tracking never recorded.
- "Deprecating is admitting failure." It is the last phase of a feature's life, not a verdict. The failure is keeping something that costs more than it gives because removing it feels like a confession.
- "We can deprecate it later when things are quieter." Things are never quieter; every month it stays, the next change pays for it again.
Knowing whether it worked
- Usage drops after the announcement and the remaining users are ones you have talked to by name.
- No escalation arrives on removal day — support has the answer and has used it.
- The next change to the cart is measurably simpler: fewer tests touched, no saved-cart branch in review.
- The learning note is referenced when someone next proposes a feature in the same area.
- On a small product, deprecation is a conversation with a handful of customers and a PR. The phases still hold; each one takes a day.
- At 10x customers, even a small percentage is hundreds of people and some are important accounts. The announcement needs to reach them through the channels they read, and the date needs to survive pressure from the account side.
- For APIs and platforms, other people's code depends on the feature. Deprecation windows become contractual, usage is measured per client, and removal is the end of a months-long migration.
- It costs attention. A well-run deprecation is weeks of calendar time and several conversations for a feature nobody is excited about.
- Some users will be unhappy even with notice and an alternative, and a few may leave. That is a real cost, and it has to be weighed against the maintenance cost honestly, not assumed away.
- Announcing a removal publicly makes it harder to reverse quietly. If you are not sure, measure first and announce later.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALAnnounce, measure, remove and learn applies to any feature with users. The length of each phase is what varies — days for a consumer toggle, months for an API.
- PRODUCT-SPECIFICConsumer features can be removed with a month of in-product notice. B2B features may be named in contracts and need the account team and sometimes legal; platform and API features need per-client migration and a published sunset date.
- STAGE-SPECIFICEarly on, features are removed often and quietly because the user base is small and expects change. In a mature product with habitual users, the same quiet removal is a trust incident.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.