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