Build the case to deprecate a legacy feature

WHAT THIS TESTS The interviewer wants a balance of analytical rigor and user empathy. A feature used by only 2 percent looks like an easy cut, but raw usage hides whether those users are your most valuable accounts. The skill is building a defensible case and executing the sunset without burning trust.

A GOOD ANSWER COVERS Analyze both sides. On cost: confirm the 15 percent capacity drain and document exactly how the feature blocks the architectural migration, since unblocking it may benefit all users. On value: segment the 2 percent. Are they low-value free users or a handful of enterprise accounts representing major revenue or strategic logos? Check whether an alternative workflow exists or could be built cheaply. The case rests on cost versus value, not usage alone. To manage the trade-off, run a phased deprecation: announce early with a clear timeline, provide a migration path or export, reach out personally to high-value affected users, and monitor churn signals as you wind down. Keep a reversible checkpoint in case the migration reveals the feature is load-bearing.

COMMON WRONG ANSWERS Cutting it immediately because only 2 percent use it. Ignoring who those users are and their revenue weight. No migration path, no advance warning, no support, treating a sunset as a delete.

LIKELY FOLLOW-UPS What if the 2 percent are your top revenue accounts? How long a deprecation window and why? How do you measure whether the sunset caused churn?

ONE CONCRETE EXAMPLE You find the feature is used by 2 percent of accounts but three of them are enterprise customers worth a fifth of revenue. Rather than kill it, you build a lightweight migration to a supported alternative, give a ninety-day notice, personally onboard those three accounts, then decommission, freeing the 15 percent capacity and unblocking the migration without losing the strategic accounts.