In the PMHQ Slack community, we regularly get thought-provoking questions that we feel should be explored in-depth and documented for future reference. We’re starting a new set of Q&A posts called Highlights to dive into these kinds of questions, and enable everyone in the community to revisit the answers and contribute further!

---

“Hi all – I have a 2-part question:

1) What is the threshold of usage to make the decision to remove a feature?

2) If the usage is overall low, but a non-insignificant number of high-paying clients are using it, what is the approach to making this change?“

– Penny Yuan, Sr. Product Manager at Poll Everywhere

Our community of product leaders had lots of great insights to share on this particular topic! Below is the summary of their approaches in removing features.

Note that in some organizations, the act of removing a feature can also be called feature sunsetting, feature discontinuation, feature deprecation, killing off a feature, etc.

Alan’s Approach

Alan uses multiple metrics to determine whether to sunset a feature or not, rather than relying on a single utilization metric. He looks at customer adoption, market impact, strategic impact, and other considerations.

He also suggests having a discussion with the clients who are currently using the feature.

The goal of this discussion is to figure out why they’re using it and how feature removal will affect their perception of the overall product.

Chris’s Approach

Chris Kluis, VP Strategy & Business Development at Mintek, both works at a B2B company and also uses B2B software, and therefore sees the issue from both sides.

He brought up a personal example where one particular feature had been changed, which broke his entire flow around the product. This lack of communication and lack of user empathy led him to stop using the product.

He’s attempted to make enhancements to underutilized features in his product, and found that for particular customers, those features were critical – and that the enhancements created a huge problem for them.

The key for him is that any time a product manager decides to make breaking changes or remove functionality, the product manager needs to know if it is important to the users who use it, and what the impact of a change or removal is prior to making the change.

One place to start is to hide functionality through settings and configurations.

By taking this route instead of fully sunsetting a feature, he’s found that he can better gauge feature criticality based on how many users decide to opt back in to having that feature, while still enabling the majority of users to work with less clutter.

Vazgen’s Approach

Vazgen Babayan, Product Manager at Workfront, highlights that understanding customers is key. When there’s low utilization of a particular feature, he’s found that there are actually two different reasons for why that might happen.

The first underlying reason might be that users prefer to get the job done through other existing processes or more specialized products.

In cases like these, feature removal is a good idea – since your user doesn’t feel that solving this problem makes sense in the context of your product.

The threshold for removal depends on the feature. For example, for any sort of administrative functionality, having only 1% utilization can actually be great, since administrators (the targeted user segment) may make up a very small portion of the total user base.

The second underlying reason might be that users would find your feature helpful in getting the job done, but that they’re running into blockers within the functionality.

In cases like these, feature removal is a bad idea – the user definitely has a problem they want solved by your product, it’s just that your product isn’t solving it well enough for them.

When this happens, the problem that the feature is targeting is worth solving. Finding the underlying reason for why those customers use it enables you to better plan the deprecation: by suggesting workarounds, putting replacements on the roadmap, creating additional functionality elsewhere that solves the problem better, etc.

In the end, there will always be customers who won’t want to change their ways. In cases like these, Vazgen advocates for a hard stance – but taking this hard stance still requires a deep understanding of the underlying problem.

Other Factors to Consider

As with any product decision, you should consider both the upside and the downside before coming to a decision.

First, what’s the benefit of sunsetting the feature?

That is, what sorts of cost savings do you expect, and how does sunsetting this feature benefit your users?

Then, what’s the cost and the risk of killing this feature?

It’s hard to evaluate cost without deeply understanding why users are using this feature or not. Hence, user research and empathy are critical to making these decisions.

Segment your customers into “those that use the feature” vs. “those that don’t”, then conduct customer research into both of these segments (e.g. interviews, focus groups, surveys, shadowing).

It’s possible that the customers who do use the feature are actually far more valuable and should be targeted more heavily.

In Penny’s situation, she has a significant number of valuable customers as part of the “those that use the feature” segment. Making a feature deprecation decision on overall utilization may not be a good call, especially when your product serves multiple customer segments.

