How do you decide when to kill a feature?
Model answer
Model answerFeatures rarely get killed because there's always someone who uses them. The right trigger isn't low usage — it's negative ROI when you account for maintenance cost, cognitive load on new users, and engineering complexity. I'd evaluate: usage rate, trend direction, cost to maintain, and whether the feature conflicts with the current product direction. Killing features is a sign of product maturity, not failure.
Framework · Feature Retirement
- UUsage reality check
Not just absolute usage — trend, and who is using it (your best users?) - CCost of keeping it
Maintenance, complexity tax, cognitive load for new users — these are real costs - AAlignment with direction
Does this feature conflict with where the product is going? - RRetirement with care
Give lead time, communicate clearly, migrate power users where possible
Related questions
- How would you prioritize building for power users vs. new users?
- A major competitor just launched a feature you were building. What do you do?
- How do you align stakeholders when they disagree on the roadmap?
- How would you evaluate the ROI of a product investment before building it?
- How would you evaluate a potential acquisition target from a product perspective?