Feedback is the nexus between user needs and product development. But gathering and using it effectively doesn't come easily; it's one of the trickiest things to get right.
Users are fickle, often misguided about what they want, and will give feedback you'll want to build for but should completely ignore. This is a tough racket.
Like any business challenge, great execution is a composite of focusing on the right things while filtering out noise. By getting in the right state of mind when talking to customers, you can avoid missteps and use feedback to its full potential.
Divorce yourself from the product
Researcher Charles Liu wrote a great article on asking better questions in user interviews. Referencing Erika Hall's book, Just Enough Research, Liu reminds us of the number one rule for user research:
Never ask anyone what they want.
Doing so inevitably leads to missing the root cause of the problem.
By not divorcing yourself from the product, you will find it tempting to lead the interview with your own product ideas or suggestions. This can get scary.
You will start bringing your engineering team a list of your ideas that you've mistakenly assumed are customer needs. In the end, you'll have no one to blame but yourself if the customer decides that they're "not ready to buy."
Liu suggests applying the 5 Whys approach to uncover the root cause of a customer's problems. By asking instead of suggesting, you can help customers find new workarounds, give process feedback, and save valuable engineering resources.
Focus on uprooting the core problem your users are facing. Find out what is currently being done to solve this problem and what could be made better.
All feedback is not created equal
A great product manager will set up many methods to get a holistic view of what users think -- exit surveys, user interview requests, and NPS email campaigns, just to name a few.
But context matters. Placing all feedback on equal footing and overlooking the source is bad research; you'll be met with a deluge of data and not a drop of insight.
A customer's parting words as she's filling out the cancel screen paints a much different picture than what power users say on a 30-minute call. Keeping a universal list of product feedback is a must, but use segmentation to explain the "why" behind a feature request.
Image credit: Sian Townsend
"Best practices" can vary to the point of being contradictory. Should you maintain neutrality? Always go in with a hypothesis? Have mocks and drafts to show? Or should you only ask questions?
Though each is useful, the trick is to know when to use each technique most effectively:
- Conduct user test interviews to find friction in your onboarding flow. In this case, sit back, maintain neutrality, and let your customer's confused mouse path and voice tell the story.
Taking every piece of feedback at face value is a surefire way of dragging your team into what David Bland calls the "Product Death Cycle."
By giving context to feedback, you can achieve greater clarity on not only what customers are asking for, but their motivations behind it.
Consider the "minimum viable solution" for small requests
This one is specific for the support folks. Not every piece of feedback requires a product overhaul or new feature to be built.
Always ask yourself: "Does this customer's request really need three more months of development, testing, and implementation? Or is there an immediate workaround solution that we can implement today.
A personal example: I was cross-shopping CRM solutions for our team and found one that I mostly liked, but saw a glaring fault. I needed the ability to populate the CRM from multiple email addresses (one company-personal address and one support-specific email).
Unfortunately, adding additional email addresses would mean additional "seats" for our account, meaning additional costs. Instead of telling me "the feature will be here in X months" with the risk of not delivering, their support team suggested adding the extra account and waiving extra desk fees (since they knew I was the only one using the account).
Does each piece of feedback need engineering, or can a problem be solved through a manual process? If the request reoccurs enough times, you'll have justification to move forward with a new feature.
Lower the bus factor
Achieving clarity on customer feedback is something we strive for. But how this feedback is delivered to your team is just as important as the gathering process. Don't lead the race only to stumble at the finish line.
The muddling of customers' thoughts isn't just a possibility; it is inevitable, especially when misinterpretation is amplified exponentially across multiple people.
Paragon Innovations' famous product development analogy.
To avoid breakdowns in communication, maintain transparency and consistency of communication across your organization. Help desk tools, shared documentation, and weekly syncs should all be staples in any company's arsenal.
Even better, consider putting everyone on the front lines by establishing a culture of support.
Having engineers experience customer frustration first-hand is much different than having them hear about it from a report from the support team.
The key is to ensure everyone involved with a product is relying on primary sources, not interpretations and assumptions.
Don't make support and sales speak for the customers. Let the customers speak for themselves.
Finally, accept that mistakes will happen
Mistakes will happen in any ambitious business strategy. Rarely will a single, catastrophic failure happen in a built out process. Instead, mistakes occur in a systematic fashion, one at a time.
Comic by Sandra and Woo
It is a given. Unavoidable. But if you consistently strive to keep the right state of mind when collecting feedback, you'll be well on your way to developing real insights.