When do you even want to remove product functionality? Think about your car’s interior or the interior of the last car you sat in. Picture the music player in the center control panel. We’ll assume the car has a screen displaying an app menu. The menu offers access to satellite radio, a music app, and the ability to play songs from your phone. Does it also have a CD player? Maybe. A cassette player? Almost certainly not. How about an 8-track player? Good grief—we hope not!

At various times, each one of those devices was standard in every car manufactured. At some point, the product teams responsible for their cars’ onboard music functionality decided to remove those devices. These teams may have found the decision difficult because there are plenty of car buyers who still expected those features. Some of the product teams probably faced a backlash from their markets.

So why did these product teams feel compelled to make those calls? Julie Hyman, a senior product manager for software maker Quest, puts the dilemma this way:

“Whenever you pull functionality from a product that’s been on the market for any period of time, you’ll be upsetting at least a small percentage of your users. But if you don’t make these decisions, if you let your product accumulate functionality indefinitely, you’ll eventually have a product that has grown out of control. And that will upset a lot of more of your user base.”

—Julie Hyman, Senior Product Manager, Quest Software

In this post, we’ll discuss why you might need to stop supporting certain functionality in your products or remove those features altogether. We’ll also review a few common conditions that signal it’s time to do so.

3 Reasons You Shouldn’t Keep All Product Functionality Forever

1. Too much functionality undermines the existing product.

Think of the challenges people face living in a cluttered home. It takes a lot of time and effort to keep all of the items clean and organized. The clutter itself makes moving around the home more difficult.

Too much product functionality creates a similar set of problems. If a product team has to devote resources to maintain and test a great deal of functionality, that will slow down the company’s ability to update the product and release newer versions.

Also, too much functionality can make the user experience slower, less intuitive, and more frustrating. Especially compared to a product where the company periodically pulled outdated or unpopular features. Think about how much control-panel real estate would need to be devoted to a car that offered all the music-playing options ever available. Imagine how poor the user experience would be trying to navigate among all of them.

2. You’ll be diverting resources from improving your product.

The resources needed to maintain all a product’s functionality forever can compromise the team’s ability to look forward.

A team overseeing a successful product will always be engaged in a difficult balancing act. On one side of the fulcrum, the team will have to figure out the level of time and resources needed to support the existing product. The aspects of the product that its persona finds valuable. On the other side, the team will be monitoring product data and customer feedback. They will be busy studying the competitive landscape and weighing competing strategies to improve the product over time.

The team’s extent to support old functionality will undermine the product’s innovation and strategic improvement.

3. Your team will be less comfortable innovating and trying new things.

If your company has the mindset that any new functionality added to the product will be there forever, that could make your team less likely to innovate. They’ll know that even a relatively unpopular feature will be a part of the product indefinitely. IT will demand resources for support, maintenance, and testing, presumably forever.

This is why a product team should develop a culture that favors experimenting and testing, especially to understand that if a new functionality fails to resonate with users, the team will pull it from the product.

3 Signs It’s Time to Remove Product Functionality

We’ve reviewed some of the key reasons that you’ll want to prune your product of its little-used and outdated functionality periodically. Now let’s go over a few common signals that indicate it’s time to pull something from your product.

1. The market is moving on.

One common signal is that the industry itself is phasing out that functionality.

For example, most mobile apps don’t offer a version for the Blackberry operating system. The market has moved away from Blackberry in favor of Apple, Android, and Microsoft devices. For a company making business apps, it no longer makes sense to devote the resources required to support a Blackberry version of their apps.

On the hardware side, consider how few consumer-electronics makers still include charging ports on their devices that accommodate the old, pre-lightning Apple chargers. Those electronics companies recognized that the market was moving away from those old chargers. They decided to remove them from their own products.

One final example is Microsoft announcing a path to stop supporting Windows 7. Like Apple’s charging plugs, here, the vendor itself is phasing out a platform that was once popular. But the company has replaced it with something new. If your product supports Windows 7, it’s time to phase out that platform for your product as well.

The good news: This will free up resources, budget, and energy for your team to focus on more forward-looking product plans.

2. Usage data tells you the functionality isn’t resonating.

Another signal includes your product analytics review indicating that customers aren’t showing interest in the function.

It would help if you kept in mind that someone out there will always use a given feature in your app. A few people find something useful in your product does not mean your team should continue supporting that functionality. You’ll need to determine user interest level in a feature that you believe makes that feature strategically worth maintaining in the product.

For example, if fewer than 5%, or 3%, of your customer base uses a given piece of functionality, you’ll determine it makes more sense to redirect the resources maintaining that feature. But wherever you decide to draw this line, you’ll want to ask the following question:

Is this really a functionality problem, or is it a UX problem?

Before you remove product functionality, you’ll want to ensure that the failure rests with the functionality itself. That it’s not a problem with where you’ve placed it in the product. Nor how difficult it is for users to access it.

There are a couple of ways to uncover the truth here:

Conduct a survey.

Put the question directly to your users. Let them know you’re thinking about removing the feature and ask their opinion about it.

You might discover that your user-data analysis was correct: Customers didn’t find the functionality useful or worth their time. You might also learn that the feature wasn’t connecting with users because users didn’t realize it was there or found it too much effort to access.

Change the feature’s placement in the product.

You can also tweak the product’s layout—possibly just for a small subset of your user base—making the feature in question more prominent.

If more users are exposed to the feature, will more of them use it? If so, the problem might never have been that the functionality wasn’t valuable; instead, it was hidden.

3. Your company is shifting to a different persona or market.

A final signal it’s time to remove certain product functionality will be that your product team is moving away from the product’s original persona, use case, or market.

For example, maybe you’ve been offering a freeware version of the SaaS app you designed for small and mid-sized businesses. Your team’s original thinking was that building brand awareness. That market share was worth delaying revenue because the app users would eventually become your paid version champions within their companies.

But today, you are switching your focus to a new market segment: large enterprises. Your buyer persona now will be a mid-level manager or department head at a big corporation. Your marketing strategy and value proposition for this persona will differ from the plan you rolled out for the small-business user.

So, at this point, you see no reason to continue supporting a freeware version. It’s time to remove that from your product offering—and move those resources onto projects that will help you successfully break into the large-enterprise market.