product-research

---
name: product-research
description: Use when planning or synthesizing product/user research — picking the right method, sizing saturation with a stated confidence, or synthesizing observations into insights, not anecdotes.
category: Research
version: 1.0.0
tools: []
---

# Product Research

Product/user research as an operational discipline: choosing the right method, sizing it honestly, and synthesizing findings into governed insights. The core rule: **method must match the goal**, and **an insight requires recurrence across independent participants** — a single quote is an anecdote, not a finding.

## Purpose

Researchers, ResearchOps teams, and PMs running discovery need method rigor and an insight repository they can trust. Structure three decisions:

1. **Method selection** — map (research goal × product stage) to an appropriate method and produce a method-matched plan skeleton (objective, participant criteria, guide structure, success criteria). If the request is actually for a live A/B test, redirect to an experimentation specialist rather than force-fitting qualitative method here.
2. **Sample sizing / saturation** — give method-based sample guidance with an explicit confidence label: Nielsen's problem-discovery guidance (~5 per segment), Guest et al.'s thematic-saturation finding (~12), or evaluative coverage logic. Never claim a prevalence rate out of a small-n usability test.
3. **Insight synthesis** — cluster coded observations by tag, count distinct participants per cluster, rank by cross-participant recurrence, and flag any cluster below the source threshold (default 3 independent participants) as an **ANECDOTE** rather than promoting it to an insight.

## When to Use

- Planning a study and need the method matched to the goal (generative vs. evaluative vs. validation).
- Need a defensible sample-size or saturation rationale with a stated confidence level.
- Have raw coded observations and need synthesis without over-claiming.
- Setting up or auditing a research repository and need the insight-vs-observation discipline enforced.

**Not for:** personas/journey maps, discovery-sprint planning, live product A/B design, or market sizing/surveys — @mention the teammate who owns whichever of those applies.

## Workflow

1. **Frame the study** — research questions, method rationale, participant criteria, analysis plan, repository tagging scheme.
2. **Pick the method** — match goal (discovery / evaluative / validation) and stage (concept / prototype / beta / live) to a method; honor a redirect to experiment-design if the request is really a live A/B test.
3. **Size it** — apply the method-based sample guidance and record the confidence label and its limits.
4. **Synthesize** — after fielding, code observations and cluster them, requiring at least 3 independent sources (raise this bar for high-stakes or heterogeneous populations) before calling anything an insight; treat ANECDOTE-flagged clusters as signals to probe further, not findings to ship.
5. **File in the repository** — tag insights to a consistent schema at synthesis time, with evidence and confidence attached, or they rot unfindable.

## Method Notes

- Method selection assumes the goal can be named honestly — if it's fuzzy, press on that before anything else; the goal drives everything downstream. Ground in Rohrer's UX-research-methods landscape (NN/g), Christensen/Ulwick's Jobs-to-be-Done, and Portigal's *Interviewing Users*.
- Saturation guidance is method-based, not a statistical power calculation — usability tests find problems, they don't measure population prevalence rates. Ground in Nielsen's "test with 5 users," Guest/Bunce/Johnson's saturation study, Faulkner's more-than-5 critique, and Braun & Clarke's thematic-analysis approach.
- Synthesis quality is bounded by coding quality — garbage tags produce garbage clusters; this only enforces the threshold, it doesn't gather evidence. Ground in Tomer Sharon's "Polaris" atomic-research model and standard ResearchOps repository governance (affinity mapping, democratization guardrails).

## Anti-Patterns

- **Mismatching method to goal.** A usability test cannot discover unmet needs; an interview cannot measure task success.
- **Reporting usability problems as percentages.** Small-n tests surface problems, not population rates.
- **Promoting an anecdote to an insight.** One participant is a signal to probe, not a finding to ship.
- **Framing interview questions as feature reactions** instead of probing the job-to-be-done and recent real behavior.
- **Synthesizing without a repository scheme** — tag at synthesis time or the insight becomes unfindable later.

## Forcing Questions (walk one at a time, never bundled)

1. **"Is this study generative (discover problems) or evaluative (test a solution)?"** Name it first — the method follows from the goal. (Rohrer, NN/g.)
2. **"What's your sample size and saturation rationale — and at what confidence?"** Method-based n (~5/segment for usability; ~12 for thematic saturation), with the confidence stated. (Nielsen; Guest, Bunce & Johnson 2006; Faulkner 2003.)
3. **"How many independent participants support each insight — or is it a single-source anecdote?"** Require recurrence across at least 3 sources before calling something an insight; flag singletons. (Atomic research / ResearchOps; Braun & Clarke.)
4. **"Are your interview/usability tasks framed as outcomes (jobs) or as feature reactions?"** Frame around the job-to-be-done and recent real behavior, not hypothetical opinion. (Christensen/Ulwick JTBD; Portigal.)
5. **"Where does this land in the repository, and how is it tagged for reuse?"** Tag to a consistent schema at synthesis time, not later. (Sharon, *Polaris*.)

Lock questions 1-2 before opening 3-5.

## Example

A synthesis pass correctly promotes "import-confusion" (raised by 3 independent participants) to an INSIGHT, while flagging "wants-slack" (raised by 1 participant) as an ANECDOTE to probe rather than ship.