Feedback is not research; a common mistake in product development and how to deal with it

If someone tells you he does not like peanut butter. Do you take peanut butter off the shelves? You do not! You ask him why he does not like peanut butter.

He could have an allergy, or perhaps his back injury is keeping him from reaching for it on the shelves. Whatever the case is, companies are making decisions that seem rational, but in reality are not, all the time. And that needs to change.

If you’re an interface designer, user experience researcher, or anyone else involved in building a product, you likely agree with me. However, everyone within a company has a tremendous impact on design and actually make design decisions, whether they are aware of it, or not. And therefore it is fundamental that we speak up if we see that feedback is being translated into design decisions.

But then, is all feedback bad?

No. Absolutely the opposite! Feedback is a beautiful identifier of undiscovered information. And oftentimes feedback does contain out of the box, beautiful insights. The key here is that we understand those insights and make a well-informed decision. Speed slows you down if it impacts quality.

So how do we get there?

Well, that kind of depends on where you are with your project or company. Generally speaking there is something called a feedback loop in place, that acts as a guiding principle for where feedback enters the company and how it is distributed to make the most impact.

Depending on how teams are set up I generally introduce a feedback loop that comes in at multiple stages of the product lifecycle. This could be during customer support, a contact form, help center, you name it. this feedback then gets synthesized into a single overview on something like Airtable, Jira, Asana, or Trello.

I tend to ask everyone involved with synthesizing to prioritize the feedback based on the perceived urgency and the amount of similar feedback dropping in. Once you keep doing this you will have a steady stream of feedback being injected into the company, and it’s available to everyone. Kill all secrecy!

Now the question is, does this feedback go-to project managers, product owners, designers in product teams, or to a separate design team? I would say, send it to whoever is in charge of planning research, he or she is incredibly capable in differentiating feedback that needs further research, or feedback that is clear enough to be acted upon.

So whether you have designers distributed in different teams or a centralized design team that injects information into development teams, I would say, make sure these designers have uninterrupted communication with each other and allow them the responsibility of making informed decisions.

So, where to start?

Just speak right up, if you do not know who is responsible for dealing with the feedback, start at a development team and talk your way up. If you do know who manages the product design, go and talk to him or her. If you happen to be this person, slow down partner, have another look at the feedback coming in.

Your all-time takeaway should be

Does this guy really, really, not like peanut butter?

Thank you for reading! Make sure to follow me, and if you liked this snippet, put your hands up and clap! And if you wanna hang out, have a discussion or possibly work together sometime, reach out to me on Linkedin 🎉