In product management, much of the focus is on building and growing products, but knowing when to shut down a feature or product is equally important. Unlike development, where you can pivot and iterate, deciding to sunset something is final. If the timing’s off, the product fails.

Product managers often juggle competing ideas from various stakeholders, making it hard to prioritize. Road mapping is a continuous process, not a one-time task. 

In this post, I’ll share simple strategies I use to decide when to kill a product or feature, helping you make smarter decisions.

You Should Kill a Product Feature When:

  • Users are not using it
  • When the cost outweighs the benefit: Think of maintenance cost, support cost, and opportunity cost.
  • When the feature doesn't align with the larger vision (anymore)
  • When the feature has a negative impact on another (more important) feature
  • When users are not using it anymore: If users aren't using it, kill the feature.

You might have some product features in your portfolio that were popular in the past but now they aren’t. Users are not using it anymore. The drop in usage could be for multiple reasons: maybe the feature is not as useful as it used to be, maybe there is a better alternative, or perhaps the design is outdated (read: painful).

Usually, it’s easy to spot these kinds of features. If you look at usage data, you will see the usage trending towards zero.

When the Cost Outweighs the Benefit

This one is a little trickier but is one of the most effective ways of deciding which feature to kill.

If the value (that users get from the feature) < cost (to keep the feature in production), then kill it.

Unfortunately, this math is not simple. Quantifying value is usually complex and requires translating multiple aspects (like user growth, user satisfaction, competitive advantage, etc.) into a single number.

The other end of the equation is also tricky. Measuring the short-, medium---, and long-term costs takes a lot of time and effort. Most people need to be more active and busy to do the calculation.

Even when some people take the time to quantify the cost, they usually miss one or more types of costs involved:

  • Maintenance cost: If the price of the technical resources and engineers required to keep the feature up and running is higher than the value, then kill it.
  • Support cost: If the support cost is higher than the value to the user, then kill it. If users are using a feature, they will have issues. When they do, they will reach out to customer support for help. Customer support will answer the simple questions but might reach out to engineers for more complicated issues. The cumulative time spent answering or fixing such issues is usually manageable. And if it is higher than the value users are getting from the product, you know what to do - kill it!
  • Opportunity cost: If diverting resources from a low-value feature to a high-value feature promises a higher return, then kill the low-value feature. Inbox by Gmail, for example, was taking away resources from Gmail. Hence, it was shut down. (Read below for more details)

The concept of opportunity cost sounds obvious, but very often, product managers overlook it. In their busy lives, product managers need to catch up on the day-to-day. They need to focus on the larger picture. Hence, they need to calculate the opportunity cost more often or more objectively.

When the Feature Doesn't Align with the Larger Vision (Anymore)

Most product teams, at some time, have built features or products for a specific customer, a small use case, or based on limited resources. This mostly happens in early-stage and growing companies.

However, when the team and company mature, they create specific product vision and goals. At this time, if any features do not align with the now-clear vision, kill it.

When the Feature Has a Negative Impact on Another (More Important) Feature

If there are new features that negatively impact the performance of older features, then one of them needs to go away.

Product managers should always be aware of how their features might impact other features. And accordingly, they should let the different product managers know about it in advance. Then, work together to decide which feature gets the axe.

A few real world examples to help you understand the above tactics

Twitter shuts down Fleets

What: Twitter launched fleets in an effort to encourage more users to share more. But they realised that only those users who are already Tweeting were using Fleets to amplify their existing tweets. As a result, Fleets was shut down.

Why: new users are not using it

Periscope shuts down after 6 years of launch

What: Periscope took live streaming to another level, especially after the acquisition from Twitter

However, it shut down after about 6 years. The reason to shut it down as per the company is that “The Periscope app is in an unsustainable maintenance-mode state, and has been for a while. Over the past couple of years, we’ve seen declining usage and know that the cost to support the app will only continue to go up over time.”

Why: cost to maintain outweighs benefit

Google shuts Neighbourly

What: Google shuts Neighbourly (a Q&A app) because “it did not get the traction the company was hoping for."

Why: users not using it

Google shuts Inbox

What: Inbox by Gmail was an email service developed by Google. It was released to the public in May 2018. Google then shut it down in April 2019 to allow Google to focus “solely on Gmail.”

Why: very high opportunity cost.

That is it for today.

While researching for this article I came across about 20 very interesting stories of companies/products that were shut down.

If you're interested in knowing which ones, follow me on Twitter and stay tuned for a great thread on this topic.

If you'd like to receive one new guide (like this one) on email, then subscribe to my newsletter here.

Conclusion

Knowing when to kill a product feature or an entire product is an essential but often overlooked skill in product management. Many times, the best decision for the future of a product is to let go of features that no longer serve the bigger picture, cost too much to maintain, or no longer align with user needs.

By considering factors like feature management, the cost-benefit ratio, and alignment with product vision, product managers can ensure that resources are focused on the most valuable and impactful aspects of their product. It’s also important to keep in mind the long-term benefits of focusing on high-value features, even if it means letting go of what once seemed essential.

Killing a feature doesn’t mean failure—it means product management is evolving and adapting. It’s a crucial part of the product lifecycle that ensures only the best features survive and the product continues to improve.

FAQs: Kill A Product Feature 

  1. What does killing a feature mean in product management?
    It means removing a feature from the product because it no longer serves its purpose, is too costly, or misaligns with the product’s goals.
  1. Why is it important to kill a product feature?
    It allows product managers to focus resources on features that add more value, ensuring the product evolves efficiently.
  1. What’s the difference between a feature and a product?
    A feature is a specific function or tool within the product, while the product is the full offering provided to users.
  1. How do you analyze if a feature should be removed?
    Check usage data, evaluate costs (maintenance, support, opportunity), and ensure it fits the product's vision and goals.

How I can help you:

  1. Fundamentals of Product Management - learn the fundamentals that will set you apart from the crowd and accelerate your PM career.
  2. Improve your communication: get access to 20 templates that will improve your written communication as a product manager by at least 10x.
Posted 
Aug 21, 2021
 in 
Product Management Concepts

More from 

Product Management Concepts

View All

Join Our Newsletter and Get the Latest
Posts to Your Inbox

No Spam. Unsubscribe any time.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.