Discover · Core
Plan and run discovery research with users
Before you commit to building anything, find out who your users are, what they are trying to do and what gets in their way. Discovery research gives you the evidence every later decision rests on.
About 10-20 daysEvergreenLast reviewed 4 November 2026
Who this applies to
- Skills it builds
- Discovery and research
- PM types
- All
- Product types
- All
- Starting points
- All
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- Write down what you need to learn. Turn it into 3 to 5 research questions, for example 'How do people do this task today?' and 'Where does it go wrong?'.
- List your assumptions about users and the problem. Mark the ones that would hurt most if they turned out to be wrong. Those are what the research should test first.
- Agree with your User Researcher (or yourself, if you have none) who to talk to. Aim for 5 to 8 people from each main user group, including people who struggle with the current way of doing things.
- Choose a method. One-to-one interviews and watching people do the task in their normal setting work best early on. Avoid surveys until you know which questions matter.
- Run the sessions with a note-taker. Ask about what people did last time, not what they would do in theory. Keep your own opinions out of the room.
- Sort what you heard into themes the same week. Write up the main user needs, pain points and surprises, with quotes or evidence for each, and share them with the whole team.
Intermediate (1 to 4 years)
- Turn your riskiest assumptions into research questions and agree them with the team.
- Plan recruitment for each user group, including people with access needs and people who use the offline route.
- Run interviews or contextual observation, and synthesise as a team within a few days of the last session.
- Publish findings as user needs and pain points with evidence, and link them from your product backlog.
Experienced (5+ years)
- Trace research questions back to your riskiest assumptions.
- Cover each user group in your sample, including excluded and offline users.
- Synthesise as a team, and publish findings with evidence, linked to the backlog.
- Record a clear decision: carry on, change direction or stop.
Who can do this
Owner: Product manager
Can be delegated to
- User Researcher or UX Designer: Plan the research, recruit participants and lead the sessions
- Business Analyst: Map the current process and gather existing data about it
- UX Designer: Take notes in sessions and help turn findings into journey maps
- Data Analyst or Performance Analyst: Pull existing data that shows where users drop out or call for help
Reviewed by: User Researcher, Tech Lead, Delivery Manager
Tool examples
- Confluence
- Create one research page per round, with the research questions at the top, a table of sessions, and a findings section the whole team can comment on.
- Notion
- Use a database for sessions (date, user group, key quotes) so you can filter findings by user group when you synthesise.
- Miro
- Put each observation on a sticky note during a team synthesis session, then group them into themes together.
- Mural
- Use a synthesis template: one column per participant, then cluster the notes into themes as a team.
- Claude
- Paste anonymised session notes (no names or personal details) and ask for candidate themes, with the quotes that support each. Check every theme against your own notes before you use it.
- ChatGPT
- Paste anonymised notes and ask which findings contradict each other. Treat the answer as a prompt for discussion, not a conclusion.
Definition of done
- Research questions agreed with the team before sessions started
- Sessions run with people from each main user group
- Findings shared as user needs and pain points, each backed by evidence
- Team has agreed what the findings mean for the next step
Common pitfalls
- Asking people what they would like instead of what they did
- Only talking to confident or friendly users
- Running the research alone and presenting a report, so the team never sees users first-hand
- Starting to design or build before the findings are in
If you lead the team
What good looks like: Teams talk to real users regularly, and their research changes decisions.
Ask your PM
- Who did we speak to, and what surprised us?
- What will we do differently because of this research?
Warning signs
- Research only confirms what the team already planned.
- Users are only heard through sales or senior opinions.