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.

By talking to our customers we almost always come up with improvements that are:

• Easier to program than what the customer suggested
• Easier for our customers in general to use than what the customer suggested

By finding out what the customer really wants to do we can make a better decision about whether or not to implement the feature request.

2. Decide if this is something our software should do.

Now that we understand what the customer is trying to accomplish we need to decide if that task is something our software should be designed to accomplish. A software application can’t be all things to all people. This is probably the most difficult decision to make. On one hand you need to be flexible in your product vision because your customer may be introducing you to a new market that would readily accept the new functionality and improve your business. But on the other hand you don’t want to get distracted from what your overall product vision is.

Every developer has to weigh the pros and cons of the feature addition at this stage but trying to be all things to all people will quickly make you worthless to everyone.

3. Decide if this is something our software can do.

If we decide that it is a feature that we want to support then we next need to decide if it is something we can reasonably implement given our current resources. If it is then we will add it to our short term queue. If it isn’t then we put it on the back burner for a later date when we have things in place that will allow us to implement it.

Direct Democracy Doesn’t Work

Direct democracies don’t work anywhere. Organizations, businesses and products need leaders. If you are allowing users to vote on features, use that information to inform your decisions, but don’t let you users make your decisions for you. You’ll both end up being unhappy with the results.