Feature requests are a constant companion of most product managers. It seems like no matter where you go, someone has an idea — AKA a feature request — for your product. Some people hail these feature requests, proclaiming them the silver bullet of product evolution. Other product professionals view these constant requests as the bane of their existence. Which is it?
The answer lies in the beholder. How you handle feature requests determines whether these requests are useful or just an annoying (and sometimes expensive) distraction.
Many new product managers eagerly review incoming feature requests and trust what they’re being told. These product managers run confidently off to implement the design suggestions they received, and they are often confused when users summarily reject these features.
Here’s the issue: most people who submit feature requests are not designers. They might understand how to use the product, and they probably understand the problem that they’re trying to solve when they make a feature request. Unfortunately, most of our users assume that they need to give us a concrete idea for improvement to be heard — so they dutifully imagine how their problem might be solved inside your product and submit an extremely specific feature request.
The problem with these specific feature requests is that even if you study many people in your market and your company, you are unlikely to find a trend among those feature requests — and trends are what market-driven businesses want to respond to.
You want these incoming feature requests, but it is dangerous to take them at face value. Your users are not designers, and their feature ideas often reflect that. They picture something they’re familiar with, or something that would work specifically for them – but they do not understand design or the rest of the market, so these attempts at design usually fall short of the usability goal.
Instead of abdicating our design authority to the users and employees who submit feature requests, we must dig deeper. When someone gives you a feature request, ask them: “what problem are you trying to solve when you make that request?” Take the time to explore the problem they’re experiencing. Ask them, “why are you making this request?” and “Why is that important to you?” When you ask them to focus on the impact on their business, rather than the product’s features, they will start telling you about the root problem instead of making design suggestions about a feature.
When you master this approach and begin to document the problem instead of the individual feature request, you realize that the trends pop up quickly. It also becomes much easier to prioritize, picking the right problems to solve next.
If you focus your team on the right problems to solve, your designers and engineers will figure out the best way to implement a solution.
Left at face value, feature requests can be an intimidating foe; but when we take the time to discover the root problem, feature requests become a loyal friend.
Learn more about how to turn feature requests from foe to friend in our workshop on building better people skills within product management. Check it out here: https://ci2advisors.com/workshop/
