WHAT THIS PHASE PRODUCES
You leave with
- A synthesis doc that grades the hypothesis against the pre-registered rule
- A list of the strongest dissenting evidence
- A written iterate-or-commit decision your advisors can read in five minutes
THE MENTAL MODEL
How to think about this phase
Synthesize is where the loop pays off. Done well, you leave with a graded bet and a written decision. Done badly, you leave with a folder of chat logs and a rationalisation.
The honest move is to grade the hypothesis against the rule you set in Test, not against the result you wish you’d gotten. If the rule failed, the bet is wrong as stated, even if a different bet inside the same general space might still be alive. Naming the wrong bet correctly is what makes the next loop sharp.
Look hardest at the dissenting evidence. The customer who hated it, the one who asked “what about X”, the one who paused for ten seconds before answering: those are the seams the next iteration must address. Pattern-matching only the wins gives you a confident wrong answer.
End with a written iterate-or-commit decision. Iterate means a refined hypothesis enters Loop 2 with the carry-forward artifacts wired up. Commit means the bet survived enough pressure to graduate into a real engineering effort. There is no third option called “keep going as is”. That is how loops become months.
PRACTICE PROMPTS
Paste these into plain Claude or ChatGPT
Grade the bet against the pre-registered rule
Pre-registered decision rule: "<paste from Test>" Transcripts (or your structured notes from each session): "<paste>" Do three things, in order: 1. Tally the rule literally. Did it pass, partially pass, or fail? Quote the exact transcript moments behind the tally. 2. List the three strongest dissenting data points, not the supportive ones. 3. Name the bet I'm tempted to substitute mid-grading and tell me why I should not let myself.
Surface patterns and seams
Across these transcripts: "<paste>" Find: - The single behavior 3+ participants exhibited that I did not expect - The 2 most common workarounds participants described - The phrasing or vocabulary they used that I should adopt before Loop 2 - The seam (the place the prototype broke down) that the next iteration must address first Do not summarize the transcripts. Surface the patterns I missed.
Write the iterate-or-commit decision
Given the grading and the patterns, write a 200-word decision doc my advisors can read in 5 minutes. It must contain:
- The one-line graded outcome ("PASS / PARTIAL / FAIL")
- The two strongest reasons for the call (with transcript evidence)
- The one strongest reason against
- The decision (iterate or commit) and the single sentence that would have flipped me to the other side
- If iterate: the refined hypothesis for Loop 2 in one sentence
- If commit: the first three engineering decisions the validated bet implies
No hedging. No "we should consider".Turn discovery calls into themes, priorities, and a build prompt
You are analyzing customer discovery call transcripts for my product.
My goal is to understand how users respond to my product's features and what that means for what we build next.
**Instructions:**
Focus only on feedback about my product, its features, or workflows. Do not include general "state of the world" insights unless they are explicitly tied to a feature reaction, request, or product gap.
Group insights into 2 to 5 themes. For each theme:
Give it a 2 to 4 word title with a relevant emoji and a signal count in parentheses showing how many distinct people mentioned it (e.g. "4 of 6 participants").
List 1 to 3 representative quotes as bullets. Format each as:
"[quote]" - [persona descriptor] · [Positive / Frustrated / Request]
Then on a new line, write a **Design Implication**: a specific, actionable takeaway tied directly to product strategy. State whether to build, improve, emphasize, or cut something. Call out any tradeoffs.
After all themes, add a **Priority Signal** section with 3 ranked actions: what to address first, second, and third, based on frequency and emotional intensity across the themes.
Finally, generate a **Vibe Coding Revision Prompt**: a single, self-contained prompt ready to paste directly into any AI coding tool. It should:
- Open with the current state: "The existing design has [brief description]"
- List only the Priority Signal changes as specific UI instructions, in order
- Exclude everything that is not being changed
- Close with: "Do not change anything else. Preserve all existing layout, copy, and interactions not mentioned above."
**Example:**
**Vibe Coding Revision Prompt**
The existing design has a single-link feedback collector with a flat list of responses and no filtering.
Make the following changes in priority order:
1. Add a filter bar above the response list with two toggle options: "Internal" and "Client." Default to showing all responses. Selecting a toggle filters the list in place.
2. Add a persistent header to each response card showing reviewer type (Internal / Client) as a small label in the top right corner.
3. Group responses by reviewer type when a filter is active, with a section label ("Internal Feedback" / "Client Feedback") above each group.
Do not change anything else. Preserve all existing layout, copy, and interactions not mentioned above.Run it as a Granola recipePaste a prompt into Claude or ChatGPT, then replace the bracketed placeholders with your own work. Free, no signup required.
FREE AGENTS
Run a free Synthesize agent
COMMON TRAPS
What goes wrong in this phase
- Grading against a softer rule than the one you set in Test. This is the most common form of self-deception in the loop.
- Counting enthusiastic participants twice in your head and skeptical ones half. Your synthesis must use literal counts.
- Letting the decision linger. A loop without a written close becomes context the next loop has to relearn.
- Writing the synthesis doc only for yourself. Write it for an advisor. That constraint forces honesty.
WHAT GOOD LOOKS LIKE
A worked example
SETUP
From the Test example: 10 PM sessions, paste rate 7/10, share rate 2/10 against thresholds of 6 and 4.
OUTPUT
After Synthesize: a one-page doc that reads, in part, “Decision: iterate. The paste behavior is real (7/10, transcripts confirm they pasted live problems, not toy ones). The share behavior failed because the generated outline was useful but not branded enough to feel safe to forward. Loop 2 hypothesis: when the outline is rendered with the team’s shared vocabulary and a one-click ‘share to Slack thread’ flow, share rate clears 4/10 in another 10 sessions. Refined P0 next loop: vocabulary detection + Slack share. Carry-forward: the 10 transcripts, the 7 confirmed pasters as recruitable Loop 2 contacts.”