Suggestions for Making Feature Requests
Garrett Dimon on April 7, 2009
If there's anything about Sifter that I have a love-hate relationship with, it's managing feature requests. On one hand, feature requests and customer feedback are the most valuable ways of understanding where we should steer the ship, and the people that take the time to share are priceless. On the other hand, some people request features with the entitlement of spoiled children who have never heard the word "no" in their lives.
This isn't based simply on my experience with Sifter. It's based on behavior that is visible everywhere. Whether it's software or hardware, there seems to be a limitless supply of baseless negativity from some people when the product is missing their pet feature. Instead of opening a dialogue with the creator, they just unilaterally dismiss it or create a condescending or indignant feature request. For everyone's sake, we can do better. (Note: Support requests are entirely different from feature requests.)
Making New Feature Requests
Nobody's perfect, and I'm sure that over the years I've been as guilty of the following things as the next person. However, I've learned a lot over the course of the last year developing Sifter, and it seemed it was about time to share that experience. For the most part, you might think that these are obvious common courtesies, but you would be wrong.
- Make a suggestion, not a demand. This doesn't just apply to feature requests. If you approach any situation with a demand, you're starting off on the wrong foot. It's a called a feature request not a feature demand.
- Recognize that the developer is balancing many requests. As of writing this post, Sifter has almost 4,000 users. That's not much in the grand scheme of things, but it's enough that I've learned that not everyone wants the same thing. Fulfilling your request may only make you happy at the expense of other customers. It's a balancing act, and while every suggestion and request is important, yours is rarely the only one that the developer has to consider.
- Remember that there are humans behind the software. Any feature request you make is going to a human being, and it's more than likely that the people behind the software care deeply about making it the best that it can be. Assume that they do care and they do have the best long-term intentions in mind. Talking to them as if you feel they are actively sabotaging their product doesn't help make a case. Be friendly and civil.
- Don't tell them how to run their business. Focus on your need, not their revenue. Telling a developer that a feature would "clearly lead to more customers" or that they're "missing out on additional revenue" is way oversimplifying. With each new feature, there's just as much potential for downside as their is for upside. In fact, if you feel that it's necessary to tell them that, thinking they aren't aware of the business implications, you might as well just open the request with, "I think you're incompetent." I can't speak for everyone, but that's never worked well for me.
- Assume that your request is incredibly complex. Just because you're familiar with the technology or platform doesn't mean that you know the application inside and out. Every product is unique, and only the developers will know the full impact of a new feature. Hell, sometimes even the developers don't see a significant portion of the complexity until they're halfway into implementation.
- Be constructive. Talk with them, not at them. Acting indignant or condescending about a feature that is "missing" because "XYZ Software has it" makes for a poor discussion. Now, referencing another application and saying, "Hey, I really like how they did this because _______. Is there any way you could offer something similar?" expresses the same thing, but accomplishes much more.
- Details matter. Just because your feature request is one word, doesn't mean the solution is simple. In fact, the less information you provide, the more room you leave for misinterpretation. Mention specifics and do your best to provide clarification and details about your needs. The more information you provide, the happier you will be with the result. It also shows that you care and aren't just firing off a half-baked whimsical request.
- Talk about your problem or goal instead of prescribing a solution. There's nothing wrong with suggesting a solution, but it's much more valuable to the developer if you describe the problem you're encountering or the goal you would like to accomplish. Understanding your behavior and usage of the system is a priceless component for helping the developer help you.
- Offer alternatives and keep an open-mind. If you want to request a feature, suggest multiple implementation options that could solve your problem. By thinking through other options, you'll invariably be able to come up with a better solution, and you'll help the developer gain some additional insight into your needs.
- Participate. If you really care about a feature request, the best way to make your case is to invest some time in it. Do a little research. Maybe mock it up. If the company has public forums, see if anyone else has made a request. See if the developer has shared any information about their decision to exclude that feature or if it's something that they've openly stated is in the works. If they don't say yes right away, and you care, continue the discussion. If you don't care enough to do more than fire off a one-sentence feature request, you're not making much of a case, and it probably won't go far.
That's probably not an exhaustive list, but those are things that come to mind. The list is based on the hundreds of requests I've read since launching Sifter as well as the hundreds of comments I've read on other developers' blogs and forums over the years.
It's important to remember that just because you've eloquently made your case and presented a flawless solution to your problem doesn't mean that it will make it into the application. Any software company still has a philosophy and vision that will influence their decision to include, exclude, or delay a feature. It doesn't mean you were wrong or that your input and feedback was any less valuable. It just means they have a diferent vision. However, that's a topic for another day.
Summary
Whether we all realize it or not, receiving user feedback is one of the most important aspects of software development. The day that people stop caring enough to share their thoughts is the day that your software has become irrelevant. However, ill-conceived, rude, or otherwise poorly worded feature requests really take the joy out of pleasing people. (Remember, these are feature requests, not support requests.) Instead of feeling like you're granting their wishes and making them happy, it feels like you're merely mitigating their misery. I think it's safe to say we'd rather spend our time granting wishes.
Comments
Great post. I struggle with the feature requests all the time in my project. And I would be very happy, if my users knew about this list. Thank you.
Garrett
Thanks for another insightful post. I'm currently developing my own bit of desktop software which I'm hoping to be in Beta by Christmas. This post means I'm a bit more prepared for the onslaught of people telling me that my product is rubbish because it doesn't do X.
In the past I've tended to overly focus on my mistakes, and I can see there would be a strong temptation for me to take things customers said personally. The more posts like this I read, the more I'll be able to see the wood for the trees when I'm engaged with difficult customers.
On a final note, although I can't afford to run Sifter just yet, I love what you've done with it and as soon as my business is making some money, I'll be seriously considering switching to it for my bug tracking, as I love elegant, well designed tools that aren't crammed with features I don't need.
Don't get me wrong. I really don't see them as difficult customers, because I've very rarely had anyone continue to be pessimistic after I've replied to their initial request. However, those initial requests sometimes make it really difficult to stay upbeat.
Ultimately, it's all worth it, and I wouldn't trade it for the world, but as in anything, we could all stand to grow a little and be more thoughtful when making feature requests.
This is a great post, Garrett.
In my experience, thre is one other really important thing (which, granted, probably falls outside of the scope of your list): developer's response.
The best way to get good feedback from your users is to respond diligently and thoroughly to every incoming communication. Users are much more likely to be understanding of delays in pushing out "essential features" if they know that they can email you and hear back from you on how things are going.
Just my $.02... Developers are almost (if not equally) as responsible as users for facilitating good, open communications.
Hear, Hear! Really well put.
As a friend of mine often says: "Don't ask a designer for a bridge; instead, show him the abyss you want to cross"
You're absolutely right. The topic of developer responses could (and just might) be a whole other post in and of itself.
Developer responses should be taken very crucial, independently from the fact that not every single request can be responded due to the huge amount of requests.
but i believe not responding to useres lead more people to rant about a software if feature requests XY from year 2005 wasn't implemented in the major release B nor in release C, never mind if the request are posted several times in to forum wishlists or not.
just giving the users a little feedback about the possibilities or drawbacks of a (missing) feature, especially a feature which has been requested by many people.
The Photoshop blog by John Nack is a beautiful example how this can be achieved and still leaving room for discussion with the user about how new features will work or not, and flaws could be eliminated much better trough the community.
After Effects is is in my opinion a bad example on how the future of the software will be accomplished. It definetly lacks from that information.
However, i still have to admit that anything at Adobe regarding to infomation about development roads is far better than at Apple.
I think there's some great advice in this post. Once being a product manager for Adobe myself, I wrote up some information on what is and what isn't helpful feedback for developers in a post: http://rwillustrator.blogspot.com/2008/09/dear-adobe-quest-for-perfect-feature.html