Skill: Turning Customer Interview Notes into a Real Product Insight Memo

---
name: customer-interview-insight-memos
description: Turn raw customer interviews, research notes, call transcripts, and synthesis inputs into decision-useful product insight memos. Use this skill when the user asks to summarize interviews, synthesize themes, write a research readout, draft an insight memo, turn quotes into recommendations, separate signal from noise, frame findings in JTBD or user-need terms, prepare stakeholder-ready findings, or convert a pile of interview notes into evidence-backed product decisions. Trigger even when the user asks for a "research summary," "customer insights," "what did we learn from interviews," "recommendations from calls," or "a memo for product/design/leadership."
---
# Customer Interview Insight Memos
Convert interview evidence into a memo that helps a product team decide what appears true, why it matters, what to do next, and what still needs validation.

## Instructions
Follow this process whenever you are asked to turn interviews into an insight memo.
1. Start from raw evidence, not memory. Read the transcripts, notes, clips, or observations before you synthesize. If the input is partial or secondhand, say so and lower confidence accordingly.[11]
2. Identify the decision the memo must inform before coding themes. Write the decision question in one sentence and keep it visible while you work. This prevents the memo from becoming a bucket of interesting observations.[11][5]
3. Code observations and quotes before drafting conclusions. Use descriptive codes for what happened and interpretive codes for what it seems to mean.[11]
4. Cluster codes into themes, but do not force neat buckets. Small clusters may still matter if they indicate a severe issue, a segment-specific failure, or a new opportunity.[17][16]
5. Write theme labels as claims, not filing labels. Prefer short sentence-like takeaways with a verb, such as "Ops leads lose triage confidence when signals are split across tools," not "Dashboard feedback."[16]
6. Weight evidence before you elevate it into a finding. Consider who said it, whether the feedback was prompted or unprompted, whether it repeated, what stakes were involved, and whether behavior matched the claim.[14][15]
7. Keep every claim traceable to recoverable evidence. Maintain a lightweight evidence table behind the scenes with an evidence ID, participant or account, source session, date, quote or observation, code, and confidence notes.[11][12][13]
8. Select quotes to support analysis, not replace it. Choose short quotes that crystallize a recurring pattern, capture the customer’s language for a high-stakes problem, or illustrate an important exception.[5][9][10]
9. Translate solution-shaped requests into need statements when the real decision is about what problem to solve. Use JTBD or user-need framing only when it clarifies the job, constraints, and desired outcomes. If the data only supports a narrower pain point, state the pain point directly.[7][8]
10. Test themes against contradictions and outliers before you recommend action. Check whether the conflict is a true market difference or a method artifact caused by participants, tasks, logistics, or analysis choices.[6][5]
11. Separate findings from recommendations. State what appears true first, then explain what to do, for whom, with what confidence, and what tradeoffs or follow-up questions remain.[3][2][4][5]
12. End with action levels. Distinguish between product change now, exploration next, and open questions later. This keeps weak signals from being overstated and keeps strong signals from dissolving into vague follow-up.[2][3][4]

## Report structure
ALWAYS use this exact template unless the user explicitly requests a different format:
```md
# [Decision-focused memo title]
## Executive summary
- Decision this memo informs
- 2-4 claims stated plainly
- Recommended action level: Product change / Exploration needed / Open question
- Main risk or tradeoff
## Decision and scope
- What decision is being made
- Which users, workflows, and evidence are in scope
- What is out of scope
## Key claims
### Claim 1: [short sentence takeaway]
- Why this appears true
- Evidence: [2-4 brief evidence bullets or quotes]
- Confidence: High / Medium / Low
- Segment or workflow notes
- Contradictions or exceptions
### Claim 2: [short sentence takeaway]
- Why this appears true
- Evidence: [2-4 brief evidence bullets or quotes]
- Confidence: High / Medium / Low
- Segment or workflow notes
- Contradictions or exceptions
## Implications
- What this means for the product, workflow, or segment
- What tradeoffs the team must accept or test
## Recommendations
### Now
- Specific product change or decision to make now
- Why now
- Owner or likely owner if known
### Next
- Follow-up exploration, prototype, or instrumentation
- What uncertainty it resolves
### Later / Open questions
- Important unknowns that should not be overstated
## Appendix: evidence log
- Evidence ID
- Participant/account/segment
- Source interview or note
- Date
- Quote or observed behavior
```
```[5][3][18][2]
If the user already has a memo format, preserve it but still enforce the same logic: claims before recommendations, evidence under each claim, and explicit uncertainty.[5][3][18]

## Worked examples
**Example 1: Repeated feature requests mask a coordination job**
Input:
- Decision question: Should repeated requests for CC/BCC-style support justify prioritizing a native multi-party conversation feature?
- Evidence E1: "I don’t actually need a CC field. I need everyone involved in resolving the issue to see the same context so I’m not re-explaining it in three places."
- Evidence E2: "When legal needs to approve a response, we copy the thread into email because the conversation tool doesn’t keep internal reviewers in the loop."
- Evidence E3: "If the account owner is out, nobody can see what was promised unless we forward screenshots around."
- Observed pattern: Teams route conversation context through email or screenshots when they need shared visibility or approval.[7][13][19]
Output:
```md
# Shared context matters more than a CC field
## Executive summary
- Decision: whether to build native multi-party conversation support now.
- Claim: repeated CC/BCC requests are evidence of a coordination problem, not proof that an email-style field is the right solution.
- Action level: Exploration needed.
- Main risk: building the familiar request may lock the team into the wrong interaction pattern.
## Decision and scope
- In scope: support and operations workflows where multiple internal stakeholders need visibility on a live customer issue.
- Out of scope: full redesign of external email collaboration.
## Key claims
### Claim 1: Teams use side channels because the product does not preserve shared context during resolution.
- Why this appears true: participants describe re-explaining issues, moving threads into email, and forwarding screenshots when approvals or handoffs are needed.
- Evidence:
  - "I don’t actually need a CC field..."
  - "When legal needs to approve a response..."
  - Teams route context through email or screenshots for approval and continuity.
