Killing features — just as important as building them
BY GRANT AMMONS
Retiring features is a critical part of product management. It takes guts and discipline to do it, but it is critically important to the overall health and success of your product.
If you let too many features creep into your product, the core value proposition and vision can easily get diluted. The product will start to seem “big” and “complex”, and does not easily solve the problem the customer had in the first place.
When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one would want our products. — Jason Fried
A product with lots of features does not make a great product. A great product is one that solves the customer’s problem in the simplest way possible. Great products deliver value, not features.
How to identify features to kill
If you work at a company with an established product, there will certainly be features that can and should be removed. Take a step back and evaluate every current feature of the application.
- Does this feature add to the core value proposition, and does it deepen your product/market fit? Could it potentially hinder you from adding other features that will deepen your product/market fit in the future?
- Does it fit within the rest of your product’s context?
- Does the feature have conceptual debt?
- Are the usage numbers good enough to justify the feature’s existence? Does it require more development cost to support than it makes?
- Does this feature present a liability to other, better features? Does it present a liability to the tech stack?
Features on the backlog need the same level of scrutiny, or higher. Any increase in the surface area of a product is a potential dilution of the value proposition and the overall experience.
Jeff Atwood had a great blog post entitled The Best Code is No Code At all. The same logic could be applied to features within an app. Are you sure you need all this stuff on your backlog? Will all of it make your product deliver more value?
The dilution effect is why maintaining a clear vision for your product is so important. Without a clear understanding of the limits and boundaries of your product, the product will morph into something you no longer recognize. Or worse, something you can no longer manage or control. — Jason Fried
Even if you’ve done your homework, done the customer interviews and market research, done the context analysis and are fully sold that adding this feature is indeed the right move, you still need to be cognizant that any added feature means added complexity, cognitive load, and dilution of the core value proposition. Any added features have the potential to remove the tightness, the focus, and the crispness of the product’s surface area.
Context
When evaluating new or current features in your product, placing each feature within the context of your overall offering is important.
If your product is a tree and your branches are its features, are there branches that look out of place? Is there a branch that is so large it’s making the rest of the tree lean towards it? If you step back and circle around the tree are there any branches that stick out like sore thumbs, ready to be pruned? Do all the branches feed back nicely into the trunk, which is your core value proposition?
The above analogy begs you to ask the following questions about your product: Does this feature integrate well with the rest of the features in our product? Does it clearly solve the customer’s problem, and does it deepen our value proposition?
Conceptual debt
Conceptual debt is when the concepts introduced in your app do not match up with your customers’ mental model of the problem. This can happen when you do not get enough customer feedback. You go ahead and ship what you think they need, rather than what they actually need.
Conceptual debt happens when you’ve made design choices that lead to an unintuitive product. The product is unintuitive because you’ve chosen the wrong way to model and represent the core concepts in your system. — Nicolae Rusan
If you’re demoing to a customer and it takes them a long time to understand a particular feature, or if you find yourself explaining a feature using many different approaches or analogies, then that is a good sign the feature’s concepts do not align with the customer’s problem model. Features with high conceptual debt tend to have low customer adoption rates.
Read Nicolae Rusan’s excellent article on conceptual debt. It’s worth your time.
Usage Numbers
Usage numbers should be the most clear indicator of feature failure. Ideally, every feature should have 100% adoption by customers. 100% adoption means every feature is amplifying your core value proposition.
This is never the case in reality. But, it should be your mindset when looking at what is being used in your app. The features that are closer to 100% adoption are the features that enhance your product’s core value prop. The features that are closer to 0% do not, and are a liability. The features whose adoption rates are abysmal are the dead branches of the tree. Sure, you will definitely get resistance from a few very vocal customers, but it’s better overall for the product as a whole.
Don’t let angry customers dictate your application design — the application isn’t as important to them as it is to you. Keeping your application healthy is your responsibility. — Lukas Mathis
The Tech Side
For every feature in your product, you have made a vow to support it, come hell or high water, for years. Your engineering team will need to own any scaling issues, tech stack issues, code refactors, bugs, security flaws, customer complaints. And, they will just need to keep the damn thing up and running. For years.
Whenever you build a new feature, you’re entering into a contract to keep that code up-to-date and compatible with all other features you’ll choose to add in the future. — Sandi MacPherson
Are you prepared to do enter that contract? Are you prepared to eat the opportunity cost of working on other, potentially more valuable features for maintaining your existing set of features, even if it is hard to justify the existence of those features?
The more features you have, the bigger team you will need to support all of them. Otherwise, you will end up with even more feature rot. As your team goes and builds new features, existing features will be neglected. You won’t be pushing them forward, responding to customers, and making them more successful. Sometimes features can be neglected for years! This type of “checking the box to ensure we have this feature” mentality is not one that will be successful, and is the opposite of a healthy, lean organization.
As your product grows in complexity, developing features on top of your existing feature set will also get more complex. You will start seeing institutional knowledge silos appearing, e.g. “Oh, Bob’s the only person who knows about our sharing feature. Go talk to him!”. What happens when those knowledge silos move on from your company?
If you don’t have enough engineering and product management to support all the features you created, your teams will start feeling thin, sort of stretched, like butter scraped over too much bread. You won’t have enough time or resources to make all of your features truly successful, and therefore none of them will be.
Kill that feature
It’s likely you already know what needs to be killed. Saw off those dead branches and pave the way to allow new growth to appear that truly enhances your product’s core value. And remember, your product’s value is not the number of features it has. It’s not about that one customer who threatened to leave if you don’t build feature X. Your product’s value is determined solely by if users perceive it to solve their problem.
Grant Ammons is focused on building better software products and engineering teams through fostering an amazing team culture, developing software smarter, and utilizing the right metrics. He has hired and currently manages multiple development teams, defined and matured the software development process, and built an infrastructure with three 9s of uptime.
