The following is an excerpt from my upcoming book, Continuous Discovery Habits. I’d love your feedback in the comments. After reading, are you ready to interview as a trio? Still have doubts? Please let me know your thoughts.
Product research needs to be timely, actionable, and believable for a product team to act upon it.
Product research needs to be timely, actionable, and believable for a product team to act upon it. – Tweet This
To achieve all three, the product trio (a product manager, a designer, and an engineer) needs to conduct their own interviews. Many teams don’t want to hear this. It’s easy to outsource interviewing to other parts of the organization—to the user research team, the marketing team, or the business intelligence team.
These teams are already conducting valuable research. Why can’t we leverage their work? While these teams do create valuable research that the product team should use, it shouldn’t be in lieu of discovery interviews. It’s difficult for third-party research to be timely, actionable, and believable for the product team.
Product Trios Need Timely Research That Answers Today’s Discovery Questions
Product teams are marching toward a desired outcome. Many teams release code every week—if not every day. We have daily questions that need fast answers.
At most companies, centralized research teams work on a different cadence. They conduct project-based research. They spend four to six weeks getting a reliable answer to a meaty business question. They are serving multiple teams, weighing the demands of different teams against each other.
A product team can’t afford to sit around waiting for an answer. They need to make decisions based on whatever data they have now. When a product trio conducts their own interviews, they are able to get fast answers and infuse more of their decisions with valuable customer feedback.
When a product trio conducts their own interviews, they are able to get fast answers and infuse more of their decisions with valuable customer feedback. – Tweet This
Product Trios Need Actionable, Not Just Interesting Research
Additionally, longer-horizon research projects tend to generate a lot of data. These centralized research teams are well versed in massive synthesis projects. They spend hours affinity diagramming, looking for patterns and themes, and drawing broad conclusions that can help steer the business. This creates a ton of value, but it rarely comes in the shape or size that’s right for a product team.
A marketing team at a streaming entertainment company might uncover through their research that consumers in the United States are becoming more comfortable with streaming entertainment and more are willing to end their cable subscriptions. This is an important trend that would have a large impact on any company in this industry. The research might describe what types of families are canceling their cable, which subscriptions they are most likely to buy, how much they pay for these subscriptions, and so on. This research is valuable. It can be used to help craft a streaming entertainment company’s offers, pricing, and when and where to advertise.
However, for the product team that is building the streaming entertainment service, this research is interesting and can inform their overall strategy, but it doesn’t answer their weekly questions. One week they might need to understand what people think of commercials and how they respond when they interrupt the show. The next week, they might need to dive into how people decide what to watch.
It’s not that centralized research teams can’t dive into these types of questions. It’s that they aren’t likely to do so on the timeline that the product team needs. As a result, if the product team wants research they can act on right now, they need to do their own interviewing.
Centralized research teams aren’t likely to do research on a timeline that the product team needs. If the product team wants research they can act on right now, they need to do their own interviewing. – Tweet This
Product Trios Need Believable Research That Will Influence Their Decisions
Finally, research needs to be believable. It is true that most user research teams, marketing teams, and business intelligence teams conduct good research. Their methods are sound, they are careful about the conclusions they draw, and they do a good job of communicating their results.
However, it is very easy to dismiss or discredit someone else’s research if you disagree with it. Consider your experience reading the news. If your political party is in power, it’s easy to agree with everything they do. If they aren’t, it’s easy to disagree with everything they do. Even if both parties do the same thing.
This is human nature. Annie Duke, in Thinking in Bets, calls this “motivated reasoning.” Motivated reasoning happens when we don’t question what confirms our own beliefs and we try to discredit what goes against our own beliefs. In other words, we can quickly see the flaws in other people’s work when we disagree with it while we overlook the flaws in our own.
We can quickly see the flaws in other people’s work when we disagree with it while we overlook the flaws in our own. – Tweet This
Now if you think you are immune to motivated reasoning, Duke explains, “the smarter you are, the better you are at constructing a narrative that supports your beliefs, rationalizing and framing the data to fit your argument or point of view.” This is known as the blind-spot bias—we notice motivated reasoning in others, but not in ourselves.
Too often good research gets ignored because the people who are responsible for making the decision weren’t involved in conducting the research. The easiest way around this is to have the product team conduct their own research. If they find a flaw in their own research, instead of ignoring the research, they are responsible for improving their research methods.
Longer-Horizon Research Plays a Role
This doesn’t mean that you can’t use the research that your centralized research teams produce. You can and should. In fact, they have the luxury of longer-horizon research which a product team rarely has. If you can forecast what might be helpful down the road, get them started on this work now.
If you can forecast what might be helpful down the road, get your centralized research team started on this work now. – Tweet This
Additionally, you can use these teams as subject matter experts on research. They were trained in this; you likely weren’t. Ask them for advice when you get stuck with your own research. Encourage them to review and give feedback on your plans. And if you ever have the luxury of having a member of one of these teams embedded in your own product team, working alongside you in your product cadence, by all means, rely on their expertise.
No Single Role is the “Voice of the Customer”
But just like we don’t want to outsource our research to a centralized team, we also don’t want to rely on one team member to do all of the interviewing. It’s easy for teams to leave the interviewing to the user experience designer or to the product manager, but this is a mistake.
Oftentimes we think the purpose of these roles is to be the “voice of the customer.” However, our goal as a product trio is to collaborate in a way that leverages everyone’s expertise. If one person is the “voice of the customer,” that role will trump every other role.
Imagine a product manager and a designer disagree on how to proceed. The designer has done all of the interviewing. It’s easy for the designer to argue, “This is what the customer wants.” Regardless of whether or not that is true, the product manager has no response to that. Designating one person as the “voice of the customer” gives that person too much power in a team decision-making model. The goal is for all team members to be the voice of the customer.
Designating one person as the ‘voice of the customer’ gives that person too much power in a team decision-making model. – Tweet This
Generate More Insights by Interviewing Together
What we hear in an interview is influenced by our prior knowledge and experience. Because each member of a trio brings a different set of knowledge and experience to the room, each member will hear different aspects of the interview.
You’ve probably had the experience of talking to a coworker after an important meeting, only to realize that you each heard different takeaways. As you talk it through, you realize you interpreted a key statement differently or you each focused on different statements.
This selection of different data and/or the different interpretation of the same data is an example of Chris Argyris’s Ladder of Inference at play. The Ladder of Inference is a model that describes how we interpret the world. It explains that as we engage with the world, we select a subset of observable data, we add meaning to that data, we make assumptions based on that meaning, and then we draw conclusions and adopt beliefs based on those assumptions.
Because we all engage with the world from a unique perspective—we each have different knowledge, expertise, and past experiences—we each select different data, attach different meanings to that data, make different assumptions, and often draw different conclusions. Even though we are starting from the same raw material, we each see and hear different things.
Even though we are starting from the same raw material, we each see and hear different things. This is why it’s so important to have the product trio interview customers together. – Tweet This
This is true even for two product managers listening to the same customer interview, but it’s especially true for a product manager and an engineer, because they each bring unique experiences to the interview.
The product manager and the engineer each select data, attribute meaning, make assumptions, and draw conclusions from their own knowledge and expertise. Because product managers and engineers each have their own domains, they aren’t likely to draw the same conclusions. This is exactly why we want the trio conducting interviews together.
We want to leverage all three types of knowledge and expertise throughout the discovery process. We want to incorporate the meanings, assumptions, and conclusions that an engineer might draw from an interview that are different from what the product manager or designer might draw.
What does this look like in practice? Imagine you are interviewing a Netflix customer and they tell you the following story:
The product manager might key in on, “‘Most popular’ was all TV shows” because they’ve been concerned that we don’t have the right content.
The designer might hear, “we couldn’t figure out how to search for a specific movie title” because they are primarily interested in improving the user experience.
The engineer might hear, “all of the recommendations are for kids’ movies” because they might be interested in finding a technical way to detect different types of users.
All three selected different data as salient because of the perspectives they brought to the interview. Each perspective is valid and can lead to an important product improvement. The more diversity in the room, the more value you’ll get from each interview.
So remember, interview as a product trio. This will ensure that your research is timely, actionable, and believable. It will also encourage truly collaborative trio-based decisions, helping you to generate far more insights.
The above is an excerpt from my upcoming book, Continuous Discovery Habits. I’d love your feedback in the comments. After reading, are you ready to interview as a trio? Still have doubts? Please let me know your thoughts.
Federico Casabianca says
1. I love the idea of leveraging on a central research team to provide insights and trends on the industry and market. It may be a great input when you’re discovering opportunities.
The challenge here is how to connect that information with what the team is doing now. You might get distracted on the outcome you’re chasing by too much information.
2. Another great point I try to encourage, even if your team has more internal stakeholders is to bank on your engineers to go and have interviews with them. When you’re synthesising the takeaways they always see something the PM didn’t, and they get a better understanding of what they are building and how they are using it. It’s very revealing
Caio Cestari says
Reminded me a lot of “Desirability”, “Feasibility”, “Viability”, and when you mentioned the Ladder of Inference: boom! The perfect connection 🙂 I have recently been introduced to your content and work, Teresa – and I already love it!