discovery-research-synthesis

# Discovery Research Synthesis

A senior PM's playbook for turning research artifacts into decisions. Customer interviews, user research notes, support ticket reviews, sales call transcripts, survey data, in-app feedback, all synthesized into the product direction they are meant to inform.

Most discovery research never produces decisions. The team conducts interviews; the transcripts pile up; a researcher hands product the raw artifacts (data-dump) or builds a polished readout deck (insight-theater); the deck gets a 30-minute review meeting and is never referenced again. Two months later the team is making the same product decisions that the research was supposed to inform, with the same gut-feel inputs the research was supposed to displace.

The discipline is in the synthesis. Synthesis is where research earns its keep: where transcripts become tagged observations, observations cluster into patterns, patterns get named, named patterns surface product implications, and implications drive specific decisions. Without that sequence, research is performance art.

This skill covers one-off discovery research projects: a 12-week customer development sprint, a sales-call review for an onboarding redesign, a support-ticket audit informing a roadmap quarter. Different from `user-feedback-aggregation`, which covers ongoing feedback streams; different from `jtbd-framing`, which is a specific framing technique often applied within synthesis but narrower in scope.

The voice is the senior PM or staff product researcher who has run synthesis well and seen plenty of teams fail at it. Honest about where polish becomes performance and where pattern-naming slides into pattern-fabrication.

When to use this skill: synthesizing a recent batch of customer interviews, auditing why prior research has not produced product decisions, designing the synthesis output for a multi-week discovery sprint, or establishing the synthesis discipline a team currently lacks.

---

## What this skill is for

This skill spans research-to-decision synthesis. The PM-skill distinction:

- **`discovery-research-synthesis` (this skill)** is one-off research synthesis: turning a discrete batch of artifacts into a discrete set of decisions.
- `user-feedback-aggregation` is ongoing feedback streams: continuous synthesis across always-on channels (support, NPS, in-app, sales).
- `jtbd-framing` is a framing technique often applied during synthesis; this skill is broader.
- `pm-spec-writing` is downstream: specs use synthesized insights as input.
- `roadmap-planning` is downstream: roadmap uses synthesized priorities as input.
- `experiment-design` is the quantitative-validation discipline that often follows qualitative synthesis.

The audience: senior PMs, product directors, in-house product teams, agencies running discovery work for clients, researchers handing off to product teams.

What is not in scope: conducting the research itself (interview design, recruiting, moderation), the broader discovery strategy that decides which research to commission, or the long-running feedback channels that user-feedback-aggregation covers.

---

## Data-dump vs insight-theater vs actionable-synthesis

The keystone framing. Two failure modes plus the discipline.

**Data-dump.** Research artifacts handed to the product team raw. "Here are 47 transcripts and a spreadsheet of tags; figure it out." No synthesis, no signal-finding, no implications drawn. The product team either does the synthesis itself (often badly, often months later) or skips it (the most common outcome). Output: a research investment that produced artifacts but not insight.

**Insight-theater.** Overpolished synthesis dressed as insight. Pretty quote walls, designed personas, branded readout decks, no decision-driving conclusions. The research deck that gets a 30-minute review and never gets referenced. Synthesis that performed for the executive audience but did not inform the product audience. Cost: real research budget converted into a slide deck; the organization "did the research" without doing the research.

**Actionable-synthesis.** Synthesis that drives decisions. Each pattern has a "so what" attached; each finding leads to a product implication; the document gets referenced in roadmap discussions, spec drafts, prioritization debates. The synthesis is short, opinionated, and load-bearing. Six months later, team members can quote the patterns that shaped what shipped and what got cut.

The litmus test. Three months after a synthesis ships, can team members name the decisions the synthesis informed? If yes, the synthesis was actionable. If team members remember the deck but cannot name the decisions, it was insight-theater. If nobody remembers anything because the synthesis never happened, it was data-dump.

---

## Discovery research types

Five common research types, each with different artifacts and synthesis needs.

**Customer interviews.** 30-90 minute structured or semi-structured conversations. Transcripts plus moderator notes plus recordings. Highest-quality qualitative data; most expensive to collect; most rewarding to synthesize when done well. Typical batch: 8-15 interviews per discovery cycle.

**Support ticket reviews.** Auditing recent support tickets for patterns. Lower per-artifact richness than interviews; higher volume; surfaces the friction users actually hit (not just what they say in interviews). Typical batch: 100-500 tickets per audit.

**Sales call analysis.** Recording or transcript review of recent sales calls. Surfaces objections, pricing-conversation patterns, competitive mentions, and the gap between marketing positioning and what sales actually leads with. Typical batch: 15-30 calls per audit.

**Survey data.** Quantitative responses with optional qualitative comments. Best for validating qualitative patterns at scale; weak as primary discovery (surveys reveal what users say, not what they do). Typical batch: 100-2,000 responses.

**In-app feedbac