Interview Synthesis
An interview synthesis transforms raw user research data into structured insights that drive product decisions. Rather than simply listing what participants said, a good synthesis identifies patterns across conversations, connects observations to underlying user needs, and translates findings into actionable recommendations.
When to Use
- After completing a round of user interviews (typically 5+ participants)
- Following customer discovery calls or sales feedback sessions
- After usability testing sessions to consolidate observations
- When stakeholders need a summary of research findings
- Before ideation sessions to ground the team in user reality
When NOT to Use
- You are summarizing one internal meeting for its attendees -> use
foundation-meeting-recap
- You need patterns across multiple meetings over time -> use
foundation-meeting-synthesize
- Your data is survey responses rather than interviews -> use
measure-survey-analysis
- The findings are synthesized and you are ready to frame the problem -> use
define-problem-statement
- You have synthesized findings and want to map them onto a customer's journey across stages and touchpoints -> use
discover-journey-map
Instructions
When asked to synthesize interview findings, follow these steps:
Gather the Raw Material
Collect all interview notes, transcripts, or recordings. Ensure you have data from at least 3 participants to identify meaningful patterns. Note the research objective and methodology used.
Create Participant Profiles
Document each participant with relevant context: their role, segment, tenure, and any notable characteristics. This helps readers assess the representativeness of findings.
Identify Recurring Themes
Read through all notes and tag observations by topic. Look for themes that appear across multiple participants (ideally 3+). Distinguish between frequently mentioned topics and one-off comments.
Extract Meaningful Quotes
Capture 3-5 verbatim quotes per theme that powerfully illustrate the insight. Good quotes are specific, emotional, or particularly articulate. Always attribute quotes to participant IDs.
Synthesize into Insights
Transform themes into insight statements. An insight goes beyond observation ("users mentioned X") to interpretation ("users need Y because of Z"). Connect what you heard to why it matters.
Formulate Recommendations
Based on the insights, propose prioritized actions. Each recommendation should tie directly to an insight. Note confidence level based on strength of evidence.
Document Limitations
Acknowledge what you didn't learn, sample biases, or areas needing further research. Honest limitations increase credibility.
Project Memory Contract
Active only when .claude/pm-skills.local.md exists. With no file, ignore this section entirely
and behave exactly as described above.
- Reads:
phase and active_initiative, so findings are framed against the initiative in flight instead of asking you to restate it.
- Writes: the personas and findings as an
interpretation artifact, so a later skill can consume them without you pasting them again.
- Posture: propose the entry and wait for confirmation before writing, unless
memory_auto_append: true is set, in which case append and echo what was written.
- Write discipline: re-read the file immediately before writing, never from the copy that
produced the proposal. If it changed in between, merge your entry into the current state and
re-propose rather than overwriting; add only your own entry and leave every other field and
section byte-identical. Nothing enforces this at runtime and the file is gitignored, so a
careless whole-file write loses another session's work with no way to recover it.
This is the writer half of the loop the cohort exists to demonstrate: what this skill records, deliver-prd later reads.
Output Format
Use the template in references/TEMPLATE.md to structure the output. A complete synthesis fills every template section: Research Overview; Key Themes; Notable Quotes; Insights; Recommendations; and Appendix.
Quality Checklist
Before finalizing, verify:
Examples
See references/EXAMPLE.md for a completed example.
1---2name: discover-interview-synthesis3description: Synthesizes user research interviews into actionable insights, patterns, and recommendations. Use after conducting user interviews, customer calls, or usability sessions to extract and communicate findings across participants. Distinct from foundation-meeting-recap, which summarizes one internal meeting for its attendees; this skill aggregates research conversations into evidence-backed findings.4license: Apache-2.05---6<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
7# Interview Synthesis
8
9An interview synthesis transforms raw user research data into structured insights that drive product decisions. Rather than simply listing what participants said, a good synthesis identifies patterns across conversations, connects observations to underlying user needs, and translates findings into actionable recommendations.
10
11## When to Use
12
13- After completing a round of user interviews (typically 5+ participants)
14- Following customer discovery calls or sales feedback sessions
15- After usability testing sessions to consolidate observations
16- When stakeholders need a summary of research findings
17- Before ideation sessions to ground the team in user reality
18
19## When NOT to Use
20
21- You are summarizing one internal meeting for its attendees -> use `foundation-meeting-recap`
22- You need patterns across multiple meetings over time -> use `foundation-meeting-synthesize`
23- Your data is survey responses rather than interviews -> use `measure-survey-analysis`
24- The findings are synthesized and you are ready to frame the problem -> use `define-problem-statement`
25- You have synthesized findings and want to map them onto a customer's journey across stages and touchpoints -> use `discover-journey-map`
26
27## Instructions
28
29When asked to synthesize interview findings, follow these steps:
30
311. **Gather the Raw Material**
32 Collect all interview notes, transcripts, or recordings. Ensure you have data from at least 3 participants to identify meaningful patterns. Note the research objective and methodology used.
33
342. **Create Participant Profiles**
35 Document each participant with relevant context: their role, segment, tenure, and any notable characteristics. This helps readers assess the representativeness of findings.
36
373. **Identify Recurring Themes**
38 Read through all notes and tag observations by topic. Look for themes that appear across multiple participants (ideally 3+). Distinguish between frequently mentioned topics and one-off comments.
39
404. **Extract Meaningful Quotes**
41 Capture 3-5 verbatim quotes per theme that powerfully illustrate the insight. Good quotes are specific, emotional, or particularly articulate. Always attribute quotes to participant IDs.
42
435. **Synthesize into Insights**
44 Transform themes into insight statements. An insight goes beyond observation ("users mentioned X") to interpretation ("users need Y because of Z"). Connect what you heard to why it matters.
45
466. **Formulate Recommendations**
47 Based on the insights, propose prioritized actions. Each recommendation should tie directly to an insight. Note confidence level based on strength of evidence.
48
497. **Document Limitations**
50 Acknowledge what you didn't learn, sample biases, or areas needing further research. Honest limitations increase credibility.
51
52## Project Memory Contract
53
54Active only when `.claude/pm-skills.local.md` exists. With no file, ignore this section entirely
55and behave exactly as described above.
56
57- **Reads:** `phase` and `active_initiative`, so findings are framed against the initiative in flight instead of asking you to restate it.
58- **Writes:** the personas and findings as an `interpretation` artifact, so a later skill can consume them without you pasting them again.
59- **Posture:** propose the entry and wait for confirmation before writing, unless
60 `memory_auto_append: true` is set, in which case append and echo what was written.
61- **Write discipline:** re-read the file immediately before writing, never from the copy that
62 produced the proposal. If it changed in between, merge your entry into the current state and
63 re-propose rather than overwriting; add only your own entry and leave every other field and
64 section byte-identical. Nothing enforces this at runtime and the file is gitignored, so a
65 careless whole-file write loses another session's work with no way to recover it.
66
67This is the writer half of the loop the cohort exists to demonstrate: what this skill records, `deliver-prd` later reads.
68## Output Format
69
70Use the template in `references/TEMPLATE.md` to structure the output. A complete synthesis fills every template section: Research Overview; Key Themes; Notable Quotes; Insights; Recommendations; and Appendix.
71
72## Quality Checklist
73
74Before finalizing, verify:
75
76- [ ] Themes are supported by evidence from 3+ participants
77- [ ] Quotes are verbatim and attributed to participant IDs
78- [ ] Insights explain "why" not just "what"
79- [ ] Recommendations are specific and actionable
80- [ ] Participant identities are protected (no PII)
81- [ ] Limitations and biases are acknowledged
82
83## Examples
84
85See `references/EXAMPLE.md` for a completed example.
product-on-purpose