How to Build a User Research Claude Skill for PMs
Twelve interview transcripts. A roadmap meeting Friday. You're not getting the themes done in time, again. A Claude Skill for user research synthesis is what makes that math work. Here's how to build one.
Why User Research Is a Perfect Use Case for Claude Skills
Most PM workflows are some mix of judgment and repetition. User research synthesis is heavily on the repetition side. The same shape of input (transcripts, interview notes, raw quotes) flows through the same shape of analysis (themes, pain points, jobs-to-be-done) into the same shape of output (a structured synthesis the team can actually act on). What changes from project to project is the content, not the process.
That's exactly what Skills are for. A research synthesis Claude Skill encodes the framework you'd apply manually, then runs it against whatever transcripts you feed in. The output quality depends almost entirely on how disciplined your framework is, which is a thing you can write down once and reuse forever.
There's another reason this workflow is a fit. Research synthesis quality varies wildly between teams, but most of the variance comes from inconsistent framework application, not from how thoughtful the researcher is. A Skill enforces the framework every time. Even on a Tuesday afternoon when you're tired and behind on three other deliverables.
What a Good Research Skill Actually Does
A working user research Claude Skill takes raw input and returns a structured synthesis. Specifically:
Input it accepts. Interview transcripts, cleaned or raw. Session notes. A folder of multiple files. A pasted quote block. Whatever format your team actually captures.
Analysis it runs. Theme extraction. Pain point identification. Surprising-quote isolation (the verbatims worth surfacing in your readout). Framework application. The framework is the part you encode in the Skill.
Framework it applies. Jobs-to-be-done, jobs-pains-gains, opportunity sizing, or whatever your team uses. The Skill should know your team's preferred lens, not just generic research methodology.
Output it returns. A structured synthesis. Not "here are some interesting things people said." A real document with themes ranked by frequency, customer quotes attached as evidence, and recommendations grounded in what was actually observed.
The Skill shouldn't invent insights. If five interviews mention onboarding friction, that's a finding. If only one person mentioned it, that's a quote, not a theme. Encoding the difference between those two is what separates a useful research Skill from a Claude-flavored summary.
The Components of a User Research Skill
The Skill folder needs three files: SKILL.md, INTERVIEW_TEMPLATE.md, and OUTPUT_TEMPLATE.md. Optionally, a fourth file (FRAMEWORKS.md) for the methodology library.
SKILL.md holds the instructions and the trigger description. INTERVIEW_TEMPLATE.md is the format Claude expects interview notes to come in (or the format Claude should normalize raw input to, before analysis starts). OUTPUT_TEMPLATE.md is the format the final synthesis takes.
Here's a working SKILL.md to copy and adapt:
[CODE BLOCK GOES HERE — use the Webflow Embed HTML below]
The trigger description is the most important part of the file. Vague descriptions like "analyzes research" cause the Skill to either misfire on unrelated requests or never fire when you need it. Name the specific phrases your team uses to ask for synthesis.
Teaching Your Skill the Frameworks You Trust
A research Claude Skill is only as good as the framework you encode in it. Most teams already have a methodology they trust, but it lives in someone's head, not in a document Claude can read.
Take jobs-to-be-done as an example. The framework has three dimensions: functional (what the customer is trying to accomplish), emotional (how they want to feel), and social (how they want to be perceived). A research Skill that applies JTBD properly needs to call out all three for each major theme. Most AI-drafted research syntheses only do functional, which is why they feel flat.
Encode the framework as a short reference file (FRAMEWORKS.md) that SKILL.md points to. Don't write a textbook. A page of clear definitions, an example of the framework applied to a fake interview, and three rules for when to deviate is enough. Claude reads the reference when the Skill triggers, so you're not paying for the context every conversation.
The same approach works for any framework: jobs-pains-gains, opportunity sizing, RICE applied to qualitative findings. Encode the rules. Show one worked example. Let Claude do the rest.
How to Test Your Research Skill on Real Transcripts
The best way to test a research Skill is to run it on an old project where you already know the conclusion. Pick a study you ran six months ago. Feed the original transcripts into the Skill. Compare what comes out to the synthesis your team actually shipped.
Watch for three things.
Did it find the same themes? If your manual synthesis identified onboarding friction and pricing confusion as the top two themes, the Skill should land in the same neighborhood. If it finds five themes that don't match yours at all, the framework instructions are too loose.
Did it surface the surprising stuff? Good research syntheses include at least one quote that made the team rethink something. If the Skill output is all confirmations and no surprises, it's filtering for what you already believe instead of what the customers actually said.
Did it respect the threshold rules? If your SKILL.md says themes need three sessions of evidence, check that one-off observations got correctly labeled "interesting but not validated." If the Skill is promoting single quotes to themes, the rule isn't tight enough.
This is also where understanding how to quantify qualitative feedback matters. Themes that aren't grounded in frequency are opinions wearing research clothing. A Skill that respects the threshold rule is the difference between research that holds up in a roadmap meeting and research that gets challenged the moment leadership pushes back.
Where to go from here
A research Claude Skill is the front end of the discovery workflow. The natural next step is feeding what comes out of it into a PRD Skill that drafts product requirements documents using the same customer language. Together, the two Skills compress the gap between "we just finished interviews" and "we have a spec engineering can build."
Frequently asked questions about building a user research Claude Skill
What does a Claude Skill for user research actually do?
A user research Claude Skill takes raw qualitative data, interview transcripts, session notes, or open-ended survey responses, and returns a structured synthesis. The output includes themes ranked by frequency, customer quotes as evidence, and framework-applied analysis like jobs-to-be-done. The Skill enforces your team's methodology every time, so the synthesis is consistent across PMs and studies.
How is a user research Skill different from just asking Claude to summarize interviews?
A summary smooths everything out. A research Skill enforces structure. The Skill knows your threshold for what counts as a theme versus a one-off quote, applies the framework your team uses (like JTBD), and returns a document in your team's standard synthesis format. A summary gives you "here's what people said." A Skill gives you "here are the three themes worth acting on, with evidence."
Can a Claude user research Skill handle multiple interview transcripts at once?
Yes. The Skill reads all input transcripts before doing any analysis, then identifies themes that appear across multiple sessions. The recommended threshold is three sessions of evidence for something to count as a theme. Anything below that gets flagged separately as a one-off observation worth investigating further but not yet validated.
What frameworks should I encode in my user research Skill?
Start with the framework your team already uses. Jobs-to-be-done is the most common, with three dimensions: functional, emotional, and social. Jobs-pains-gains and opportunity sizing are good follow-ups. Don't write a research textbook in the Skill instructions. Write the rules your team applies in practice, with one worked example, and let Claude pattern-match from there.
How do I keep the Skill from inventing customer quotes?
Add a rule to SKILL.md that says Claude must use verbatim quotes from the input transcripts. If a real quote isn't available, the Skill should leave a clearly marked placeholder like [QUOTE NEEDED] instead of generating one. This single rule, enforced consistently, is the difference between research that holds up in review and research that quietly hallucinates customer language.
