Continuous discovery only works if more than one person does it. But “everyone does research” raises an obvious question: what is the researcher for, and what happens to everyone’s actual job?
For my MSc thesis I asked eight practitioners how they divide this up, then asked a twelve-person product team to design it themselves and vote. The tension in the answers is the most interesting part.
Who should be in the room
The workshop team’s top answer, with five votes, was the product owner for the relevant product. Then, in order of votes:
- Product owners and scrum teams (three votes)
- Internal subject matter experts, so the research team is not starting from scratch and understands the existing process or feature (two votes)
- User researchers and the design team (two votes)
- Business analysts where needed
The subject matter expert point is a good one. A lot of research time gets spent rediscovering things somebody in the building already knew.
Practitioners I interviewed described a similar core: a product manager, a designer and a tech lead in the conversations, with roles assigned per session so everyone has a job. One leads the interview, one takes notes, one observes. Roles rotate.
What the researcher actually does
The highest-voted answer on roles, again with five votes, is the clearest statement of the researcher’s job in a team where everyone participates:
The UX researcher takes on board the research needs and defines the process based on that, using their skills to word questions accurately.
That is the shift. The researcher moves from being the person who does all the research to being the person who designs how research gets done, and guards the quality of the questions. Practitioners described this as providing guidance and oversight rather than being the only one allowed to talk to users.
Other roles the team voted for:
- Researcher, business analyst, product owner and design consistently involved (three votes)
- Product owners assisting and leading where applicable (three votes)
- The product owner defining the outcome required from the research, with whoever requested it (two votes)
- A RACI matrix defined for each activity, so responsibility is explicit per study rather than fixed forever
- Subject matter experts consulted, requesters kept involved, and board or executive stakeholders updated
What non-researchers need to learn
Here the workshop produced a genuinely surprising top answer, with four votes, and it is not a training topic at all:
Everyone should have access to insights, so the same research is not repeated unnecessarily. Note: insights, not data. We cannot expect everyone to read through everything. They need the high level “what does this mean” information.
Access to distilled insight, they argued, prevents more wasted research than any amount of interview training. That is worth sitting with.
After that, the actual training needs:
- Documented frameworks, best practices and a wiki (three votes)
- GDPR, sensitive data and personally identifiable information (two votes)
- How to analyse and present findings
- Training to understand the value and goals of research, not just the mechanics
- How to communicate outputs
- How to write open questions
- How to conduct an interview. One participant’s phrasing is worth quoting: it is very important to listen, not to give a sales pitch, and not to influence. They named this as their biggest concern.
The honest objection
The workshop surfaced a tension that most writing on democratised research skips. Two to three votes went to this:
Recommend skilled researchers are always present. Otherwise, are we making everyone researchers, and therefore where does that leave their original responsibilities?
This is a fair challenge and it deserves a straight answer. Involving the team is not free. Every hour a developer spends in an interview is an hour not spent building. If you push it too far, you get a team of mediocre part-time researchers and nobody doing their actual job.
The practical resolution, and the one both my interviews and the workshop point at, is:
- A skilled researcher stays involved, designing the process and safeguarding quality.
- Untrained team members participate as observers and note-takers rather than leading interviews.
- Everyone gets access to the insights, so participation is not the only way to benefit.
- Roles rotate so the load is shared rather than landing on the same people every week.
Leadership has a role too
One thing practitioners were firm about: initial buy-in from leadership, such as a VP of Product, significantly affects whether a team commits. Clear direction from the top decides whether continuous discovery is something the team is allowed to spend time on, or something they do around the edges of their real work.
Give teams the freedom to experiment with it, and the time to get good at it. As one participant said, it is a mindset, and mindsets take time.
Further reading
- Teresa Torres, Product Talk. On the product trio and involving the team. producttalk.org
- My MSc research. Eight expert interviews and a twelve-person workshop. Read the case study
Next, read the continuous product discovery process or 11 challenges of continuous product discovery.
Based on my MSc thesis on continuous product discovery. The research is written up in the case study.
