User feedback - should you ever not listen to it?
User feedback is always right. Or is it?
Well... yes and no.
Product developers are faced with a flood of feedback every day, from direct feature requests from users, to feature ideas from sales reps on your team, to complaints via email, through rating sites and social media, through customer service tickets, and more.
User feedback is always a valuable source of information. But if product developers aren't careful, user feedback can quickly become a to-do list of features ranked by who shouted the loudest and most often.
Not only does this risk steering a product team in dozens of different directions, but it can also lead to designing a product according to consensus rather than a clear vision and confusing the user experience.
The antidote to being overwhelmed by user feedback is a strong product vision and the product designer's ability to filter out the most important criticisms.
The key to success: look for user insights, not feedback.
Instant cake mixes are a famous example of finding a "million dollar product insight" hidden in negative user feedback that, if taken at face value, likely would have resulted in the product being discontinued.
The first customer reactions to "instant baking mixes" in the 1950s were terrible. The target audience was mothers at a time when housewives, who spent much of their time cooking, were the norm. The test subjects said they hated the product. It made them feel like they weren't really baking or "taking shortcuts."
By listening to insight ("It's important to me to feel like I really baked this cake for my family") rather than words ("I hated this product"), the product designers came to an incredible realization.
They realized that if their customers had to remove the egg powder from the mix and add a freshly beaten egg to the batter, they would feel like they had really baked the cake. The fact that baking mixes are now on the shelves of every grocery store is an indication of how successful the originally hated product became after this insight into how customers experienced the product was uncovered.
So don't just listen to what your customers say, look for the unexpected insights hidden in their words.
Users tell you problems, not solutions
When users (or potential users) ask for certain features, they very often ask for features they are used to from other products. It's unlikely that mimicking other companies' features will result in a truly great, differentiated product.
So don't think of a feature request as a mandatory requirement, but use it as a starting point for a deeper investigation to find out why the customer requested that feature.
There are a number of research methods for generating insights from user feedback, but one of the most effective is simple user interviews. Meet with users and ask them to explain why they want specific features.
In doing so, try to identify the problem they are trying to solve with that feature. It is very likely that multiple "feature requests" from users are all related to the same need or problem. If you can figure out this "root problem", you can come up with a basic solution that can satisfy many "feature requests" at once.
Look at the "silent" sources of insights.
Some of the most valuable insights about your product are "silent"; they are contained in what people do, not what they say.
Look for "cow paths": a cow path is a "randomly chosen" path that shows where people have actually walked, rather than following paved sidewalks. In design, this concept is used to observe user behavior to find the "paths" that users really want. Look for ways your customers are using the product in ways you didn't intend.
Interview people who have turned away from your product: Probably the most powerful source of insights about your product is not feedback from your active users. It lies with your former users who tried your product and then abandoned it. These people believed in the concept of the product so much that they were willing to take on the behavior change and challenge of adopting a new product. If they stop using your product, it is an indication that their experience with the product did not meet their expectations. The delta between the "real experience" and the "expectation" is a measure of satisfaction with a product and a treasure trove of insights on how to improve the product.
When to listen to feedback and when not to
Knowing when not to listen to feedback you receive is just as important as knowing when to listen.
If your company is trying to do something really innovative that is different from what people are used to, and you ask the public if they would hypothetically want that product, many would probably say "no." Changing behavior is notoriously difficult, and doing something truly new requires a willingness to change that few people have.
Imagine asking people if they wanted a platform where they could write 140-character text-only messages and send them around the web at a time when blogs were popular. Despite its popularity today, Twitter would likely have initially received mostly head shakes and eye rolls as feedback, with a few enthusiastic responses that recognized the platform's potential.
Products go through what's called the "Innovation Adoption Lifecycle", a curve with "innovators" on the far left and "laggards" on the far right.
If you're launching something new and innovative, understanding the profile of the people giving you feedback can be critical to gaining meaningful insights.
Look at how visionaries respond to the future direction of your product to understand its potential. Learn from people who are typically late bloomers to understand what you would need to add to your product to reach the "majority" of the market.
But don't mistake latecomers' lack of enthusiasm for a new product for a lack of value or potential. The more your solution aims to change user behavior, the more adept a product designer needs to be at not only analyzing what they hear in feedback, but also understanding the profile of the person giving the feedback.
Every innovation-whether it's a small usability improvement to a feature or the development of a generation-defining product-relies on the recognition of a fundamental problem that real people face. The ability to separate the "symptoms" of feedback from the "causes" is the key skill in developing the simplest and most innovative solutions.
You just have to know how to "crack" the feedback code.