Improvement is not always the responsible choice

When a feature underperforms, the default response is often to add more: more settings, another onboarding tooltip, a redesign, or a new campaign to explain it better.

Sometimes that is right. Often it is a way to avoid a harder question: does this feature solve a problem important enough to deserve more of the team\u2019s time?

Removing a feature can be a product improvement. It lowers cognitive load, reduces maintenance, and makes the core workflow easier to explain. The goal is not to delete anything that has low usage. The goal is to distinguish a feature that needs a better chance from one that is quietly pulling attention away from the product\u2019s real value.

Look for evidence beyond a usage number

Low usage alone is not a verdict. A feature may be hard to discover, used only in a valuable edge case, or too new to judge. Combine several signals:

  • Do users describe a real problem that the feature solves?
  • Do people return to it after trying it once?
  • Does it make a core workflow faster, safer, or clearer?
  • Does support reveal confusion that the team can realistically fix?
  • What would become harder if it disappeared?

The answers should come from actual behaviour, support conversations, and targeted observation\u2014not a vote on a hypothetical redesign.

The UK Government\u2019s agile delivery guidance is a useful reminder to work in small increments and learn from users. That applies just as much to deciding what to stop as deciding what to build next.

Separate a bad implementation from a weak problem

A useful feature can fail because its implementation is confusing. Before retiring it, identify the smallest credible version of the underlying job.

For example, if a reporting screen is rarely opened, the problem may not be \u201ccustomers do not need insight.\u201d It may be that the insight arrives too late, requires too much setup, or is disconnected from the action someone needs to take.

Test the simplest alternative that could change the conclusion: a clearer entry point, a short guided workflow, or a concise summary where the work already happens. Set a time limit and a success condition. If the problem remains unimportant after that focused test, continuing to invest is usually a story about attachment rather than evidence.

Be explicit about the opportunity cost

Every feature carries more than build cost. It appears in navigation, documentation, support, quality assurance, permissions, analytics, and future product decisions. In an AI product, it can also create another area that needs careful safety and reliability review.

Ask what the team could do with the same attention. Could it improve activation? Make the main workflow faster? Fix a recurring customer pain point? Strengthen a feature that people already rely on?

This comparison makes the decision less emotional. You are not deciding whether a past effort was worthwhile. You are deciding where the next effort will create the most value.

Retire with care

If the feature is used, removal deserves a clear plan:

  1. identify the people affected and the work they will need to do instead;
  2. communicate the change directly and early;
  3. preserve or export important data where needed;
  4. offer a simpler replacement when one exists;
  5. monitor the result and keep a route for real problems to reach the team.

For many features, a gradual sunset is better than a surprise. For a feature that is confusing everyone, a prompt removal may be kinder.

What remains after removal

The best reason to retire a feature is not that it failed. It is that the product becomes more focused without it.

A smaller surface area makes the main promise easier to keep. It lets a team concentrate on the work users actually value, and it creates room for the next experiment to be intentional rather than additive.