In cases like these, you may need to make the even tougher call to double down on just the most valuable user segment, and be prepared to alienate the broader user base.

If serving the broader user base causes your organization to lose your most valuable users, then you may need to stop serving the broader user base and pivot your product strategy accordingly.

Another factor to be mindful of: existing support agreements. You may need to give advance warning, and you should clear it with the legal team.

In cases where a feature deprecation is associated with releasing a new version of that feature, you’ll want to migrate users from the deprecated feature over to the new one, and ensure that you are still within the bounds of your support agreements.

Communication Strategy

Once the decision has been made to sunset a feature, you need to communicate your decision to customers.

If you don’t, they may be unpleasantly surprised, and may lose trust in your product.

As you craft your message, be honest but thoughtful.

Show them that they’re trading upwards by deciding to stay with you, even as you remove functionality.

You can phrase it something like: “We’re discontinuing this feature because we’ve noticed that very few of our users are getting value out of it. We’ll take the resources that we invested in maintaining this feature and invest them instead on new features that will enable you to get even more value out of our product.”

Remember that you’re making this tradeoff because you’re working with limited resources.

If you had unlimited resources, you probably wouldn’t need to sunset this feature in the first place. You’re sunsetting it so that you can focus, double down, or invest in additional strategic capabilities in the product.

Provide this context and excitement for customers, so that they buy into your product direction.

They’ll still be disappointed by what you’re taking away. However, when you’re transparent about why a feature is being removed, and when you show why the product will be better due to it, your customers will be more likely to accept your change.

Be sure to also address the emotional aspect of such a decision.

Even though you may have very few users who use that particular feature, they’re likely especially attached to that feature. This scenario is particularly likely in cases where the broad user base isn’t using the feature.

Let them know that you understand that you are causing them pain, but that this short-term pain is worth the long-term gain.

You can phrase it something like: “We know that some of you are die-hard fans of this feature, and we’re really sorry that we need to make this decision. We’re absolutely going to do our best to make up for this loss over the next couple of months, and provide you even more value than you got before.”

Of course, remember to check that your messaging is in line with your brand voice! Messages that don’t reinforce the brand can wind up damaging customer trust.

Final Thoughts

As product managers, sometimes we need to sunset existing functionality, so that we can provide higher value in its place.

To make this decision, ask questions about how the feature is being used. What kinds of customers are using this feature? Is the feature underutilized because it’s inherently not valuable to existing customers, or because it’s creating more pain than the value it provides?

Explore your options around sunsetting a feature. One option is to keep it available for all users. Would it be possible to keep it at a low cost on maintenance mode? If so, is there a way to hide it from the users who aren’t using it?

Another option is to make additional iterations on the functionality. Perhaps the feature is valuable, but it’s just not able to provide the value that the users want. What’s blocking users from using it more deeply?

Yet another option is to conduct deeper customer segment research, and identify whether the segment using the feature is more valuable than the ones who do not. In that case, what changes need to be made to the product strategy to retain these more valuable customers, and what new tradeoffs need to be made?

If you do decide that sunsetting the feature is the right approach, now is the time to ask questions around strategy and execution.

What benefit do you get from sunsetting off the feature, and what are the costs and risks associated with doing so?

Do you have a transition plan and communication strategies in place before kicking off the sunset?

Do you have a clear grasp of the downstream effects that sunsetting the feature will create – such as contractual agreements, perception in the marketplace, or product dependencies?

Remember that while sunsetting features can be painful, not sunsetting it can be deadly to your company.

It’s a tough decision – but it’s a decision that only you as a product manager can make.

About Our Contributors

Penny Yuan is a Sr. Product Manager at Poll Everywhere.

Alan is a community member on the Product Manager HQ Slack community.

Chris Kluis is VP Strategy & Business Development at Mintek.

Vazgen Babayan is a Product Manager at Workfront.

 

---

Have thoughts that you’d like to contribute around how to sunset a feature? Chat with other product leaders around the world in our PMHQ Community!