When was the last time you removed a feature?

Hm?

In the last 7 years, I’ve been part of a handful of product teams of early stage startups, and in 90% of cases, we talk about adding features, not removing them.

Here’s the thing though: Removing a feature will have a big impact on your business growth, because features nobody uses add clutter and reduce the value of more useful features.

It’s like furniture. Add too much and you can’t even walk around anymore.

So let me show you the downsides of having too many features, the upsides of removing them and how to actually do it (+ how teams like Slack and Mixpanel removed features in the past).

Vamos!

Why having too many features sucks

Features come with costs:

• User cost – Every button steals attention from what actually matters.
• Design cost – You need to maintain it visually and structurally.
• Engineering cost – Every line of code makes future changes slower.

1. User Cost - Your app feels cluttered

As you keep adding features, your app starts to get full. As a product designer, my job is not to “find a free spot to add this feature to the UI”, it’s to ensure a great product experience overall.

And this great experience is not given when you have too many features bloating up the app.

It also makes new users feel overwhelmed and it might be harder to find the truly game changing features.

2. Design Cost - More and more edge cases

More features means more edge cases. It’s harder to design a new feature, because you need to think about how it interacts with all the other features. For example, if you have an analytics tool, and want to add a date range filter, you need to think about all the other places where this date range filter could have an impact on the UI.

3. Engineering cost

Needless to say, code needs to be maintained as well. I’m not an engineer, so I don’t want to go too much into detail here.

Why removing features will grow your business

Most of your features aren’t helping you grow. They’re dead weight. They’re hiding the real value of your product.

And worse: they make it harder for users to love your product.

Think about your own experience: how many times have you opened an app and felt lost? Too many tabs, too many options, too many “maybe one day” features.

That’s not innovation. That’s clutter.

And clutter kills retention.

If you remove unused features, you:

• reduce clutter, and your top features will shine.
• start to ship faster, as you don’t need to maintain so much code and design.
• will increase "first 7 days" retention rate, as it’s easier for new customers to get started.

At my Product Design Studio Grauberg, we recently finished another design sprint with a US-based fintech startup, and we decided to remove a full-blown page: an investor dashboard.

Result: 5% higher retention overall. More on the results later.

Why We Keep Building

If removing features is so smart, why don’t we do it?

Three reasons:

1. Founder ego. We equate features with progress. A roadmap that says “remove stuff” feels wrong, even if it’s right.
2. User lies. In interviews, users always say yes to new features. “Would you use X?” Of course. But once you build it? Silence.
3. Fear of backlash. “What if users get angry if we remove something?”

But here’s the thing: the backlash is the point.

If nobody complains when you remove a feature, it wasn’t valuable. If a handful of people scream, you’ve just discovered who your real power users are. That’s insight you could never get from another round of fake-positive interviews.

How to remove features in the best way possible

So, if you are still here: No, we don’t just remove a random feature to see what happens.
You have to start with data first!

Step 0: Set up tracking

Set up tracking for each of your features. For instance, you can use PostHog to track every feature and how often people use it.

Step 1: Check analytics

Check analytics, and see what % of users use each feature, and how often. You’ll quickly find features that are not adopted well.

Step 2: Remove the feature from the frontend

PostHog also has a feature called Feature Flags. It allows you to turn on/off features for users, without removing them from the code base.

Step 3: Wait for screams

For the next 2 weeks, you see if users complain about a feature missing, or if no one even notices if it’s gone.

Step 4: Evaluate and decide

• If enough people screamed → Keep the feature, you just proved how valuable it is.
• If no one noticed → remove it.
• If some people complained → Interview them, find out what made this feature so useful. Maybe you can repackage it and ship it only partially.

Step 5: Documentation

Write down why you removed the feature, and add some usage metrics to it. It’s very likely to forget in a few months why you removed it. We had a case where after a few months we asked ourselves “Why did no one think about this great feature yet?”, until we remembered why we removed it in the first place.

The case study

The fintech team I mentioned before built a gorgeous investor dashboard. Two months of work. Dozens of features.

Users said they wanted it. They nodded in interviews.

After launch? Less than 2% ever used the dashboard.

When they finally removed it, something surprising happened: nothing broke. No mass outrage. In fact, engagement improved when they replaced the bloated dashboard with a single text alert on the one metric users cared about, which eventually led to a 5% increase in overall retention rate.

The lesson: removing a feature revealed the real job-to-be-done.

An interesting article I found is about how Slack removed one of their features.

Fareed Mosavat – VP of Programs and Partners, Ex-Director Product Growth at Slack

The mindset shift

So instead of adding features as a means to progress, think of progress as “how useful is my product?”

Adding features doesn’t make it more useful, but a clutter-free user interface with only the features you need will skyrocket your growth.

Cheers!