“A customer requests a feature you’re never going to add (doesn’t fit with product, won’t increase sales, whatever). How do you respond?”
This came in from the super-talented and brilliant product mind of Leah Culver. It’s a specific question—but one that comes up over and over again for community and support folks.
I think there are a few rules of thumb to apply when responding.
First, anyone communicating with your users should be on the same page for these responses.
Support, community, marketing, PR and product managers should all have generally the same response in these situations. I’ve found a great way to accomplish this is to have an internal FAQ, which includes major feature requests, as well as a document covering voice and tone. This keeps your team’s external message consistent. You never know when a support ticket gets added to a blog post with a gazillion readers.
Second, never say never.
There are countless times I’ve told a user, or bunch of users, that a feature is never going to happen, and six months later someone changes her mind and it gets prioritized. (Likewise, never promise anything not already tested and ready to ship.)
Finally, make sure you fully get what they are trying to accomplish with their request and why.
Find out what problem they are trying to solve. This ensures they feel listened to and understood. It also gives you further perspective and product feedback. And ultimately in saying no, you still want to help solve their problem.
So how to respond to people requesting extremely unlikely features? There are a few techniques to letting people down gently when denying their requests:
Offer a workaround.
People want to embed your product somewhere it’s not supported? Explain how to take a screenshot and hotlink it.
Find an external tool that can integrate with your product.
They want you to add Facebook comments to your blog product? Let them know they can integrate other comment products that allow Facebook sign-in.
Find an alternative product.
This is best for major features you are least likely to implement, or you think are years away. Let them know, “Hey, we might not be the right fit for you now, have you checked out other-product-A?”It may seem counterintuitive to send someone to a potential competitor, but ultimately that user will remember you taking care of them, and will be much more likely to give you another chance if the situation comes up.
There will be a small number of requests that fall into the “never gonna happen category—like rolling back a redesign, for example. In these cases, your best bet is to acknowledge their request, try to understand where it comes from, and set realistic expectations.
How have you handled saying “No” to a community member or customer?
Photo cred: gaptone via Compfight
I love meeting people working on community at startups. I work full time at about.me, am cofounder of Signal Camp and an advisor at Planwise. In my free time I love climbing, going to concerts and wine.
I think never say never is good advice. It’s also important to thank the person for taking the time to make the request (even if it is one you have heard before). The fact that people care enough about your product to want to make it better should be rewarded.
Deidre Such a great point! I love companies that come back and tell me if something has been added or changed too.
LOVE this post Laura.
 I think it’s extremely important to look at every piece of feedback that you get as a representation of a problem, not a literal problem in itself.  Try to understand WHY they’re asking for this feature.  Users usually don’t know what the solution to their problem is, they only know what their problem is.  YOU as the community manager need to work with the rest of your team to figure out that solution.
So when someone asks for a feature, it’s okay to let them know that the specific feature they’re asking for isn’t the best fit for the product that your team believes will offer the best experience. Â Then explain what you’re doing to solve their problem in a way that IS a good fit for your product.
Rock on.
I’ve found that it’s OK to say that something’s not the right fit or not being worked on now, many people will surprise you by thanking you for your honesty! But you definitely need to be on the right page with all customer-facing teams at your company because mixed-messages erode customer trust. Also, when people request things because that’s how they expect them to work, I try to turn it around and ask why they need it or how would they expect it to work or what the scenario is – most of the time this works fine and gets valuable information about what customers want, although sometimes it does backfire when they get a bit annoyed that you don’t know everything about how your industry works, how your competitors work etc. As Deidre says, it’s good to realize people have taken the time to let you know how the product can be better even though sometimes it’s hard to separate the passionate people from the trolling people!
Conversely, saying “yes” before a commitment is live is just as dangerous. In the software space, deadlines change all the time and what was supposed to be released in the next patch, gets moved or even deferred until a later time. Declaring a commitment too early — or without the right internal buy-in erodes the credibility that you’ve earned from users.Â
I think it’s acceptable to say “no” affirmatively to users. I’m gentle with it and provide rationale, but if you don’t have a backbone, no one will respect the decisions you (or your company) makes. We’ve said no to many things — in good faith — that we can say yes to the right ideas and suggestions that many users do want.
Never and always are perpetual commitments. I agree that you want to avoid those phrases where possible.
Some great tips. It’s interesting to read your point on saying “never”, for two reasons. One, I actually highly advocate saying “no” if you’re sure (http://community.uservoice.com/blog/say-no-to-customer-feedback/) but we’re also experimenting with a new status for UserVoice ideas: “deferred”. Basically saying: “Hey, we don’t think we’re going to build this but we’ll keep this here and let you know if we do.”
JoeManna Absolutely! When using statuses on our own feedback forum (feedback.uservoice.com/forums/1-general-feedback) we try to only update something to “started” if it’s actually being built at that moment, and never mark anything as “planned”. It’s all “planned”. 😉
I agree with your “no” point as well. People would rather KNOW than continue hoping forever.