Make Customer Research Matter by Avoiding These Common Mistakes

This excerpt is for any leader looking for ways to infuse customer learning into everything they’re doing.  We shed a little light on how companies lose focus and go on autopilot with research; where process overshadows actual customer insights and action. Take a look.

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

Everything we espouse as professionals is based on understanding the customer. It’s hard to find a company that will tell you that they don’t want to hear from customers. And that makes it hard to develop good hypotheses about who they are and what they need. But companies can demonstrate a big failure point in execution when they conduct customer research. These companies will say they talk to customers all the time but what we see is a big gap in understanding what customers are saying. Let’s talk a bit more about what this may look like:

Company A is a large consumer business. They have a research facility that conducts customer research like clockwork every two weeks, putting every feature of their product through some sort of customer testing. They have a dedicated customer research analyst who talks to customers and develops reports. All the reports go to a shared storage where anyone in the company can access them.

That scenario might sound like magic to some of you, but we hear the slasher sound from the movie “Psycho.” We see three red flags: 1) A dedicated research team, someone outside the product team, does all the research; 2) Research is a stage of the development process; 3) Reports don’t have a clear recipient. 

Let’s examine each red flag a bit more to understand why this is a nightmare-inducing situation for us.

A Dedicated Research Team

Large companies can afford separate research departments. This is great—having people with the right skills and knowledge to do all sorts of deep research is a gift we would never turn down. However, when external research departments want to control all customer research, as often happens, it’s a problem. Most specialized departments end up wanting control, which is not necessarily a bad thing. A specialized department can manage its work more efficiently, force a company to prioritize, and can see connections between the different products and user experiences the company offers. But when a product team loses all ability to do their own customer research, it creates a chasm that is not easily crossed. A dedicated research analyst should, at the very least, be dotted lined into the product team, they should know exactly what the product is designed to do and why, and they should take their direction from a product manager. If these steps are in place, then the centralized research department becomes a benefit and not a curse.

Research as A Recurring Process

Whenever we hear that research is done regularly, we dig a bit deeper. What drives the cycle of research activity? Is the research focused around a hypothesis, or is it happening because it’s an activity to check off the to-do list? While we encourage frequent research, it should always be attached to something that the product manager needs to learn in order to make a decision; the research should always be done with an actual target or goal in mind. All research should start with a hypothesis. If you consider research as a regular occurring activity, go back and review what the inputs and outputs are. Ask yourself if you’re getting value from the work that’s being done.

Zombie Reports

What does your research report look like? Is it updated from a template? How much is customized? Does it include quotes, pictures, and videos? Ask yourself: Does it provide insight? We both have had the experience of having dedicated research groups added to our department. These researchers would present the team with PowerPoints of their research every two weeks, like clockwork. Those reports provided a lot of colorful images of customers who the researcher had spoken to, a lot of background information, and summaries of their discussions. Our teams would dutifully listen to the presentation, some would read the report and every person would file them away and they’d never be referred to again. When you receive a research report, are you doing anything with it? Does it live after the meeting? Does your team use the research results to shape their work? Were you able to make a product decision on the basis of the research? If not, stop the madness, cancel the report, save time and effort. Ask your team to provide a hypothesis, and then leverage your research resources to learn and validate or invalidate the hypothesis. Every research activity should produce results that the team needs.

Most companies conduct some sort of customer research, and we see over and over again that it’s not optimized to give them actionable results, partly because they don’t start with a solid hypothesis. We’re determined to fully persuade you about the value of hypothesis testing!


If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.

Leave a Reply

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