Feature requests often aren’t feature requests
How to look beyond how to implement a feature and find out why it was requested in the first place
Image credit: Flickr
Don’t fix a problem until you understand it
Feature requests are a great thing to gather & understand. They are the source of ideas and suggestions directly from your customers and internal teams. They are the catalyst for discussion, change and improvement that collectively help you to build the best product for your users. Powerful stuff.
But that does not mean that every single one requires you to build a new piece of functionality or even an amend something that already exists.
It’s very easy to jump onto feedback and start implementing something to fix the problem but do you really understand what you are trying to solve?
Very often, customers will request features to solve a problem they are having because that’s what makes sense to them. They have an issue, they want your software to work in a certain way and in their head they will have an ideal picture of what they want to see. Nothing wrong with that. We all do the same thing every day for a whole host of things.
However, this is where the skill of the product team comes in. You need to take those feature requests, look beyond the HOW and think about the WHY.
So instead of asking How can we implement this? Ask yourself Why is this feature being requested?
Remember, you are the experts and know how best to develop your software. You also have the tricky job of ensuring what you are building is inline with where you want to take your product and the market you are targeting.
When is a feature request not a feature request?
Many times...most of the time actually. The key is to open a discussion with your customers and internal teams to create a deeper understanding of the various use cases for a feature that has been requested.
It’s surprising how many requests aren’t down to product alone but due to missing information in your help articles, an error on your marketing site or even a misunderstanding.
Having this open discussion is also fantastic for allowing a large number of users to surface user interface improvements. This is something I hear a lot. No matter how well designed your product is, letting users with different levels of experience loose on it always returns some surprising results. Often a small tweak in the user interface like moving a button slightly, changing it’s colour or bringing an item up a level in the navigation greatly improves the user experience. Many pebbles build a mountain right?
Why you should always dig deeper
It’s extremely rare we move a feature request into development without digging deeper first. Feature requests are like icebergs…you can see part of the issue but you need to look a little harder to build a complete use case.
Being able to request feedback from users and keep them updated along the way is invaluable. Each one will bring their own take on the feature and you can build the use cases from there. When you have this information, you can discuss the feature internally then make an informed decision about how best to handle it.
It’s great for your users and internal teams too. They understand and buy into the process. They feel like their requests are being heard even if you aren’t building exactly what they requested.
The benefits of introducing transparency and communication into the way feature requests are handled are numerous. When you’re working with users and internal teams to create a better product, digging into feature requests, taking the time to understand the why and not just the how you can build something really amazing which directly impacts the success of your business.
Originally published at receptive.io on November 30, 2015.
