Features Worth Killing

Let's talk about a counterintuitive truth in software development: sometimes the best feature you can ship is removing a feature altogether. In an industry obsessed with building and adding, the discipline to subtract is surprisingly rare – and surprisingly powerful.

After years of building products, I've learned that feature removal, when done right, isn't just cleanup – it's strategic product development that can dramatically improve user experience, technical quality, and business outcomes.

The Feature Graveyard

Before diving into the why and how, let me share some real examples of features I've personally killed that measurably improved products I've worked on:

1. The "Advanced Options" Panel That Nobody Advanced With

On an e-commerce dashboard, we had a sprawling "Advanced Options" panel with 20+ configuration settings. It looked impressive in demos, but our analytics told a different story: 94% of users never touched it, 5% opened it and immediately closed it, and only 1% actually changed any settings.

What's worse, that 1% generated 30% of our support tickets. We were maintaining complex code with broad surface area for a tiny fraction of users, and even they weren't benefiting.

We replaced it with three carefully chosen settings that lived directly in the main interface, and ensured they had sensible defaults. The code simplification allowed us to fix long-standing bugs in more important areas.

2. The Calendar Integration Nobody Used

For a project management tool, we'd built an ambitious two-way calendar sync feature that took three developers two months to create. Six months after launch, our usage data showed less than 3% adoption.

Maintaining it wasn't free – we had recurring bugs from API changes, constant edge cases around time zones, and had to keep a separate authentication flow just for this feature. The integration was adding complexity to our codebase far out of proportion to its value.

We replaced the entire system with a simple "Export to Calendar" button that generated a standard .ics file that works with every calendar system. Usage of the calendar feature increased to 15%, development and maintenance costs dropped to near zero, and reliability issues disappeared entirely.

3. The Dashboard That Created Decision Paralysis

For an analytics product, we had built a fully customizable dashboard where users could create and arrange any of 40+ visualizations. It was our most requested feature and looked fantastic in sales demos.

But after launch, we noticed a problem: new users would spend an average of 7 minutes trying different visualizations, never settle on a combination they liked, and then rarely return to the product.

We replaced it with three pre-built dashboards focused on different user roles. Each had 5-7 carefully chosen visualizations with minimal customization options. The result? Time-to-value dropped from weeks to minutes, and our retention metrics dramatically improved.

Why Feature Removal Works

If you're wondering why removing features can be so impactful, consider these principles:

1. Cognitive Load Is Your Enemy

Every feature adds cognitive load for your users. Even if they never use it, they have to understand it exists, decide whether to use it, and mentally track it as an option. When you remove unnecessary features, you're not taking away value – you're giving users the gift of simplicity.

The best products don't give users the most options – they make the important actions obvious and reduce decision fatigue.

2. Maintenance Costs Are Hidden Killers

In codebases, unused features aren't just passive – they actively harm your product by:

• Increasing testing surface area
• Creating unexpected interactions with new features
• Adding complexity to deployment and monitoring
• Making onboarding harder for new team members
• Diverting maintenance effort from core features

I've found that removing a complex, underused feature often frees up 5-10% of a team's capacity – capacity that can now go toward improvements users actually value.

3. The Paradox of Choice Is Real

Every product manager should read Barry Schwartz's "The Paradox of Choice." More options often lead to:

• Decision paralysis (users can't decide which option to choose)
• Decreased satisfaction (users wonder if another option would have been better)
• Increased anxiety (users fear making the wrong choice)
• Choice avoidance (users give up rather than choose)

By carefully curating features, you're not limiting users – you're guiding them toward success.

How to Kill Features (Without Killing Your Career)

Removing features takes political skill and data-driven strategy. Here's my playbook:

1. Build the Evidence Case

Before suggesting removal, gather compelling data:

• Usage statistics (how many users, how frequently)
• Support and maintenance costs
• Technical debt impact
• User confusion metrics (help tickets, rage clicks, etc.)
• A/B test if possible (show some users a version without the feature)

Framing matters here – this isn't about "taking away" but about "streamlining" and "focusing." Use language like "simplifying the experience" rather than "removing features."

2. Consider the Migration Path

For the small percentage of users who do use a feature, provide alternatives:

• Create a simpler way to achieve the same outcome
• Build a specialized tool outside the main product
• Partner with a third-party integration that handles that need
• Grandfather existing users while removing it for new ones

The goal isn't to abandon users who need certain functionality – it's to solve their needs in a way that doesn't compromise the experience for everyone else.

3. Execute a "Sunset" Strategy

Don't just rip features out abruptly:

1. Announce the change well in advance
2. Explain the rationale with data
3. Provide clear alternatives
4. Consider a phased approach (mark as deprecated before removal)
5. Listen carefully to feedback and be willing to adjust

In most cases, you'll find the outcry is much smaller than feared. Often, the loudest voices come from people who rarely used the feature but liked knowing it was there.

When Not to Remove Features

Feature removal isn't always the right call. Be cautious when:

• A small but important customer segment relies heavily on it
• The feature is central to your brand identity or differentiation
• It's critical for specific use cases, even if those are uncommon
• It creates network effects that benefit the broader ecosystem

The key is distinguishing between "low usage, high value" features (keep these) and "low usage, low value" features (prime candidates for removal).

Your Feature Removal Opportunity

I challenge you to identify one feature in your product that:

• Has low usage (under 20% of users)
• Generates disproportionate support or maintenance costs
• Creates confusion or complexity for new users
• Has reasonably simple alternatives

Then build the case for removing it. This exercise alone will sharpen your product thinking, even if you ultimately decide to keep the feature.

Remember: Every feature you remove is making room for focus on what truly matters. Or as Antoine de Saint-Exupéry famously said: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

The most impactful feature you ship this year might be the one you decide to kill.