User research has matured substantially as a discipline over the past decade and is now standard practice in mid-to-large product organisations. The maturation has not eliminated a recurring pattern: research conducted late in the cycle, designed to validate decisions already made, producing quotes that get used to justify the chosen direction in stakeholder presentations. This is research theatre. Research that genuinely informs product decisions looks structurally different — different timing, different question framing, different willingness to act on findings.
Discovery Research vs Validation Research
Discovery research aims to surface what the team does not yet know — what users actually do, what problems they actually have, where the friction in the current experience genuinely lives. Validation research evaluates a specific design or feature against user response — usability testing, prototype evaluation, A/B testing. Both are valuable. Both have appropriate timing in the product cycle. The mistake is using one when the other is needed — running validation research when the team has not yet identified the right problem, or running open discovery when a specific design choice needs to be evaluated quickly.
The Question That Determines the Method
Methods follow the question, not the other way around. "What jobs are users hiring this category of product to do?" is a discovery question best served by contextual interviews and observation. "Can users complete the checkout flow without help?" is a validation question best served by usability testing. "Which pricing structure produces higher conversion?" is a quantitative question best served by experimentation, not by interviews. Method-driven research — running a survey because the team has a survey tool — produces shallow findings.
Sample Size Calibration
Qualitative research saturates faster than most teams expect — five to eight interviews per distinct user segment is often sufficient for discovery. Quantitative research requires substantially more — surveys with statistical claims need representative sampling and adequate sample size, A/B tests require power calculations, segmentation analysis multiplies the sample requirement. Confusion between the two leads to two characteristic mistakes: claiming statistical generalisation from eight interviews, or running ten qualitative interviews and waiting for "enough data" that never arrives because qualitative research is not about volume.
A useful diagnostic: when the research is presented, can the team identify findings that surprised them or contradicted their prior beliefs? If every finding confirms what the team already thought, the research either was not designed to find anything genuinely new, or the findings that contradicted prior beliefs were filtered out during analysis. Both of these are common, and both produce confidence without learning.
Research Operations: The Infrastructure That Holds Up
Research scales when the operational infrastructure is in place — participant recruiting that works repeatedly, consent and incentive workflows that are compliant and efficient, research repositories that make past findings discoverable, templates and playbooks that let non-research-trained PMs run lightweight studies competently. Without this infrastructure, every study reinvents the operational wheel. With it, the team can run more studies with less effort, and findings accumulate rather than getting lost in slide decks.
How to Run Research That Actually Lands
- Frame the question precisely before picking the method — "what do we need to learn?" not "what study should we run?"
- Pick the lightest method that answers the question — five interviews can answer a lot, do not run thirty by default
- Recruit a real user sample — convenience samples produce biased findings
- Invite stakeholders to observe, not to debate during the session
- Synthesise honestly — including findings the team would prefer not to act on
- Store findings somewhere durable — research that lives only in slides cannot accumulate
- Tie findings to specific decisions; research that does not change decisions is decoration
When Research Is the Wrong Tool
User research is not always the right answer. Some decisions are best made by analysing existing usage data. Some are best made by running an experiment rather than asking what users would prefer. Some are policy or regulatory decisions where user preference is not the relevant input. Strong product organisations match the decision to the right input rather than reflexively running research because research is what they have. The discipline of knowing when research is the wrong tool is part of using research well.