- Confidence: Medium
- Contradictions or exceptions: current evidence supports the job strongly, but does not yet prove which collaboration pattern will work best.
## Implications
- The product is failing at internal coordination, continuity, and shared visibility.
- Solving only the requested surface feature may preserve the workaround instead of fixing the workflow.
## Recommendations
### Now
- Do not approve "add CC/BCC" as the headline recommendation.
### Next
- Test concepts that keep shared context and internal collaboration inside the conversation workflow.
### Later / Open questions
- Which interaction pattern best supports approvals, continuity, and accountability across roles?
```
This example shows how to reframe solution-shaped requests into the underlying job without overclaiming the final product answer.[7][19]
**Example 2: Repeated workflow friction supports a narrower recommendation**
Input:
- Decision question: Should the team prioritize a unified triage view for operations leads, or are requests for a dashboard still too vague?
- Evidence E1: "Every morning starts with opening several tabs. By the time I compare statuses, the urgent account has already changed."
- Evidence E2: "I don’t need more charts. I need one place that tells me what needs attention first."
- Evidence E3: An analyst copies account IDs from one tool into another to confirm whether an alert is still current before escalating it.
- Synthesized observation: Across interviews, the repeated desired outcome is faster triage confidence, not better-looking reporting.[7][13][19]
Output:
```md
# Fragmented triage slows intervention
## Executive summary
- Decision: whether to prioritize a unified triage view for operations leads.
- Claim: the core problem is fragmented triage, not the absence of charts.
- Action level: Product change.
- Main risk: a broad dashboard project could expand beyond the current evidence.
## Key claims
### Claim 1: Ops leads lose triage confidence when risk signals are spread across tools.
- Why this appears true: interviews and observed workarounds show repeated cross-tool comparison before escalation.
- Evidence:
  - "Every morning starts with opening several tabs..."
  - "I don’t need more charts..."
  - Analysts verify alerts by copying IDs between tools.
- Confidence: High
- Segment notes: strongest for operations leads doing current-state prioritization.
## Implications
- The first product win is faster prioritization in one current view, not richer reporting.
## Recommendations
### Now
- Prioritize a narrowly defined unified triage view optimized for current-state prioritization and drill-down to source details.
### Next
- Validate which signals must appear in the first version and which can remain linked.
### Later / Open questions
- Does this need extend beyond operations leads to account managers or support leadership?
```
This example shows when the evidence is strong enough to move from abstract need framing to a narrower workflow recommendation.[7][19]

## Gotchas
- Do not write from memory when transcripts, notes, or clips exist.[11]
- Do not treat the loudest or most vivid quote as the finding. Anecdotes persuade, but they can distort weighting if they are not backed by repetition, stakes, or behavioral evidence.[9][14]
- Do not cluster by shared words alone. Cluster by meaning, workflow, cause, or outcome.[16]
- Do not label themes with bucket nouns like "navigation," "dashboard," or "reporting." Write what is actually happening or failing.[16][7]
- Do not hide contradictions to make the story cleaner. Name whether the conflicting evidence is a real segment difference, a situational exception, or a method problem.[5][6]
- Do not smuggle solutions into findings. "Customers need a dashboard" is usually weaker than "Ops leads need one place to triage current risk."[7]
- Do not collapse all recommendations into one priority bucket. Strong evidence may justify product change now; weaker evidence may justify exploration or instrumentation instead.[14][2]
- Do not let the memo become an archive dump. Store evidence atomically elsewhere if needed, then write one coherent decision artifact for the question at hand.[13]

## Writing style
- Write for a product decision-maker, not for a research methods class. Lead with the answer, then show the evidence.[3][18][5]
- Keep claims short, specific, and falsifiable. Prefer "New admins lose setup confidence when billing and permissions are split" over "Onboarding feedback was mixed."[16][18]
- Use quotes sparingly. One good quote per claim is usually enough if the rest of the evidence is summarized well.[5][9][18]
- State confidence explicitly. Use high when evidence converges across participants or behaviors, medium when the pattern is plausible but still partial, and low when the memo is mostly directional.[5][14][6]
- Name tradeoffs when they matter. A recommendation can improve one workflow while creating burden for another segment.[6]