| name | synthesise-interviews |
| description | Pattern-code a window of discovery interviews into themes, update opportunity solution tree nodes, and flag theme saturation. Produces a synthesis that turns raw interview notes into discovery decisions. Use after running several interviews to convert conversation into opportunity nodes. |
| argument-hint | [the set of interviews or the time window to synthesise] |
| user-invocable | true |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep |
Synthesise the interviews in $ARGUMENTS.
Discovery without synthesis is just conversation. This skill turns a window of interviews into themes, maps
those themes onto the Opportunity Solution Tree,
and flags when themes have saturated — the point where new interviews stop yielding new themes. It is the
analysis counterpart to the generative interview (/product-manager:write-interview-guide) and switch
interview (/product-manager:switch-interview) skills.
Follow every step. The output is a synthesis with updated OST nodes and a saturation call.
Step 1: Assemble the interview window
Gather the interviews to synthesise — typically the last three to four, matching the OST update cadence, or
a defined window from docs/product/discovery-log.md. List participant, segment, interview type, and date.
This step is complete when the window is listed.
Step 2: Pattern-code the notes
Read every interview and tag recurring observations. Code at the level of customer need and behaviour, not
solution requests:
- A customer saying "I wish it had a bulk button" → code the underlying need: "reconciling records one at a
time is too slow at their volume", not "wants a bulk button"
- Tag each coded observation with the participant it came from, so a theme's support is traceable
Group codes into themes. A theme is a pattern seen across multiple participants, not a single strong quote.
This step is complete when observations are coded and grouped into candidate themes.
Step 3: Test each theme for support and disconfirmation
For each theme, count how many participants support it and actively look for disconfirming evidence — a
participant who didn't have the problem, or solved it differently. A theme every participant supports with
zero discards is a warning: it may be a confirmation-bias artifact of leading questions rather than a real
pattern. Note the discard rate. This step is complete when every theme has a support count and a
disconfirmation check.
Step 4: Update the opportunity solution tree
Map themes onto the OST (/product-manager:write-opportunity-solution-tree). For each theme that meets the
branch criteria (connected to the outcome, surfaced by research, specific enough to act on):
- New pattern → add an opportunity node, citing the interviews
- Strengthened pattern → note the added evidence on the existing node
- Contradicted pattern → flag the node for review; don't silently keep it
This step is complete when the OST reflects the window's evidence and every change cites its interviews.
Step 5: Call theme saturation
Compare this window's themes to prior windows. If new interviews are producing themes already on the tree
and few or no new ones, the segment is approaching saturation (typically 20-30 interviews across a
homogeneous segment reaches 90-95%). State whether to:
- Continue in this segment (still finding new themes)
- Saturated — move to a new segment or shift from generative to evaluative/concept testing
This step is complete when a saturation call is recorded.
Rules
- Code needs, not feature requests. A customer's proposed solution is data about their need, not a
requirement. Always translate up to the underlying job.
- A theme needs multiple participants. One vivid quote is an anecdote. A pattern across participants is
a theme. Don't promote anecdotes.
- Actively seek disconfirmation. A zero-discard synthesis means the interviews were confirmatory. Note
who didn't fit the theme.
- Every OST change cites its interviews. An opportunity node with no source is an assumption wearing a
research costume.
- Saturation is a decision, not a feeling. Base it on the rate of new themes, and write the call down.
- Don't synthesise toward your prior plan. If every theme conveniently supports what you already wanted
to build, re-examine the coding.
Output Format
Write to docs/product/synthesis-[window].md:
# Interview synthesis: [window]
## Window
| Participant | Segment | Type | Date |
|-------------|---------|------|------|
| ... | ... | generative / switch | ... |
## Themes
| Theme (need-level) | Participants supporting | Disconfirming | Discard rate |
|--------------------|-------------------------|---------------|--------------|
| ... | 4/5 | 1 | 20% |
## OST updates
| Change | Node | Source interviews |
|--------|------|-------------------|
| Added opportunity | ... | ... |
| Strengthened | ... | ... |
| Flagged (contradicted) | ... | ... |
## Saturation call
[Continue in segment / Saturated — move to next segment] — [reasoning based on rate of new themes]
Related Skills
/product-manager:write-interview-guide — the generative interviews this synthesises./product-manager:switch-interview — switch interviews also feed this synthesis./product-manager:write-opportunity-solution-tree — the artifact this skill updates./product-manager:strategic-voc-synthesis — validates synthesised hypotheses against broader VoC signal.
