Pick a product you know well. Which feature would you remove, and how would you know it was safe to remove?

Low usage is not the argument

The answer most candidates give is that a feature has few users, so it should go. That reasoning is weak on its own, because a feature with few users and no maintenance cost is nearly free, and plenty of important things are used rarely — export, account deletion, the annual compliance report. Usage tells you how much you would lose. It says nothing about what you would gain, and removal only makes sense when the gain is real.

So make the case from cost, and be specific about who pays it. A feature charges rent in four separate currencies. It occupies interface space, which pushes everything else further away. It adds a decision to a flow every user walks through, including the ones who will never want it. It constrains the data model and the code, so unrelated changes get slower and riskier. And it consumes support, documentation and QA attention permanently. The third and fourth are invisible in any dashboard, which is exactly why an interviewer wants to hear you name them unprompted.

A worked case

Take a team expense tool with a receipt-scanning flow that offers three capture modes: photograph, email forwarding, and a desktop uploader that requires an installed helper application. Assume 40,000 monthly submitters. Suppose the split of submissions is 82 per cent photograph, 16 per cent email forwarding, and 2 per cent desktop uploader — 800 submissions a month across, say, 300 people.

Now price the uploader. Assume it accounts for a quarter of the support tickets on receipt capture because it breaks on operating-system updates, and that receipt capture generates 400 tickets a month, so 100 tickets a month from 300 users. That is a ticket per user per quarter, against roughly one per user per eleven years for the photograph path if the remaining 300 tickets are spread across 39,700 people. Assume also that every release of the mobile capture flow needs a compatibility pass on the helper, costing a day of engineering plus a day of QA per release, at two releases a month.

Those numbers are illustrative and derived from the assumptions stated, not measured facts. The point is the shape they produce: a path carrying two per cent of submissions is generating a quarter of the support load and four engineer-days a month of tax on a flow used by everyone. That is an argument. "Only 2 per cent use it", on its own, is not.

Who are the 300, and where does their need go

Before proposing removal, characterise the dependants along dimensions that change the decision. Are they concentrated in a few accounts, or scattered? Are they your highest-value accounts? Do they use the uploader because they prefer it, or because something else blocks them — a locked-down laptop with no camera access, a finance team processing a hundred paper receipts in one sitting, an accessibility need the photograph flow does not meet? Concentration and blocking are the two findings that would stop me. A feature used by scattered people out of habit can be removed. A feature that is the only route for a segment is not a feature you are removing, it is a segment you are dropping, and that is a different decision needing a different sponsor.

The strong answer always ends with the need's destination. Bulk paper receipts might route to email forwarding with a multi-attachment path; a camera-blocked laptop might route to a browser file picker with no helper installed. If a dependant's need has nowhere to go, either you build the somewhere first or you do not remove the feature yet.

Staging so you can still change your mind

Removal is usually treated as a switch and should be treated as a sequence, because the cheapest place to discover you were wrong is before the code is deleted. Stop new adoption first by removing the entry point for users who have never used it, which costs nothing and immediately caps the exposed population. Then contact the identified dependants directly with the alternative, rather than relying on an in-product banner they will not read. Then dark-launch the removal to a slice of them and watch for submissions that simply stop rather than move — a user who abandons is invisible in the migration numbers and will show up later as churn. Only when the volume has moved rather than vanished do you delete anything.

Stage	What you learn	Cost of reversing
Hide from new users	Whether new users miss it at all	None
Notify dependants	Who objects and why	None
Dark-launch removal to a cohort	Whether volume migrates or disappears	Low, feature flag
Delete code and data path	Nothing further	High

The distinction that separates a strong answer

Weak answers optimise the removal; strong answers optimise the learning during it. The metric you watch afterwards is not "did the feature stop being used", which is guaranteed once you remove it, but whether the job still gets done at the same rate. In this case that means total receipt submissions per active submitter, and it should stay flat. If submissions per submitter fall while the migration numbers look healthy, you have not simplified the product, you have quietly stopped some people from completing a task and they have not told you.

Expect one metric to get worse regardless: support contacts spike for a few weeks after any removal, including successful ones. Say that in advance, because a team that has not predicted it will read the spike as proof the decision was wrong and roll back a good change.

Removal is justified by the tax the feature levies on everyone who never uses it, and it is safe only when you can say where the displaced need goes and would notice if it went nowhere.