There is 1 feature in your current product that you could take out today, without any negative consequence at all.
Taking it out will make maintenance and software evolution, technical debt, support, and probably even the user experience better. It will make your codebase more maintainable. It will make everyone happier. You added that feature because you thought it would make a difference, but it doesn’t.
In evolutionary terms, taking this feature out will increase fitness (or keep it fixed) while decreasing complexity.
That’s feature debt.
No product is so perfect, so optimized that all of its features are in perfect balance, all necessary, all required.
No digital product anyway. Here’s one that’s pretty close. But note:
- It’s very simple.
- It’s been optimized for centuries.
So let’s assume that there is 1 feature in your product that you could take out, with positive effects. Once we agree on that, it’s quite likely that there are more than 1 features that you could and should take out. There are features you should not take out, too. The more complex the product, the more features you should take out. Facebook surely has dozens of features that they could take out today, and the net effect would be positive. Google probably has hundreds. Windows has thousands.
There’s not a lot written about the art of taking things out once they’re launched. Taking things out during the “design process”, sure, but not after it’s launched.
Apple is famous for removing features from live products. They’re also famous for launching products with very few features, but that’s for a different post.
There are 2 kinds of features that you can take out: features that nobody uses, and features that some people like but that aren’t helping *you*.
Features that nobody uses are easy to take out. The hard part is to define “nobody”. Early on (first year or two), I like to go with 10% of my active users. If not even 10% of my active users are using this feature, we should probably kill it. You could do 20%.
It’s easy to know when nobody uses your feature. Track it. Once you use metrics to inform (not drive) your product decisions like this, you’ll never go back. But that’s another post as well.
Features that a significant amount of your users actually use and like are harder to take out. But if they’re not helping *you*, perhaps you should. These are often features that are attracting the wrong kinds of users, or encouraging the wrong kind of activity, or perhaps they just don’t fit with the direction you want to take the product in.
If you’ve never considered taking features out of a live product, try it. It engenders a whole different mindset. You’ll start asking, before even developing a feature: do we really need this? It will make you want to measure things. It will make you think more deeply about your product. It will be good for your team. That’s probably a rule for a good product team: takes features out of live products.
Notes:
- The debt metaphor comes from WardCunningham
- See also: You Aren’t Gonna Need It
- Decreasing complexity is good, because it speeds you up.
- Andrew Chen calls it product design debt.
- Architects call design debt “work that remains unfinished after a deadline”, which isn’t exactly the same concept.
Peter Van Dijck 