How to reject Feature Requests?

How do you reject feature requests nicely especially when the feature request is made publicly via twitter, uservoice or something like ideastorm?

For us general reasons to reject are:

• It's going to take ages to implement and doesn't really worth it
• We got more important tasks before that
• Not going to benefit many users
• It's going to complicate the GUI / usage of the application

I'm big fan of being transparent to the users but I'm afraid that it's not easy to tell them

"Sorry that feature sounds nice but
with our limited resources we can't be
bothered to implement it right now,
maybe next year."

Or shall we just not request any feature?

How about taking "official" notice of the suggestions, and putting up polls to see which features to implement that aren't on your priority list. You're constantly making changes, so why don't you balance some of the ones you want to make with some of the ones your users want.

For example, let's say that your users are asking for 5 things, none of which are currently on your agenda to add to your product. Put up a poll on your site (which you tell the users about) and say that the item voted to the top at the end of the month will be added to your priority list. That way, the users feel like they are able to put in requests, you can continue your development, and each month, you add one feature to your product that you might not have chosen, but your users want. (Plus, you have control over what gets added to the poll, so if some idea really doesn't fit with your site, you can veto it immediately.)

There is no need to outright say "no" although I have done that on a rare occasion. You can simply say "Thank you for your feedback! We will take your suggestion under consideration."

It's not like you immediately implement every feature suggestion that comes your way and users understand that. Also, if appropriate, asking questions about why they need a feature even if you don't intend to implement it sometimes provides an insight into how customers use your product.

What's wrong with just being honest?

The next step is to do the "plug-in" or API route - so that people who want to customize can do so, but you can keep your core functionality minimal.

(ala Fogbugz 7)

EDIT:

I understand you are concerned about potential customers being turned off by an apparent snubbing of their feature request. Note that in many cases these feature requests might not translate into sales when they are done. There might be no correlation.

Feedback is great - especially when you hear repeats of the same item. Your question though gave a purposely poor example of a response to a customer request.

You can be honest and say you are still working on core functionality and your goal is to keep the main product simple to use, clean, etc and you are still working on the core.

Be sure to thank all your responders and let them know you appreciate their time and their suggestions and even go so far as to say what you like about the suggestion. You can give a reason that you are declining the suggestion.

Also, int he automatic emails for the feedback, or on the forums that solicit feedback you should have a few sentences that highlights your policy and tells the customers right up front that you value feedback but because of certain things like time, limited resources and other priorities that you might not be able to meet their request. You need to set expectations BEFORE they send it.

My system is:

• Be transparent about the list of features that were declined and similarly be transparent about the list of features that were completed.
• I am very careful when declining any items that have a lot of community support (which I measure with a wish count)
• Its always better for the community to decline a feature request, which on my system is done with voting or a comment. I still have the last say, but its much easier to say no, when lots of people agree its a bad / non-viable idea.
• If I make a mistake and decline something that really has tons of community pull I am likely to get quite a few downvotes which will alert me to the fact.
• Whenever I decline something I will always explain my reasoning in a short note. This avoids getting duplicate requests later on and helps reassure the customers (they do not want their feedback to simply go to the void)
• By rewarding people (with reputation or a thank you) for good feature requests I keep them coming back for more.

You can be like 37signals and Apple and just ignore everything people say, then state publically that you ignore everything people say, and then people will love you all the more for being strong and opinionated.

Only slightly joking...

Seriously, you don't need to justify. You just keep them in the fold. When you do decide to do something someone wants, make a big deal out of that.

Call this request "Customization" and ask for high value. Customer will forget or give you a big profit.

Let them know that you thought about it and state the reasons why it is not a fit. Other users may agree/disagree and provide feedback to improve the request to the point where you may want to use it. Being open does not mean that you have to implement every request; nor should it be a user expectation (Get rid of them early.).

We also never consider user who may not want a new feature. Everyone needs to be aware of the impact of a new feature. Will it make the system slower? Does it complicate a current process?

I think the idea of having users vote on what features they would like to see is great, as, you may have a particular vision of your application, but, if you add certain hard-to-do features you may get more customers then that would be helpful to everyone.

If you want suggestions, but don't expect to implement most of them, then you may want to state that you are open to ideas, but you will decide which to use.

If you get certain requests that you won't/can't implement, I would suggest you start some sort of FAQ where you explain why you are not going to be implementing a certain idea, but be very tactful. This will help to prevent too many repeats, and may spark discussions as to your rationale.

You could start a roadmap, to show where you will be going in the next two or three updates, to help the users see where you are trying to go, and they can give suggestions that are more inline with your expected changes.

But, if you want to force your vision, and ignore any ideas that are not inline with what you are envisioning, then I expect you should stop accepting requests, or be very clear about your vision and the fact that you don't want to deviate from that.

Personally, I would find that attitude troubling. Once you release software, I expect that the users should be helping to steer the future of the product, and you may find that it is being used in ways you didn't expect.

For example, Java was initially expected to be used in embedded systems. But, that didn't work, but it was popular with applets for a while, and then it continued to grow, and the users have helped to shape the direction that Java has taken.

If you look at Autocad, Autodesk has done a fantastic job of listening to customers, and they seem to adopt ideas even if it wasn't something they envisioned, at least from what I have seen by observing people that used the software often.

It is easy to deal with this problem without pissing your customers off. Be polite and truthful!!! Thank them for their generous ideas. Let them know you will consider this idea in a future update. If they press for a time line politely tell them you don't know when or if it will be implemented.

Remember that customer's ideas for your software may not be reasonable or in line with your idea for the future of your software product. Politely thanking them keeps your public relations on a positive track. What you actually do with their suggestion is up to you and their demands to know what is happening are unreasonable. Politely decline to be part of this debate.

If they desperately want this feature/update and are willing to pay for its development that is another matter.

You should be keeping a list of possible updates or features and anything mentioned should go on to that list. You never know how some suggestion you rjected last year will fit into next yearsupdates.

I am a big fan of voting. Since customers can take the business into a direction that you never thought of. I am in the same situation and we are building something, but depending on users we grow in a specific direction. The core thoughts are mine (about usability, commercial value, resources and open/closeness of platform).

So vote, accept and decline overview is the best for me.

On the other hand I read something related to this on 37signals. They recommend FORGET THE REQUESTS! its an interesting article...

You have an interesting dilemma. On the one hand, you want your customers to tell you the features they want and maybe even need. On the other, you don't want to implement these features since most are probably bad ideas or take up too much resources for not enough sales gain.

I think we all agree that customer feedback is valuable and should be given it's due respect but that building all those whacky requests just makes no sense.

Maybe the approach you should take is to say that features new features are determined at predetermined intervals via your user community. Maybe hold a user community forum where all of these feature requests are discussed and the group (via a peer conference model) decides what features the next release should have.

You can clearly have veto power but if you got a dozen or so users together and they came up with the list, that would show:

1. You care about your customers
2. You prioritize based on real community need.

I can't think of an example of a company doing this. Maybe the Autodesk guys that James mentioned.