A few months ago I saw a clip of Bill Hader making rounds on the internet. In the clip he talks about receiving notes on his writing.
"When people give you notes on something, when they tell you it's wrong, they're usually right. When they tell you how to fix it, they're wrong."
This clip resonated with many product managers and product designers. Customer feedback and user research often result in a collection of suggestions, ideas, and requests. Some of those suggestions may be completely irrelevant, but many might sound enticing.
"I don't need the user to tell me what to build" many will say. "But the iPhone!" they'll proclaim. "But Ninja Gaiden!" a select few might preach. The problem is that these people are thinking about research entirely wrong. Taking the customer's suggestions literally, at face value, is the exact wrong way to synthesize research.
The point of research
The primary goal for research is to better define problems and people. My hot take is that is true of both evaluative and generative research (usability and discovery research), for the UXR folks in the crowd. The goal is to invalidate your assumptions; to see what others see that you can't; to learn what people expect, and how that differs from what you're offering.
The goal ought not to be to extract the best ideas from people, but instead to generate your own ideas based on what you've learned.
In the case of discovery research, you're trying to generate qualitative data that can inspire your team to generate the next idea; you should not be trying to squeeze that idea out of the customer.
In the case of usability research, you're trying to collect qualitative data to indicate where you have usability issues. People aren't really that good at telling you verbatim what problems they're having.
Research is like mapmaking.
You're trying to get a better understanding of the land. Where are the pitfalls? Are we even headed in the right direction? Are customers down this path? If we're on the right path, can we start to plot the course more efficiently?
Research helps identify and define problems, segments, and expectations. Once you have clarity it becomes much easier to generate ideas and define constraints.
Everyone on your team should contribute to the cartography here, too. (Yeah this metaphor is getting stretched out, but bear with me for a bit longer.)
The more you have stakeholders, engineers, support people, and more participating in your research studies the better. That means collecting questions, having them observe research (or watch back recordings), and even having them help you conduct research. If you're brave enough. That also means the things they find are valuable. Listen to your team!
It's worth noting that maps are not the territory; they are a representation. So, it's best to continue to conduct research, to listen to your customers, and to constantly question your assumptions. Sometimes the landscape changes. Sometimes you find new and exciting opportunities in the terrain. Sometimes you learn where dangers may be.
Research isn't about taking user feedback as direct instructions, but about interpreting it to understand underlying problems and expectations. The goal is guiding product development and evolving with continuous exploration. You still plot the course on the map, it just helps to fill out the details.