5 Mistakes we all make with product feedback

I recently went through an article written by @destraynor titled 5 mistakes we all make with product feedback that I enjoyed, and wanted to run through it.

Having read a lot of literature this past year, on Lean Customer Development and this article put into perspective over five-points, common mistakes that are made from false assumptions when reading customer feedback.

I always champion teams not looking at face-value from what they get as feedback, because they are based on many assumptions, many of whom are either erroneous, or because you are taking into account customers that shouldn’t matter as much to you. Ill go through the list in a more abbreviated form, but I encourage you to read through the entire article, at http://blog.intercom.io/?p=6279


You need to segment the types of feedback you have by the type of audience, rather than mixing up all and forming an analysis from the combined pool. You have customers that use your product daily, some that use it sparingly, and those that downloaded or purchased but never used it. In order to get relevant feedback for a feature, ask the users that use your feature the most.

If you want to improve your onboarding, only listen to people who recently signed up.

— Inside Intercom



Customer Engagement should be on-going, and iterative, the same way your software development cycle is iterative. Lean Customer Development champions the notion of continuous engagement, which should be in sprint-cycles, so every two weeks, every four weeks. Aligning your feedback mechanism with your development feedback allows you to continuously improve your product the following iteration based on feedback in a modularised and systematic way.

Feedback should also be done implicitly, through AB testing continuously, trying different on-boarding techniques etc, as well as using analytics to track specific feature usage, how long a user has been on a particular screen.



@destraynor distinguishably points out that not all feedback requests should be treated equally. That is, users of your freemium model versus the paying-customers provide different sorts of insights. Free users can be used to provide feedback on the free aspect, but not to be used to provide insights on the premium side of things. Once again, segment your feedback for different users, to different parts of your product. 



It’s often said the plural of anecdote is not data, but that does not mean anecdotal evidence is not useful. The plural of anecdote is a hypothesis, or narrative. Something that’s easily verifiable.

— http://blog.intercom.io/?p=6279

You need to take feedback in context, you shouldn’t take the feedback of five people as the gospel on what you should do next. In Lean Analytics, your goal is to fine a specific and trackable measurement that correlates to success. With customer development, you need to ensure the right type of customers provide feedback that is constructive. With quantitative data, you need the right amount of data to offer feedback value, if you are working with qualitative data, you need to ensure the right type of customer is providing feedback, without bias or distortion.

As @destraynor says, treat every feedback as a hypothesis, don’t build it but verify and prove it. Then you should build it.


There’s a famous quote from Confucius that the author makes mention of:

when customers point to the moon, the naive product manager examines their finger.

— Confucious

That means, as a product manager, you shouldn’t take things at face value, if a customer wants something, it may be something derived from something abstract that the solution to may be, similar to the 5 Why’s technique. Interrogate the response, think laterally and essentially ‘abstract a level or two above what’s requested into something that makes sense to you

For the complete article, visit http://blog.intercom.io/?p=6279



Leave a Reply

Your email address will not be published. Required fields are marked *