Insight Processor

Insight Processor

Turn raw, messy interview transcripts or notes into a structured insight matrix that a PM or researcher can hand straight to stakeholders.

Workflow

1. Identify inputs

Check what was provided: one file, or several files from the same research project (e.g. multiple interviews for one study). If it's unclear how many files or which ones belong to the same project, ask before proceeding.

2. Read each file

Read the full transcript or notes file. If it's not in your context (only a path was given), use the file-reading skill's guidance to read it properly rather than guessing from the filename.

Note whether interviewees are identified (name, "P1"/"P2", role, segment). If so, carry that identifier through to the matrix. If not, use a generic placeholder like "Interviewee" or the filename.

3. Extract insights against the theme taxonomy

Use this starter taxonomy, but treat it as a hybrid seed list, not a fixed one — if something important doesn't fit, create a new theme rather than forcing it into the wrong bucket:

• Onboarding friction
• Pricing / value confusion
• Feature discoverability
• Trust & credibility concerns
• Workflow interruption / context-switching
• Support & documentation gaps
• Performance / reliability complaints
• Unexpected / workaround behavior (user doing something the product wasn't designed for)

For each distinct insight in the transcript:

• Assign it to a theme (existing or new)
• Write a problem statement: a concise, neutral sentence describing the underlying user problem (not just a restatement of what they said). E.g. "Users can't tell which plan tier includes API access until after signup."
• Pull the best verbatim quote that evidences it. Clean up filler words (um, uh, like, you know) and false starts for readability, but never change the substance, add words the person didn't say, or soften/sharpen their meaning. If cleaning would materially change the claim, keep it closer to verbatim instead.
  • If the source material is paraphrased notes rather than a transcript (no actual quote exists to pull from), do not invent or reconstruct a quote-like fragment. Write "Not directly quoted — paraphrased from notes" in that cell instead. A missing quote is more honest and more useful than a fabricated one.
• Note the source (interviewee identifier / file)
• Flag severity (High / Medium / Low) based on how strongly it blocks the user or how much frustration is expressed
• Note frequency — within a single transcript this is usually 1, but if the same person raises it multiple times, or if you're synthesizing across files, count mentions
• If the insight reflects the user doing something unexpected (a workaround, misuse, or off-label use of the product), flag it explicitly in a Notes column — these are easy to bury and are often the most valuable finds

Don't force coverage — not every part of a transcript contains an insight. Skip small talk, scheduling, and generic praise unless it reveals something concretely useful.

Two insights landing under the same theme name does not mean they're the same insight. If two sources raise "onboarding friction" but one is about permission scoping and the other is about template collaborators, keep them as separate rows with separate problem statements — don't merge or generalize them into a vaguer shared statement just because the theme label matches.

If two rows are causally linked — one insight is a direct downstream consequence of another, like a data-trust issue leading to a workaround, or a workaround leading to a support burden — keep them as separate rows (each should stand on its own), but note the link explicitly in the Notes column of the downstream row, e.g. "Downstream consequence of [other row's problem statement]." Don't silently leave the connection implicit; it's often the most actionable part of the story.

4. Output the matrix

Output as a markdown table with these columns:

| Theme | Problem Statement | Verbatim Quote | Source | Severity | Frequency | Notes / Unexpected Behavior |

Put this directly in the conversation (not as a file) unless the user asks for a downloadable version. If the table is long, it's still fine as one markdown table — don't split it up.

After the table, add a short (3-5 bullet) "Top signals" summary above or below it, calling out the highest-severity or most-recurring items — this is what busy stakeholders will actually read first.

5. Multiple files from the same project

Process each file into its own matrix first. Once all files are done, ask the user whether they want a combined cross-interview matrix that merges recurring themes and rolls up frequency counts across sources. Don't combine automatically — some users want to review each interview individually first.

When building the combined matrix:

• Keep genuinely distinct insights as separate rows even if they share a theme name (see the note above — this applies across sources too, not just within one).
• Report frequency as "X of N interviews" rather than a raw count, so it's clear how many separate sources corroborate the insight versus how often one person repeated themselves.
• If the same insight is corroborated across sources but they'd individually earn different severity ratings (e.g. a small team calls it "annoying," a security-conscious enterprise calls the same bug "high severity"), don't flatten them to one rating. Report the range or the higher end (e.g. "Medium–High, varies by org size") and note in the Notes column what's driving the difference — that context is often exactly what a stakeholder needs to prioritize correctly.
• Watch for cross-cutting patterns: cases where the same kind of behavior (not the same literal insight) shows up independently across multiple sources — e.g. two unrelated interviewees both repurposing a feature for something it wasn't built for, even if it's a different feature each time. This is a stronger signal than any single instance and is easy to miss if you only merge identical rows. Call it out explicitly in the Top Signals summary.

Notes

• If a transcript is ambiguous about who is speaking (interviewer vs. interviewee), do your best from context (questions vs. answers) and flag any genuinely unclear attributions rather than guessing silently.
• Preserve participant anonymity conventions already used in the source (e.g. if the file says "P3," keep using "P3," don't invent a name).
• If asked to prioritize a fixed roadmap or score business impact, that's out of scope for this skill — it produces the raw insight matrix; prioritization against business goals is a separate step for the user.