When developing products, especially in the early stages, we need a similar revolution. Most products quickly get too many underused features that stick around way too long. It is emotional to get rid of stuff and you often face resistance, but it is worth it.

Why do early products end up with too many features?
‍Reid Hoffman famously said that “If you are not embarrassed by the first version of your product, you've launched too late”. Anyone who has pushed out an MVP knows this feeling well. You are on the one hand proud of what you have made so far, but have a go-to list of things that are necessary to add as soon as possible. If you are talking to a lot of users, running experiments, and doubling down on building a product that the market wants, then your first vision for the product is likely far from where you are today. And you’ve been quickly adding features along the way that are not compelling your users to take the actions you want them to take.Whether you are 3 months, 2 years, or 4 years into developing your product, you likely still are missing key features and are a bit embarrassed by at least part of the product. However, you also have too many features that aren’t adding value. They need to go!

Why you should prioritize this
‍Users think less about your product, care less about it, and understand how to use it much less than you wish. Those features that are only used by a few people add moments of friction for everyone else. They are more likely to be annoyed by what they accidentally clicked on than it exciting them. The best products do something extremely well and limit everything else. Removing underused features makes it easier for users to focus on the core product.

A cluttered product is tough to maintain and slows down the pace of development. You need to consider how new things will interact with these legacy features, fix any unexpected dependencies within the code, and continuously QA the features to make sure nothing has broken. Each individual feature may seem like it is not affecting much, but it adds up. Would you rather a new product initiative come out earlier with less bugs without this dead weight, or later at a lower quality?

Why is this hard to do?
‍Deprecating unused features will initially be unpopular and you will likely get push back from a lot of stakeholders. You are using up political capital and potentially offending teammates without a clear outcome. It is much easier not to do, but pays off over time.

Your team put your hearts and souls into creating these features and at the time believed that it was the right thing to build. You need to emphasize that you aren’t saying it should not have been built or that it was built poorly. Instead, you are pointing to comprehensive data that shows this feature is not performing in a way that is adding value to today’s product. You have different information than you did when it was built which is why you are making this decision.

Your team also likely uses the product differently than a typical user. There was a contextual learning feature that several people on the team loved at Realworld. That was one of their favorite and most used features. However, less than 1% of our users ever interacted with it and the majority of those only saw it once. The idea of contextual learning was really valuable, but this implementation wasn’t working. By getting rid of it, we had the opportunity to reimagine it so that more users would get the value.

Top Tips
‍• Removing unused features should be on your roadmap every quarter! Do a shortened sprint with it after a large project for your engineers to reset and reenergize
• Set a clear criteria for when you would consider deprecating a feature. I start with getting a list of all features that less than 5% of users interacted with in the last 60 days. That doesn’t mean that you will automatically get rid of it. However, you should have a strong case for why you are keeping it if it makes that list
• Communication is really important here. Be specific about the lack of engagement, emphasize how this helps the user experience, point out how this will improve developer experience, and mention that you are open to exploring adding similar features in the future if they are aligned with business needs
• This gets easier over time. If you do this consistently, stakeholders will push back less and start to see the benefits of an uncluttered product