Software products accumulate. Features get added, a few users adopt each one, and nothing is ever removed because removing things upsets people. The result is a product that is harder to learn, harder to test, harder to change, and slower to develop in - where every new idea must be reconciled with eleven old ones. Deliberate removal is ordinary maintenance, and treating it as an admission of failure is why most products never do it.
Decide with evidence rather than impression. How many accounts used this feature in the last ninety days, not ever. How many of those are on meaningful contracts. What does it cost to keep - support volume, test surface, the constraints it imposes on adjacent work. A feature used by four per cent of accounts sounds significant until you find those accounts are all trials, and sounds trivial until you find one is your largest customer.
Which is the trap worth naming: usage counts hide concentration. Before announcing anything, list the actual accounts still using it and look at them. A feature with two remaining users can be more expensive to remove than one with two hundred, if those two are strategically important, and the right answer there might be a direct conversation and a migration rather than a broadcast.
Announce with a real timeline and a documented alternative. Ninety days is a reasonable minimum for anything customers have built process around, longer if they have built integrations. Say what to use instead, and if the answer is nothing, say that plainly rather than gesturing at a partial substitute - customers deal with honesty considerably better than with a replacement that does not replace.
Then remove in stages rather than at once. Hide it from new accounts first so the population stops growing. Show an in-product notice to those still using it, which reaches people email does not. Make it opt-in to continue. Then a brownout - disabled for a day, announced - so anyone who missed every notice discovers it at a moment you control and can reverse. Then remove.
Finish the job in the codebase. Removal that stops at hiding the interface leaves the code, the tables, the background jobs and the tests in place, so you carry the entire maintenance cost while getting none of the simplification. Delete the code, drop the data after the retention period, remove the tests and the documentation. If that turns out to be difficult because everything else depends on it, that is the most useful thing the exercise has told you about your architecture.
