When to remove features from your product

We’re always adding to our products. But we don’t often remove things. This is a problem that becomes worse as a product gets bigger.

Backlogs are additive. New requests come in, features get added to the list, and the product grows. Users might flag confusion or friction, but the focus is always on doing new things. Nobody asks to take something out.

And yet, if you never remove anything, you end up with a product that is hard to navigate, expensive to maintain, and increasingly difficult to keep coherent.

If you only add and never remove, you’re likely adding complexity too.

When we talk about simplification, it is easy to imagine dramatic cuts - a whole section of the product disappearing overnight.

In practice, it rarely happens like that. Simplification normally looks like this:

• A long form with 20 fields gets trimmed to 10. The rest move to an edit flow or a settings page, not the creation step.

• Two features that do slightly different versions of the same thing get merged into one.

• An option that is rarely used gets hidden behind an advanced settings toggle, rather than taking up space in the main flow.

• A journey that requires five steps gets redesigned to require three.

These changes add up. They make the product easier to use - and maintain - without destroying anything.

Start with adoption data. Look at which features get used a lot, and which are used less. Low usage is a signal worth investigating, but it is not automatically a reason to remove something. A feature might have low usage because it was never surfaced well, or because it serves a small group of users who depend on it heavily.

Low usage becomes more interesting when combined with other signals:

• Cost to run - does this feature require significant infrastructure, third-party services, or maintenance overhead relative to how much it is actually used?

• Support burden - does it generate a disproportionate number of tickets, questions, or complaints?

• Technical complexity - is it fragile, poorly understood, or a frequent source of bugs that spread into other parts of the product?

• User confusion - do users struggle to understand what it does, or how it relates to other things in the product?

• Edge cases - does it solve a problem that only arises in rare, specific circumstances that most users will never encounter?

Any one of these on its own might not be enough. But if several of these apply to a single feature, the negative impact compounds. Whether to remove that feature becomes a much easier conversation than if it was just a bit underused.

The clearest removals are the ones where you can point to something measurable. “This feature generates 25% of our support tickets” is a far easier argument than “I think the product would feel cleaner without this.”

Simplicity on its own is a hard thing to quantify. That does not mean it is not real. But it’s harder to justify when the default position is to leave things in.

A good time to simplify is during a redesign or a rebuild. When you are already changing how something works, you have a natural opportunity to challenge everything that exists today. The cost of removal feels lower because you are already touching the journey. It’s easier to ask “is this needed in the new version?” than “should we remove this from the current version?”

The same principle applies to bugs. Not every bug needs to be fixed. If something minor has been sitting in the backlog for two years, has never been escalated, and affects a tiny number of users, it is reasonable to close it rather than treat it as an obligation you will eventually get around to. The backlog is not a to-do list you will ever finish. Treating it like one is a form of debt in itself.

The strongest argument for removing something is not that it is rarely used or expensive to run. The strongest argument is that it no longer belongs.

If your product has a clear vision and strategy, you have a way to evaluate not just what to add, but what to keep. A feature that made sense two years ago might not fit where the product is heading. A capability that was added to close a deal might be pulling the product in a direction you no longer want to go.

“This does not fit our product vision” is a more compelling reason to remove something than “we are too busy to maintain it.” It gives the removal a rationale that is forward-looking rather than defensive, and it connects individual decisions to the broader direction of the product.

This is easier said than done. Many products lack a clear enough vision to make this argument consistently. But vision applies to removals just as much as it applies to additions. If you are using your strategy to decide what to build, you can use it to decide what to cut.

When we add features, we ask: what problem does this solve?

It is worth turning that question around when evaluating what to keep: why should this still exist?

One way is to use feature flags not just for rolling things out, but for testing removal. Turn something off for a subset of users and see what happens. You are likely to get more useful signal from watching behaviour change than from asking users directly. Ask someone if they mind if you remove a feature, and they will probably say keep it, even if they never use it.

A gentler version is to put a brief notice on a low-usage feature - something that flags you are considering retiring it. Invite feedback if you aren’t ready to hit delete yet. This surfaces the users who genuinely care, without creating the impression that you are asking permission from everyone.

Neither of these is a substitute for the harder work of making the case internally. But they can help you gather the evidence you need to have that conversation.

Adding features is how products grow. Removing them is how they improve.

If you’re never removing things, watch out. You might be over-complicating your product. Simplify what you can.

Product Notes is free and lands every week. Subscribe to get it in your inbox.