Deleting Features: Which Ones, How And When?
Product upgrades bring new and (hopefully) better things. Perhaps some of the old things can be deleted, but which ones? Nick Bradbury’s recent blog article helps put this interesting dilemma into focus.
The article, Killing Features, describes some of the challenges of maintaining simplicity and ease of use while adding new functionality, and an approach in executing changes after deciding what goes and what stays.
I suspect most product developers have similar thoughts, perhaps not articulated as well. I also suspect that, like me, they have three fears to overcome: 1) of deleting the wrong ones and alienating existing customers; 2) not having any facts on which to justify feature deletion; and 3) making any change that would be a glaring red, blinking neon light. Calls to mind the first lesson auto mechanics learn: Never change the customer’s radio station presets.
We started surveying existing customers about what they would like to see in product updates, but the response has been light, so the first risk is very real.
We also don’t know which features are really used, either absolutely or relative to others. That has led us to look at the possibility of instrumenting the action events, which we believe requires a buy-in by the customer, both during the installation process, and again whenever the numbers are sent back. Unfortunately, this may not be too helpful, because any feature will almost always be used by someone. I’m also not sure that having an application ‘learn’ a customer’s functional preferences is something to examine in depth, given their poor acceptance in many of the other applications from, say, Microsoft. So we don’t have a clean way to address the second risk.
The third risk affects the look and feel, and is one we have to take anyway, regardless of what else we may or may not change. The best we can do is to endeavor making the impact minimal.
I’m pretty sure that adding new features without somehow weeding out old and seldom used ones ultimately leads to really ugly complexity. How to accomplish that is, again, a dilemma that has no clear cut solution.