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 feedback. Users submitting feedback through in-product channels. Volume is high; quality varies; signal lives in patterns across many low-effort submissions. Typical batch: ongoing; synthesized in periodic audits.

Different research types compose. A discovery cycle often pairs interviews (depth) with support ticket review (volume) with survey data (validation at scale). The synthesis combines them.

Detail in references/research-types-and-when-each-fits.md.

The synthesis sequence

Six stages from raw artifacts to decisions. Skipping stages is where synthesis fails.

1. Transcribe and prepare. Convert artifacts into a synthesizable format. Interview recordings to transcripts; sales calls to summaries; support tickets to a tagged dataset. The prep work is unglamorous; teams that skip it never reach the later stages.

2. Tag at the artifact level. Read each transcript or ticket and tag it with the topics, problems, and quotes that surface. First-pass tagging is descriptive: what did this person say, what problem did they hit, what were they trying to do. Tags are messy; that is fine.

3. Cluster across artifacts. Group tags into themes. Multiple users mentioned the same friction; multiple tickets reference the same workflow; multiple interviews returned to the same struggling moment. The clusters surface the patterns.

4. Name patterns. Each cluster becomes a named pattern. The naming is the work: a pattern named badly disappears into the synthesis; a pattern named well becomes the framing the team references. "Onboarding configuration friction" is a pattern name; "users had trouble" is not.

5. Infer product implications. For each pattern, what does this imply for the product? Implications are the bridge from observation to decision. A pattern without an implication is a finding; a pattern with an implication is actionable input.

6. Name the so-what. For each implication, the specific de