Teresa Torres, author of Continuous Discovery Habits, has taught 7,000 product people how to run User Research. Yup, you read that right—7,000.
And as a famous research evangelist, Teresa has heard every objection to conducting User Research under the sun. We took the opportunity to ask her—how do you respond to those most common objections to running User Research?
Objection #1 [The Oracle]: “I don’t need to talk to users. I already know what they need”
There’s always that product person or founder that thinks they don’t need research—they already have all the answers they need to make product decisions. And sometimes, their experiences confirm this bias. Maybe the product choices they made so far mostly worked, or they started out as part of the target market and initially intuitively understood the problem statement.
For these people, Teresa insists—don’t bother trying to change their minds unless they’re willing. Eventually their luck will start to wear off, but until then focus on the people in your team that already understand the need for research and work with them.
Objection #2 [The Procrastinator]: “I want to run discovery, but I have 5 other fires to put out first.”
Some teams understand the need for User Research and fully intend to run discovery & testing, but somehow every other issue gets in the way, and research gets deprioritized. As something that’s important, but not urgent, research is prone to getting pushed further and further down their priority list.
For these individuals, Teresa recommends starting small and iterating from there.
For example, if a PM has never talked to a customer, start off with just one customer conversation. From there, do a second. And then a third. Eventually, work on building a sustainable habit. Then get better at asking the right questions. Then worry about recruiting for variation. And so on.
Objection #3 [Sample Size Matters]: “We have 100,000 users—5 users is not a representative sample size!”
This one’s a classic. “You just spoke to 5 users. How can I trust your results when it’s not statistically significant?”
The truth is, qualitative research is never going to have a representative sample size.
To these stakeholders Teresa asks, would you rather make decisions based on 5 conversations or zero conversations?
Objection #4 [The Perfectionist]: When a PM or Designer says, “I don’t know how to run research the right way”
While product and design teams may not be research purists, motivated teams can learn how to run basic levels of research well. It’s okay to trade in the perfect process for speed—any contact with a customer is better than no contact with a customer.
Longer, foundational research can still be done by expert researchers, but Teresa insists that it’s essential for product & design teams to fill the gap for faster, simpler studies.
“No matter how many User Researchers a company has, they’ll never have enough to support every teams’ daily decisions,” says Teresa.
Objection #5 [The Skeptic]: “Why should I believe your research findings?”
Teresa has a single commandment for this objection: Show your work.
Too many teams present conclusions, but the problem with that is that everyone has an opinion about what users want and what should be built.
To get buy-in we have to show how we reached our conclusions.
Bonus: How should product & research teams interact?
As we worked through the objections, an important question came up—what is the ideal way to organize your product & research teams to support user-centric product decisions.
Teresa suggests two potential models:
#1 Centralized Research: If the User Research team is centralized, they can work at a different cadence from the product team. The central team can focus on foundational research that the entire organization can benefit from. They can answer questions like, “Where is the market headed?”, “How is customer behavior changing?” or, “Where are there big gaps in the current product strategy?”
Rapid, focused research like usability testing can be handled by product & design teams that run at a faster pace.
One word of caution from Teresa—it’s important that the central research team doesn’t act as a gatekeeper or clearing house for all research. This will only slow the product teams down, which will kill the organization’s appetite for research.
#2 Embedded Research: If the company has enough User Researchers, Teresa suggests embedding them full-time within each product team. This allows Researchers to bring their expertise to the team’s daily decisions.
A warning here: Researchers have to be able to match the cadence of their work with the speed at which the product team is making decisions for their results to be relevant.
.svg)
