I have already touched on this subject in the Art of Ignoring, explaining that you should be careful implementing features based on only a small number of requests.
But there’s more to it. Here’s my full story on handling feature requests.

When dealing with many users suggesting all kinds of different features, big ones and small ones, there’s two things you need to decide on:

• Which ones to implement
• How to implement them

Which ones to implement?

Sales
For each feature, you should always consider: Will adding this feature actually result in more sales? Either by attracting more new customers, by convincing more of your existing customers to upgrade to your new version or, more indirectly, by making users happier and thus more likely to tell their friends about your software.
If none of the above applies, then you may be better off not implementing a particular feature. Less is more.

Statistics
Features that are requested more frequently are important to more of your users, so should receive a higher priority. That is, if they make sense, which is for you to decide. Only implement stuff that fits the direction in which you want to take your software.

Of course, you need a sufficient number of requests to decide. Don’t just pick one feature with 3 requests over one that got “only” 2 requests. Not getting enough feedback to make your decision purely on the number of requests? Then I’m afraid that you will have to guess. Pick the features that you think will be appreciated by the largest number of users.

Beware of the “vocal minority”
All users are not created equal. If all requests for a particular feature are coming from a small, but vocal sub-group of your users, then beware. These users may not be representative for the rest of your audience, so implementing that feature may not be as important as it seems to be.
At Collectorz.com, the features that are requested on our forum are completely different from the ones we are getting by email. We have found that the typical forum user, often advanced and tech-savvy, is different from the average Collectorz.com user. So we have to take that into account when “counting” the number of times a feature is requested. However, I must say that the forum has also been the best source for wild, out-of-the-box feature ideas…

Beware of helpful users
When users suggest a particular feature, always make sure they actually want or need that feature themselves. In an attempt to help you, some users tend to make up features they think other users will like. Or they suggest functionality just because one of your competitors has it. Which by itself is never a good reason to implement a feature.
This is a common effect when you explicitly ask users for feedback. My experience is that the best feature requests are unsolicited, resulting from a user’s personal experience with your software.

Hidden feature requests
The best feature requests are not only unsolicited, but may not even be stated as a feature request. They may be disguised as a frequently asked question, or a common complaint. Read between the lines of your customer support emails. There will be loads of hidden “feature requests”, e.g. questions about how to accomplish a tricky task or complaints about some actions being too cumbersome, users being frustrated trying to understand your user interface.
Frustration is a major conversion killer, so implementing functionality to take away this frustration may be more important than programming your number one feature request.

Which features can you think of yourself?
Finally, don’t just rely on your users to think of new features to add. Often you can think of more important features yourself.
Users only tend to think in terms of small changes or additions to existing functionality. Whereas you can (and should) take a step back, think out-of-the-box and come up with completely new functionality. Stuff that your users may never have considered even possible.

How to implement them?

Solve the actual problem
Don’t just implement the feature that was requested. For every feature request, try to get to the story behind it. Try to find out what the actual problem is, then solve that problem. You may be able to come up with a better solution than the one the user was suggesting.

Don’t let users design your UI
Don’t just implement the feature exactly as it was requested. Your users are not user interface designers. Build the functionality they requested, but design your own interface for it, a user interface that makes sense, is understandable and consistent with the rest of your program.

Go broad
Feature requests are often very specific, solving a special problem that particular user is having. But with your implementation, you may be able to go broader, create a more generic solution that solves many similar problems. And thus make more people happy.
An example from the cataloging world: if a user requests being able to sort collection lists on the Title field, in both ascending in descending order, why not go all the way and immediately allow this for any field?

Go deep
The implementation of one requested feature is likely to trigger the next one. Can you predict what your users will request next, after you release your long awaited new version? Then why not get it over with now. Go deep and immediately add all related functionality that you can expect to be requested.

Beware of feature creep

I hope the above will help you decide which features to implement and how to implement them. But whatever you do, remember it is your software and that you are the one who is responsible for making a quality product. Listen to your users and use their ideas to improve your software, but don’t let them dictate your priorities.