How often do you remove features? Have you, ever?
How do you decide what to remove? Do you have a set of product management guidelines that help you achieve this in a consistent fashion?
I’m really not much of a gardener. I love green things, but in my off-time, I tend to gravitate toward spinning wrenches over grabbing a trowel. But there’s one thing I do know: Building software is a LOT like growing a garden or managing trees. And pruning is a key part of managing plants. It seems counter-intuitive, but cutting back dead or non-productive parts of a plant allows it to focus more energy on growth and fruit production.
The same is true for software. Many features get built that just don't get used much. That's not just 100% normal. In my opinion, it's a requirement. A company needs to experiment with new ideas! But not all of them will work. Even the best features can become redundant or irrelevant as the product matures or the company pivots.
This isn’t quite the same thing as “technical debt,” though it is obviously closely related. I tend to put this more in the realm of “product management overhead.” So often, we look at existing features as though they have no impact on our current or future endeavors. “There’s no harm in leaving it in there” is a phrase I’ve heard many time. Full disclosure: I've probably said it myself more than once.
But every feature and every line of code behind it imparts some overhead cost, whether it is used or not. The most obvious impact is seen in regression testing, where you test absolutely everything to make sure your new feature didn’t unexpectedly break something else. The more features, the higher cost to regression testing. Another obvious impact is when a bug is found in a feature that nobody uses anyway. Especially if it is a security-related bug, or a defect that causes data problems in places that people do use.
The cost appears in many other sneaky ways, too. It adds complexity to the system as a whole, resulting in ripple effects that slow down your ability to add new features. And it really rears its head when it is time to refactor or do a system-wide update to the code.
This is one of my favorite questions when I’m interviewing product managers. The best product managers know that complexity has a cost, even if they have no engineering background. Not only do existing features tend to weigh-down the speed of development of future features, but adding complexity tends to hurt the user experience, as well.
As you build your product roadmap, make sure you also have a plan for pruning the dead branches.
