over the past several weeks, we’ve been exploringwhat a product trio is,how decision-making works in product trios, andwhy more roles aren’t included. today, we are going to tackle how user researchers fit into this puzzle.
you can watch the short video or read a lightly edited transcript below the video.
why aren’t user researchers included in product trios?
what role should they play when product teams adopt acontinuous discovery cadence?
can product teams really do their own research?
how does user research fit into a continuous discovery world?
i want to start by saying user researchers absolutely have a place in a continuous discovery world. we need more researchers, not fewer.
user researchers aren’t included in the default product trio simply because most companies don’t have enough user researchers for this to be feasible. so, given that, what role should user researchers play?
i see three primary patterns—each of which is a viable way of getting value out of user researchers. and many companies mix and match the patterns.
user researchers work on longer-horizon research
first, many companies deploy their user researchers as a centralized team working on longer-horizon research, also known as project research.
project research isn’t bad. in fact, it’s necessary. we need teams tackling big, strategic questions, keeping tabs on external trends, and understanding customer behavior over time.
product teams don’t have time to do this research. we are too busy shipping value week over week to tackle these bigger questions. having a centralized user research team to fill in these gaps is invaluable.
embed user researchers with your product trios
second, some companies are hiring enough user researchers to embed a user researcher with each of their product trios. if you are in this situation, fantastic. be sure to include your researcher throughout discovery. they can help you improve the reliability and the validity of both yourcustomer interviewsand yourassumption tests.
be careful, however. sometimes when we embed user researchers on product teams, it can be easy for the team to let the user researcher do all the research on their own. we don’t want this.
it’s important that theproduct trio conduct the research togetherso that they each have firsthand exposure to the customer. remember, this is what allows us to avoid hand-offs, makes our research more believable, and helps us see the gaps between how we think of the product and how our customers think about the product.
even when we have a user researcher embedded with the product trio, we still want the entire trio involved in the research.
assign user researchers as research smes for your product trios
third, if you don’t have enough user researchers to embed one on each of your product teams, you can assign a user researcher to several teams acting as a subject matter expert. again, this does not mean that the user researcher does all of the research for each of their teams. this will create bottlenecks that will slow all of your teams down.
instead, the user researcher should be available to give guidance on interviews and assumption tests. they can help their teams increase the reliability and validity of their research methods. they can help train the individual members of the trio in different techniques so that everyone gets better at research.
the challenge with this third pattern is many researchers want to do research. they don’t want to train others on how to do research. so you have to use this pattern wisely. i often see it paired with the first pattern, where researchers both work on longer-horizon research and advise a few product teams on their discovery activities.
when user researchers advise product trios on their discovery activities, however, they need to understand that discovery research is fundamentally different from project research. product teams work on a faster cadence. we don’t have time for perfect research. and that’s okay. we are trying to mitigate risk, not seek truth.
product teams work on a faster cadence. we don’t have time for perfect research. and that’s okay. we are trying to mitigate risk, not seek truth. –tweet this
user researchers need to understand that product teams work under the constraint that they need fast answers to daily questions. they need to be able to test an assumption in a day or two, not weeks. good user researchers understand this and are able to balance the science of longer-horizon research with the art of quick and dirty assumption testing.
avoid this anti-pattern: don’t let user researchers be gatekeepers
regardless of how you mix and match these patterns in your organizations, here’s the major anti-pattern to avoid. don’t let your user researchers become the gatekeeper to your customers.
i’ve worked with far too many teams who waste weeks spinning their wheels waiting on research from the user research team. instead, they could have used that time to run less-than-perfect assumption tests, which are more than adequate for discovering and shipping customer value.
remember, longer-horizon research is fundamentally different from discovery research. it’s not about pitting these methods against each other. we need both. we need well-trained researchers doing project-based research to get answers to jumbo-sized research questions and we need product teams getting fast answers to daily questions so that they can ship value this week.
we need well-trained researchers doing project-based research to get answers to jumbo-sized research questions and we need product teams getting fast answers to daily questions so that they can ship value this week. –tweet this
there’s plenty of room for all of us. this is the epitome of the “yes, and” mindset. companies thrive when they get both types of research right.