When was the last time you removed a feature?

In the last 7 years, I’ve been part of a handful of product teams at early stage startups. And in 90% of cases, we talked about adding features. Almost never about removing them.

And the thing is, removing a feature can have a big impact on your growth. Features nobody uses add clutter, and clutter hides the features that actually matter.

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

So let me show you why too many features suck, what you get when you remove them, and how to actually do it. Plus how teams like Slack and Mixpanel did it.

Vamos!

80% of your product is dead weight

This is not me being dramatic. Pendo looked at feature usage across 615 subscriptions and found that 80% of features in the average software product are rarely or never used. They also estimated that public cloud companies spent up to $29.5 billion building them.

Read that again. 80%.

You can find the full report here: Pendo’s 2019 Feature Adoption Report​

So the question is not “what should we build next.” The question is what’s already in there doing nothing.

Features are not free

Every feature you keep costs you three times:

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.

Let's look into each one of them:

1. Your app feels cluttered

As you keep adding, your app gets full. As a product designer, my job is not to “find a free spot to add this feature to the UI.” My job is to make sure the whole experience is good.

And that experience is gone when the app is bloated.
New users feel overwhelmed.
The truly game changing features get buried.

2. More and more edge cases

More features means more edge cases. It gets harder to design anything new, because you need to think about how it interacts with everything else.

Say you have an analytics tool and you want to add a date range filter. Now you need to check every other place in the product where that filter could change the UI. That’s a lot of thinking for one small thing.

3. Engineering cost

Code needs to be maintained too. I’m not an engineer, so I won’t pretend to go deep here. But every dev I’ve worked with says the same thing.

What you get when you remove stuff

Most of your features aren’t helping you grow. They’re hiding the real value of your product. And worse, they make it harder for users to love it.

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 clutter. And clutter kills retention.

Remove the unused ones and you:

• reduce noise, so your top features can shine
• ship faster, because there’s less code and design to maintain
• improve your first 7 days retention, because new users get started easier

Why we keep building anyway

If removing features is so smart, why does nobody do it?

Three reasons.

Founder ego. We treat features as progress. A roadmap that says “remove stuff” feels wrong, even when it’s right.

Users lie. In interviews, people always say yes to new features. “Would you use X?” For sure. But once you build it? Silence.

Fear of backlash. “What if users get angry?”

But the backlash is the point. If nobody complains, the feature wasn’t valuable. If a handful of people scream, you just found your real power users. That’s insight you’ll never get from another round of fake-positive interviews.

How to ACTUALLY remove features

No, we don’t just delete something random and see what happens. Start with data.

Step 0: Set up tracking.​
Track every feature and how often people use it. PostHog is what we usually recommend.

Step 1: Check the numbers.​
What % of users touch each feature, and how often? You’ll spot the dead ones fast.

Step 2: Turn it off in the frontend.​
PostHog has feature flags, so you can switch a feature off for users without touching the code base.

Step 3: Wait for screams.​
Give it 2 weeks. See if anyone complains, or if nobody even notices.

Step 4: Decide.
​People screamed → keep it, you just proved it’s valuable Nobody noticed → remove it A few complained → interview them. Find out what made it useful. Maybe you can repackage it and ship a smaller version.

Step 5: Write it down.​
Document why you removed it and add the usage numbers. It’s very easy to forget. We had a case where months later we asked ourselves “why has nobody thought of this great feature yet?”, until we remembered we already killed it.

The case study

At Grauberg we recently finished a design sprint with a US-based fintech startup. They had 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 it.

We removed the whole page. And nothing broke. No outrage. We replaced the bloated dashboard with a single text alert on the one metric users actually cared about.

Result: 5% higher retention overall.

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

What Slack did

Slack had a screen sharing feature that let up to 15 people control your screen. Pair programmers loved it. They killed it anyway, because it was niche, adoption was low, it didn’t fit the long-term strategy, and it was expensive to maintain during a frontend re-architecture.

Reforge wrote a full breakdown of how Slack and Mixpanel did this, and it’s the best thing I’ve read on the topic: Upsides to Unshipping​

The mindset shift: Final notes

Stop measuring progress in features shipped. Start measuring it in how useful your product is.

Adding features doesn’t make it more useful. A clean interface with only the things people need does.

So, when was the last time you removed one?

Cheers!