If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

• Pasted text: Interview notes, transcripts, survey responses, feedback
• Uploaded files: Research documents, spreadsheets, recordings summaries
• ~~knowledge base (if connected): Search for research documents, interview notes, survey results
• ~~user feedback (if connected): Pull recent support tickets, feature requests, bug reports
• ~~product analytics (if connected): Pull usage data, funnel metrics, behavioral data
• ~~meeting transcription (if connected): Pull interview recordings, meeting summaries, and discussion notes

• What type of research? (interviews, surveys, usability tests, analytics, support tickets, sales call notes)
• How many sources / participants?
• Is there a specific question or hypothesis they are investigating?
• What decisions will this research inform?

• Key observations: What did users say, do, or experience?
• Quotes: Verbatim quotes that illustrate important points
• Behaviors: What users actually did (vs what they said they do)
• Pain points: Frustrations, workarounds, and unmet needs
• Positive signals: What works well, moments of delight
• Context: User segment, use case, experience level

• High frequency + High impact: Top priority findings
• Low frequency + High impact: Important for specific segments
• High frequency + Low impact: Quality-of-life improvements
• Low frequency + Low impact: Note but deprioritize

• Methodology: what types of research, how many participants/sources
• Research question(s): what we set out to learn
• Timeframe: when the research was conducted

• Finding statement: One clear sentence describing the insight
• Evidence: Supporting quotes, data points, or observations (with source attribution)
• Frequency: How many participants/sources support this finding
• Impact: How significantly this affects the user experience or business
• Confidence level: High (strong evidence), Medium (suggestive), Low (early signal)

• Segment name and description
• Key characteristics and behaviors
• Unique needs and pain points
• Size estimate if data is available

• What user needs are unmet or underserved
• Where do current solutions fall short
• What new capabilities would unlock value
• Prioritized by potential impact

• What to build, change, or investigate further
• Tied back to specific findings
• Prioritized by impact and feasibility

• Gaps in understanding
• Areas needing further investigation
• Suggested follow-up research methods

• Ask if any findings need more detail or different framing
• Offer to generate specific artifacts: persona documents, opportunity maps, research presentations
• Offer to create follow-up research plans for open questions
• Offer to draft product implications (how findings should influence the roadmap)

1. Familiarization: Read through all the data. Get a feel for the overall landscape before coding anything.
2. Initial coding: Go through the data systematically. Tag each observation, quote, or data point with descriptive codes. Be generous with codes — it is easier to merge than to split later.
3. Theme development: Group related codes into candidate themes. A theme captures something important about the data in relation to the research question.
4. Theme review: Check themes against the data. Does each theme have sufficient evidence? Are themes distinct from each other? Do they tell a coherent story?
5. Theme refinement: Define and name each theme clearly. Write a 1-2 sentence description of what each theme captures.
6. Report: Write up the themes as findings with supporting evidence.

1. Capture observations: Write each distinct observation, quote, or data point as a separate note
2. Cluster: Group related notes together based on similarity. Do not pre-define categories — let them emerge from the data.
3. Label clusters: Give each cluster a descriptive name that captures the common thread
4. Organize clusters: Arrange clusters into higher-level groups if patterns emerge
5. Identify themes: The clusters and their relationships reveal the key themes

• One observation per note. Do not combine multiple insights.
• Move notes between clusters freely. The first grouping is rarely the best.
• If a cluster gets too large, it probably contains multiple themes. Split it.
• Outliers are interesting. Do not force every observation into a cluster.
• The process of grouping is as valuable as the output. It builds shared understanding.

• Methodological triangulation: Same question, different methods (interviews + survey + analytics)
• Source triangulation: Same method, different participants or segments
• Temporal triangulation: Same observation at different points in time

• Distinguish between behaviors (what they do) and attitudes (what they think/feel)
• Note context: when, where, with whom, how often
• Flag workarounds — these are unmet needs in disguise

• Good quotes are specific and vivid, not generic
• Attribute to participant type, not name: "Enterprise admin, 200-person team" not "Sarah"
• A quote is evidence, not a finding. The finding is your interpretation of what the quote means.

• Behavioral observations are stronger evidence than stated preferences
• If a participant says "I want feature X" but their workflow shows they never use similar features, note the contradiction
• Look for revealed preferences through actual behavior

• Emotional language: frustration, excitement, resignation
• Frequency: how often do they encounter this issue
• Workarounds: how much effort do they expend working around the problem
• Impact: what is the consequence when things go wrong

• Look for patterns: which observations appear across multiple participants?
• Note frequency: how many participants mentioned each theme?
• Identify segments: do different types of users have different patterns?
• Surface contradictions: where do participants disagree? This often reveals meaningful segments.
• Find surprises: what challenged your prior assumptions?

