Treat Feature Requests With Skepticism
A lot of companies are starting to use what I like to call a “direct democracy” approach to product development. Services like UserVoice let users “vote up” features that they want to see implemented in a product. The idea is that a developer can then use this as the basis for future development.
I don’t have any problem with these systems per se but it does concern me when companies rely on them too heavily. I was speaking with one of our vendors this week about a problem we were having with their system. He instantly went to their feature request database to see how many votes the feature improvement had so he could tell me when it would get done.
What?
They were basing what they were going to do next on the voting of a small handful of users. This makes absolutely no sense to me. Maybe if you could guarantee that all current users and all potential users had voted in your poll then you might have some actionable data. But when you have a handful of users voting on features all you have is another bit of information which may or may not be valuable.
Direct democracy has never worked out well. Not in governments and not in businesses. I like Jason Fried’s quote about software development:
Think of yourself as a curator. You want to be a curator. You have to decide what comes in and what goes out. Curator’s job is to say no. Curator takes an entire universe of options to decide whether or not something makes it into a museum. If you think of your product as a museum and your features as art then you’re in charge. If you take all of the possible art and put it into a room it doesn’t make it a museum. All the art in the world in a single room isn’t a museum it’s a warehouse.
Customer feature requests should inform your decisions, but not dictate them. Some developers think they are doing their customers a favor or that they are creating a better product letting their users drive their development decisions.
Our Approach To Feature Requests
We have found it helpful to treat every feature request with a large degree of skepticism. The main advantage our product, ScreenSteps, has over other software documentation applications is that it is easier to use. If we add in every feature request we receive then we would quickly lose the advantage of simplicity.
We like to take the following approach to feature requests:
1. Don’t take the feature request at face value.
The customer may be asking for a feature, but what they really want to do is accomplish a task. In their mind they have determined the best way to accomplish a task and have requested a feature that would help them do that. They may be right. They may be wrong. But we want to understand what they are trying to accomplish with the feature request, not just what feature they want implemented.
