I have a clear memory of sitting in a quarterly planning meeting at my last company. We had the roadmap on the screen, a long list of exciting new things we were going to build. Then someone asked what we were going to turn off. The room went quiet. Turn something off? We were builders. Our job was to add, to expand, to create. The idea of removing something felt like admitting a mistake.
This is a trap many of us fall into. We become net feature accumulators. Every quarter ships new things, and almost nothing ever gets retired. At first, the cost is invisible. It’s a little more surface area to maintain, another decision for new users to make during onboarding. But over time, those costs compound. Your product gets barnacles. It becomes slower, harder to explain, and harder for your own team to manage. The work gets rough, not smooth.
Product pruning is not a failure. It is a discipline. It is the gardening that makes space for healthy growth. It is a strategic capability that keeps your product and your team from drowning in the weight of their own history.
The Four-Part Test for What to Cut
#You cannot make these decisions on gut feeling alone. Feelings are where the internal politics live. You need a framework, a defensible system for identifying candidates for retirement. When I work with leaders on this, we use a simple four-part test.
Usage Data: This is the starting point. Be brutally honest with the analytics. How many people used this feature in the last 90 days? How often? If the number is zero or close to it, you have a prime candidate. Don’t let yourself get sidetracked by the one person who loves it.
Customer Fit: Who, exactly, is using it? Is it a critical feature for your ideal, high-value customer segment? Or is it a legacy tool used by a handful of early adopters who don’t represent your current market? It’s okay to outgrow features as you outgrow customer profiles.
Maintenance Cost: Talk to your engineers. How much time does this feature consume? Is it built on an old, fragile part of the codebase? Is it a constant source of support tickets and bug reports? Some features have a surprisingly high tax on your team’s focus.
Strategic Alignment: Look at your company’s strategy for the next 18 months. Does this feature support that direction? Or is it a relic of a pivot you made two years ago? A product that tries to be everything for everyone ends up being nothing special for anyone. Pruning is strategic focusing.
If a feature fails on two or more of these tests, it belongs on the kill list.
The Deprecation Playbook
#Once you have your list, the real work begins. The goal is to remove the feature without alienating the few people who still use it. This requires a clear communication plan. Moving with a steady, deliberate process prevents the whiplash of a surprise shutdown.
- Set a Clear Timeline: Don’t just pull the plug. Announce a sunset date 30, 60, or even 90 days in the future. The more critical the feature, the more lead time you give.
Your product is defined by what you subtract. - Communicate Broadly and Directly: Use every channel. Send emails to the specific users you identified. Put a banner inside the product. Write a blog post explaining the change. Over-communication is your friend.
- Explain the ‘Why’: Be transparent. Frame it as a positive move. “We are retiring Feature X on [Date] to focus our resources on improving Feature Y, which provides a more robust and modern solution for [Job to be Done].”
- Provide an Off-Ramp: What should users do instead? Is there a new feature that replaces the old one? A third-party tool you can recommend? A way for them to export their data? Don’t leave your users stranded.
The Grandfathering Trap
#Someone will inevitably ask, “Can we just let existing users keep it?” This is called grandfathering, and it is a well-intentioned trap. It feels like a kind compromise, but it rarely solves the underlying problem. You still have to maintain the old code. You still have to support it. You create a two-tiered product that is more complex for everyone.
My experience, paid for with scars, is that a clean break is almost always better. It forces the hard conversations and the necessary migrations. If you absolutely must grandfather access, do it with a non-negotiable end date. “Current users can continue to access this feature until [Date], at which point it will be retired for everyone.” This creates urgency and prevents the problem from lingering for years.
Making Pruning Someone’s Job
#Here is the core political problem: nobody’s bonus is tied to turning off a feature. The sales team will worry about losing a talking point. The support team will worry about angry customers. A product manager’s performance is almost always measured by what they ship, not what they retire.
To make this work, the act of pruning must be an explicit part of someone’s job description. This responsibility usually falls to the Head of Product, a Group PM, or even the founder. Someone has to be empowered to advocate for the health of the entire product, not just one feature set.
This person’s role is to run the four-part test, build the deprecation plan, and absorb the political heat. They aren’t the villain. They are the leader protecting the team’s focus and ensuring the product remains capable of solving the customer’s most important problems. They are the ones who understand that your product’s future is defined as much by what you subtract as by what you add. Pick up the shears.