Customer interview analysis: turn notes into a defensible product decision

Before recruiting, finish this sentence: after this round, we will decide whether to ____. A useful answer is narrow enough to change next week’s work: test an approval handoff, revise onboarding, or investigate a pricing objection. “Understand customers” is too open to tell you when you have learned something useful.

Write the competing explanations first. If customers abandon an onboarding flow, they may not understand the next step, lack the required information, or have decided the product is unsuitable. Ask questions that could distinguish those explanations. Record which roles, workflows, and customer types you recruited, plus who is missing. Friendly existing customers cannot describe the experience of prospects who never bought.

GOV.UK’s interview guidance recommends open, neutral questions and concrete stories. Use a discussion guide for consistent topic coverage, while allowing follow-up questions when a participant describes something unexpected. Check unclear details instead of filling gaps with your preferred explanation.^[1]

The questions below are original examples for a team investigating business approvals. Ask one at a time. A participant can show a redacted artifact or walk through the sequence without sharing confidential content. A remembered incident is still self-reported evidence; label it accordingly rather than treating the account as a measured event.

GOV.UK’s analysis guidance separates observations, findings, and actions. That distinction is useful in a spreadsheet too: preserve what someone said or did before writing what it might mean. Grouping observations can help identify patterns, but the group label should not replace the underlying evidence.^[2]

Use one row per distinct observation. Include a participant ID, source location, evidence type, relevant context, initial code, and interpretation. A transcript timestamp is preferable to “from the interview.” If you only have notes, say so. Do not put quotation marks around a paraphrase or quietly repair a quote to make it more persuasive.

Start with descriptive codes such as owner unclear, input missing, duplicate entry, or existing method works. Define what qualifies for each code and what does not. Owner unclear should mean the participant could not identify who was responsible, not simply that the responsible person was slow. A row may receive multiple codes when both conditions are present.

Have a second reader classify a small shared set, then discuss disagreements and improve the definitions. This is a consistency check, not proof that the interpretation is correct. Revisit earlier rows whenever a definition changes. Keep an “unclear” category rather than forcing thin evidence into a confident theme.

Count participants as well as mentions: one person repeating a complaint five times is still one participant. Compare findings by relevant segment and keep the denominator visible. “Three of four multi-site participants described unclear ownership” is more honest than “75% of customers need our product.” Preserve the participant whose current workflow succeeds and ask what makes it different.

Consider an entirely fictional research round with eight operations coordinators: four from single-site businesses and four from multi-site businesses. The team’s original idea is automated approval reminders. Three multi-site participants describe repeatedly searching for an owner; one describes missing input. Among single-site participants, one reports unclear ownership, two describe a working checklist, and one cannot recall a recent approval. These invented counts illustrate the reasoning, not market demand.

The team has evidence for several different situations, so it does not combine them into one universal pain point. It chooses to test a visible owner and next-action field with multi-site teams. It postpones automated reminders because reminders would not resolve missing invoices or ambiguous responsibility. The successful checklists are counterevidence to a broad replacement product.

GOV.UK’s research-data guidance recommends collecting only what the research needs, explaining how information will be used, limiting access, and agreeing a retention period. Apply those practical controls to notes and recordings as well as participant contact details.^[3]

For analysis, replace names with participant IDs and remove unnecessary account details, contact information, and commercially sensitive material. Keep the ID lookup separately with restricted access. Redaction does not automatically make a distinctive story anonymous. Share the smallest useful excerpt, and use only research tools and sharing arrangements your organization has approved.

AI can propose codes, organize redacted notes, or identify apparent contradictions. Require a source pointer for every suggested finding and manually check it. Tell the model to preserve uncertainty and never invent quotes, participants, or missing answers. Keep the final research decision with the person who can inspect the evidence and understand the recruitment limits.