Hey there, fellow product managers! You know that feeling when your product starts to feel a bit… heavy? Like, it’s groaning under the weight of all those features you’ve added over the years, and suddenly, everything feels slower, clunkier, and just not as delightful as it used to be? Yeah, we’ve all been there. It’s like your product is begging for a spring cleaning, but instead of dusty old boxes, you’re dealing with features and backlog items that have overstayed their welcome.

Now, here’s the thing: while our current product, version 1.0, is still in its early stages and doesn’t yet require such a cleanup, it’s essential to recognize that feature bloat is a common challenge in product development. Drawing from industry experience, we know that as products evolve, regular feature pruning becomes necessary to maintain focus and efficiency.

Take, for instance, the team at Origin Spice, as detailed in their blog post “The Art of Feature Pruning: An Origin Spice Journey”. We shared how we carefully remove underperforming or unnecessary features, which helped us streamline our product, ultimately leading to improved user satisfaction and team productivity. This serves as a valuable lesson for us, even at this early stage, reminding us that the courage to let go of features is just as necessary as the creativity to build them.

The truth is, product quality is shaped as much by what you remove as by what you ship. Feature bloat is real—it slows teams down, confuses users, and hides the real value of your product. But let’s be honest: removing features is hard. It feels risky, political, and sometimes like an admission of failure. Stakeholders might freak out, your team might resist, and you might even worry about losing customers. So, most of us avoid it. But here’s the thing—removing the right features can actually make your product better. It can make it faster, easier to use, and more focused on what really matters to your users.

That’s why I’m excited to share a framework that’s helped me and my team tackle this challenge head-on: the Subtraction Audit. It’s a four-stage process that makes removing features and backlog items less scary and more systematic. In this post, I’ll walk you through how it works, share a case study of a team that saw engagement rebound after removing a low-use feature, and give you some tips on how to navigate the tricky parts, like stakeholder resistance and reframing subtraction as improvement, not failure.

So, grab a coffee (or your beverage of choice), and let’s dive in.

Why Removal Is Harder Than Building (But Often More Valuable)

Building new features is exciting. There’s a clear goal, a launch date, and that satisfying moment when you see users engaging with something you created. Removing features? Not so much. It’s like telling your team, “Hey, remember that thing we spent months building? Yeah, we’re gonna scrap it.” Ouch.

Here’s why it’s so tough:

• It feels like failure. We’re wired to see removal as a step backward, like we’re admitting we made a mistake.
• Stakeholders get nervous. They worry about upsetting users or losing that one customer who might be using that obscure feature.
• It’s politically tricky. You might have to convince people who were invested in building that feature in the first place.

But here’s the flip side: subtraction is often more valuable than addition. A lean, focused product is easier to maintain, faster to iterate on, and—most importantly—better for your users. They don’t have to wade through a sea of irrelevant features to find what they need. Plus, your team can focus on building things that actually move the needle instead of babysitting legacy code.

So, how do you decide what to remove? That’s where the Subtraction Audit comes in.

The Four-Stage Subtraction Audit

The Subtraction Audit is a repeatable process that helps you identify, evaluate, plan, and execute feature removals. It’s designed to take the emotion out of the decision and replace it with data, feedback, and alignment. Here’s how it works:

Stage 1: Data Analysis

Start by looking at your usage data. Which features are hardly ever used? Maybe there’s a report that only 2% of your users have ever opened, or a customization option that’s been touched by a handful of people. These are prime candidates for removal. Tools like Mixpanel, Amplitude (love this one), or even Google Analytics can help you spot these low-engagement features.

Pro tip: Look beyond usage rates. Check for features that are started but not completed—those might be confusing or broken.

Stage 2: User Feedback

Next, talk to your users. Ask them which features they find confusing, unnecessary, or just plain annoying. You might be surprised by what you hear. Sometimes, the features we think are “nice to have” are actually getting in the way. Surveys, user interviews, and even support ticket analysis can be goldmines here.

Pro tip: Listen to what users don’t say. If no one mentions a feature, it’s probably not adding much value.

Stage 3: Team Input

Your development team probably has a good sense of which features are causing the most headaches. Ask them which parts of the codebase they’d love to see simplified or removed. Features that are buggy, hard to maintain, or constantly needing updates are draining your team’s time and energy.

Pro tip: Hold a “feature amnesty” session where the team can openly discuss which features they think should go—no judgment, just honest feedback.

Stage 4: Stakeholder Alignment

Once you’ve identified some candidates for removal, it’s time to talk to your stakeholders. This is where things can get tricky, but it’s crucial. Present the data and feedback you’ve gathered and explain how removing these features will improve the product. Focus on the benefits: faster performance, happier users, and a more focused roadmap.

Pro tip: Frame it as an improvement, not a loss. You’re not just removing a feature—you’re making the product leaner and more efficient.

Identifying Features That Are Dragging You Down

Beyond the Subtraction Audit, there are other signals that a feature might be more trouble than it’s worth. Keep an eye out for:

• Low usage rates: If almost no one is using it, it’s probably not essential.
• High support ticket volumes: Features that generate a lot of questions or complaints are likely confusing or broken.
• Negative user feedback: If users are actively saying they don’t like something, listen to them.
• Features that are frequently bypassed or worked around: If users are finding ways to avoid a feature, it’s not serving its purpose.
• Maintenance nightmares: Features that are expensive to update or fix can drain your team’s resources.

Remember, not every rarely used feature needs to go—some might be critical for a small but significant segment of users. That’s why the audit includes multiple stages: data alone isn’t enough; you need the whole picture.

Case Study: How One Team Removed a Low-Use Feature and Saw Engagement Rebound

Let me tell you about a SaaS company I worked with. They had a feature that allowed users to customize the color scheme of their dashboard. It sounded like a cool idea at the time—personalization is trendy, right? But in practice, only a tiny fraction of users ever touched it. Meanwhile, the code was complex and buggy, leading to a steady stream of support tickets. The team spent hours every month fixing issues related to this one feature.

After going through the Subtraction Audit, they decided to remove it. Here’s what happened:

• Support tickets dropped by 20%: No more complaints about the color picker breaking or themes not saving.
• User satisfaction scores increased by 5%: Users appreciated the cleaner, less cluttered interface.
• Developer happiness improved: The team was thrilled to have one less thing to worry about, freeing them up to focus on higher-impact work.

The best part? Not a single user complained about the removal. It turns out that the feature wasn’t as beloved as the team had feared.

What You’ll Learn from This Process

By incorporating the Subtraction Audit into your workflow, you’ll pick up a few key skills:

• How to evaluate feature usefulness with a repeatable process: No more gut decisions—use data, feedback, and team input to make informed choices.
• Techniques to prepare stakeholders and navigate resistance: Learn how to present your case with confidence, using data to back you up.
• How to frame subtraction as improvement, not failure: Focus on the benefits—speed, simplicity, and focus—and show how removal can be a win for everyone.
• Lessons for PMs and CPOs on building a culture that values clarity over clutter: Encourage experimentation and make it okay to let go of what’s not working.

Go Ahead, Give It a Try.

Happy building (and eventually, pruning)!