Discovery Synthesis

Discovery synthesis

Core principle

Synthesis is the traceable path from a thing a person said or did to a claim a team acts on. Every step of that path stays auditable. If a reader cannot get from a finding back to the specific segments that produced it, the finding is an opinion with citations attached.

The failure this prevents: reading the transcripts, forming an impression, and then selecting quotes that support the impression. That process feels like synthesis and is indistinguishable from it in the output.

The pipeline

raw sources → segments → codes → categories → themes → opportunities → tree
     |            |         |         |           |          |
   dated      one idea   labelled  grouped    named &     customer
   & coded    per unit   with an   by shared  counted     language,
              of meaning  ID        meaning              sourced

Never skip from raw to themes. The middle is what makes the output auditable, and it is also what makes disconfirming evidence visible.

Step by step

1. Inventory the corpus. Source, type, date, participant code, segment, and the sampling frame that produced it. Sources with no provenance are excluded, not fixed.

2. Segment. Cut into units of meaning. One idea per segment. Keep the verbatim text and a locator (participant code plus timestamp or line number). Never paraphrase at this step; the paraphrase becomes the quote later.

3. Code openly. First pass, inductive: label what is there, in the participant's language, not in your product's. Codes are short, specific, and describe a behaviour, a pain, a workaround, a context or a desired outcome.

4. Build the codebook. Name, definition, inclusion rule, exclusion rule, one anchor example. Written down. Without an explicit codebook, coding drifts across the corpus and across coders, and nobody can tell later.

5. Code the rest against the codebook, adding codes where genuinely new. Track new codes per source; that curve is your saturation measure.

6. Check reliability. A second coder on 15-20 percent of segments. Report agreement. Where an AI does the first pass, a human recodes a sample and the disagreements are resolved into the codebook, not averaged away.

7. Categorise, then theme. Group codes by shared meaning. A theme is a pattern that says something about the research question, carried by multiple sources.

8. Count. Sources per theme, out of total sources. Not percentages below n=30.

9. Hunt for disconfirmation. Which sources contradict each theme? Who in the sample does not fit? Who is absent from the sample entirely?

10. Convert to opportunities. Customer language, tied to a moment, no product nouns.

11. Place on the tree. Under one outcome. See references/opportunity-solution-tree.md.

Full protocol, codebook format, and the AI-assisted coding rules in references/coding-protocol.md.

Saturation, measured

Stop when new sources stop producing new codes, not when you feel finished or when the calendar says so.

Plot new codes per source in order. The curve flattens as you approach saturation. Two consecutive sources adding zero new codes in a segment is a reasonable stopping rule for problem discovery within that segment.

../discovery-quant/scripts/qual_saturation.py computes and plots it from a codes CSV.

Saturation is per segment. A flat curve in one segment says nothing about another.

Themes versus opportunities

Both are needed. Themes structure the readout, opportunities structure the work.

Counting rules

Count sources, not mentions. One person saying something six times is one source. This single rule prevents more overclaiming than any other.

Output

Research readout per ../product-discovery/templates/research-readout.md, with:

• The answer first, with its confidence level
• Method, sample, sampling frame, dates
• Findings with source counts and evidence ids
• Disconfirming evidence, never omitted
• Saturation statement: reached, not reached, or not applicable, with the numbers
• What we still do not know, ranked
• Open assumptions

Output

Terse by default. One line per point, not a paragraph per point. Prose only where a number would be misread without a sentence of context.

No preamble, no restating the request, no closing summary of what you just said. Drop any section that would be empty rather than filling it.

Ask when a missing answer changes the recommendation, not otherwise. Use the AskUserQuestion tool where the runtime has it and the choice is a real fork between two to four known options, recommendation first. Ask in plain numbered text for open-ended facts only the user holds. Ask nothing where a sensible default exists: state the assumption inline and move on.

Full contract and word ceilings: ../product-discovery/SKILL.md, Output contract.

Read next

Red flags

• A theme with one source behind it
• A quote you cannot locate in the corpus
• A percentage from fewer than 30 sources
• An empty disconfirming section
• Codes that use your product's vocabulary
• An opportunity containing a screen name, a feature name, or a technology
• Synthesis finished in an hour on a corpus of twenty transcripts
• Every finding supports the plan that existed before the research