• Response rate: How representative is the sample? Low response rates may introduce bias.
• Distribution: Look at the shape of responses, not just averages. A bimodal distribution (lots of 1s and 5s) tells a different story than a normal distribution (lots of 3s).
• Segmentation: Break down responses by user segment. Aggregates can mask important differences.
• Statistical significance: For small samples, be cautious about drawing conclusions from small differences.
• Benchmark comparison: How do scores compare to industry benchmarks or previous surveys?

• Treat open-ended responses like mini interview notes
• Code each response with themes
• Count frequency of themes across responses
• Pull representative quotes for each theme
• Look for themes that appear in open-ended responses but not in structured questions — these are things you did not think to ask about

• Reporting averages without distributions. A 3.5 average could mean everyone is lukewarm or half love it and half hate it.
• Ignoring non-response bias. The people who did not respond may be systematically different.
• Over-interpreting small differences. A 0.1 point change in NPS is noise, not signal.
• Treating Likert scales as interval data. The difference between "Strongly Agree" and "Agree" is not necessarily the same as between "Agree" and "Neutral."
• Confusing correlation with causation in cross-tabulations.

• Qualitative first: Interviews and observation reveal WHAT is happening and WHY. They generate hypotheses.
• Quantitative validation: Surveys and analytics reveal HOW MUCH and HOW MANY. They test hypotheses at scale.
• Qualitative deep-dive: Return to qualitative methods to understand unexpected quantitative findings.

• Use quantitative data to prioritize qualitative findings. A theme from interviews is more important if usage data shows it affects many users.
• Use qualitative data to explain quantitative anomalies. A drop in retention is a number; interviews reveal it is because of a confusing onboarding change.
• Present combined evidence: "47% of surveyed users report difficulty with X (survey), and interviews reveal this is because Y (qualitative finding)."

• Quantitative and qualitative sources may tell different stories. This is signal, not error.
• Check if the disagreement is due to different populations being measured
• Check if stated preferences (survey) differ from actual behavior (analytics)
• Check if the quantitative question captured what you think it captured
• Report the disagreement honestly and investigate further rather than choosing one source

1. Identify behavioral patterns: Look for clusters of similar behaviors, goals, and contexts across participants
2. Define distinguishing variables: What dimensions differentiate one cluster from another? (e.g., company size, technical skill, usage frequency, primary use case)
3. Create persona profiles: For each behavioral cluster:
   • Name and brief description
   • Key behaviors and goals
   • Pain points and needs
   • Context (role, company, tools used)
   • Representative quotes
4. Validate with data: Can you size each persona segment using quantitative data?

• Demographic personas: defining by age/gender/location instead of behavior. Behavior predicts product needs better than demographics.
• Too many personas: 3-5 is the sweet spot. More than that and they are not actionable.
• Fictional personas: made up based on assumptions rather than research data.
• Static personas: never updated as the product and market evolve.
• Personas without implications: a persona that does not change any product decisions is not useful.

• Addressable users: How many users could benefit from addressing this? Use product analytics, survey data, or market data to estimate.
• Frequency: How often do affected users encounter this issue? (Daily, weekly, monthly, one-time)
• Severity: How much does this issue impact users when it occurs? (Blocker, significant friction, minor annoyance)
• Willingness to pay: Would addressing this drive upgrades, retention, or new customer acquisition?

• Impact: (Users affected) x (Frequency) x (Severity) = impact score
• Evidence strength: How confident are we in the finding? (Multiple sources > single source, behavioral data > stated preferences)
• Strategic alignment: Does this opportunity align with company strategy and product vision?
• Feasibility: Can we realistically address this? (Technical feasibility, resource availability, time to impact)

• Be transparent about assumptions and confidence levels
• Show the math: "Based on support ticket volume, approximately 2,000 users per month encounter this issue. Interview data suggests 60% of them consider it a significant blocker."
• Use ranges rather than false precision: "This affects 1,500-2,500 users monthly" not "This affects 2,137 users monthly"
• Compare opportunities against each other to create a relative ranking, not just absolute scores

• Let the data speak. Do not force findings into a predetermined narrative.
• Distinguish between what users say and what they do. Behavioral data is stronger than stated preferences.
• Quotes are powerful evidence. Include them generously, with attribution to participant type (not name).
• Be explicit about confidence levels. A finding from 2 interviews is a hypothesis, not a conclusion.
• Contradictions in the data are interesting, not inconvenient. They often reveal distinct user segments.
• Recommendations should be specific enough to act on. "Improve onboarding" is not actionable. "Add a progress indicator to the setup flow" is.
• Resist the temptation to synthesize too many themes. 5-8 strong findings are better than 20 weak ones.