How to reject Feature Requests?


16

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."
So how do you deal with this problem without pissing your users off. I want them to keep sending feature requests even though we reject some (or most ) of them.

Or shall we just not request any feature?

Development Features Customer Support CRM

asked Dec 26 '09 at 03:12
Blank
The Dictator
2,305 points
  • Why are you encouraging feedback with things like uservoice if you have no plans to implement the suggestions? – Tim J 14 years ago
  • Yes we do (we do implement some suggestions, just not all of them) – The Dictator 14 years ago
  • OK, I misunderstood then. I would just be honest. – Tim J 14 years ago

11 Answers


14

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.)

answered Dec 26 '09 at 04:44
Blank
Elie
4,692 points
  • +1 I'm all for gauging the community to help in some prioritizing, or at least get their feedback. Good idea. – Matt 14 years ago
  • Great point on making sure the poll is to prioritize feature requests. Otherwise, they want them all. – Jeff O 14 years ago
  • We use polls at Smart Bear and it's really effective, however you do NOT want to say that just because something is voted up it will automatically be implemented. – Jason 14 years ago
  • Fair enough, but that was my point with your veto system - you can make sure that those items that you really won't do don't even make the list. But you have to make sure that you exercise that veto power on the rare occasion. – Elie 14 years ago
  • This is what we're looking to do for our site, we have a core set of functionality, and a slew of features that I'd like to see, but as my thoughts aren't as important as potential user requirements, we're having an open feature request, polling, and discussion functionality. Hope it works out! – Adam 13 years ago

13

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.

answered Dec 26 '09 at 03:39
Blank
Oleg Barshay
2,091 points
  • What will your response be when they push for a time-line? Ask for more feedback if you are sincere, but say no when you mean it. – Jeff O 14 years ago
  • As a general policy, I try not to commit to deadlines unless the customer is paying me for the feature they are requesting. If I gauge it to be a legitimate business need and they are pressing for it and especially if they are willing to pay for my time, I can certainly change my mind about not implementing a requested feature. – Oleg Barshay 14 years ago
  • Right, just say you never commit to deadlines for anything as a general company policy. You can say that deadlines only lead to missed expectations. – Jason 14 years ago
  • I really dislike this approach, its big company mentality, it makes customers feel like they make no difference. I think you gain respect by saying no sometimes. – Sam Saffron 14 years ago
  • @Sam Very often at the time of the request I really don't know whether I will be implementing that feature. In my experience saying no to a customer or arguing about their needs alienates them more than perceived ambiguity. Sometimes I do say no but most of the time I try to understand the reason for the request and how implementing it may enhance their business. – Oleg Barshay 14 years ago

8

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.

answered Dec 26 '09 at 05:29
Blank
Tim J
8,346 points
  • API's are a strong indicator that a software vendor is serious about long-term usage of their application. Platforms are much more useful than rigid applications. – Jeff O 14 years ago
  • Lots of things wrong with being honest. In this case they won't send any more feature request and maybe they won't be happy. There you go 2 wrong things for you. – The Dictator 14 years ago
  • I'd rather be honest than the alternative. As a customer I would not want to be strung along. That is not a good way to treat your customers. I can't believe someone just wrote "Lots of things wrong with being honest" – Tim J 14 years ago
  • +1 on Tim. IMHO completely the wrong attitude. You can easily alleviate your fears about the API. For example, require registration to use the API so you can talk to them abot their experience and needs. – Jason 14 years ago
  • Settings expectations correctly is a very good point, thanks. "Note that in many cases these feature requests might not translate into sales when they are done." What's your data about this? What I see everyone says feature sells and backup that with hard evidence. – The Dictator 14 years ago

7

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.
answered Dec 29 '09 at 15:14
Blank
Sam Saffron
432 points
  • +1 because the links are to a system where Sam demonstrates how an actual community reacts when you flat out tell them you are denying requests or accepting them – Frederick Cook 14 years ago

6

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.

answered Dec 27 '09 at 04:56
Blank
Jason
16,231 points

2

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

answered Sep 26 '10 at 09:47
Blank
Bigown
331 points

2

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?

answered Dec 26 '09 at 05:33
Blank
Jeff O
6,169 points
  • One of the benefits of being open/transparent is your users will see just how many good ideas are suggested and it becomes clear, without you having to say, that you can't do everything. – Dane 14 years ago

1

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.

answered Dec 27 '09 at 21:06
Blank
James Black
2,642 points

0

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.

answered Feb 21 '10 at 14:00
Blank
Gary E
12,510 points

0

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...

answered Jul 12 '10 at 00:39
Blank
Dean Hamton
112 points

0

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.

answered Dec 28 '09 at 01:14
Blank
Jarie Bolander
11,421 points

Your Answer

  • Bold
  • Italic
  • • Bullets
  • 1. Numbers
  • Quote
Not the answer you're looking for? Ask your own question or browse other questions in these topics:

Development Features Customer Support CRM