Customer Interview Synthesis: A Practical Template for Product Teams

Synthesis is a bridge, not a summary

An interview summary tells a reader what happened in one conversation. Synthesis compares evidence across conversations to help a team reason about a question. These are related jobs, but they are not interchangeable. A polished summary can still be a weak synthesis if it presents a researcher’s conclusion without showing what participants said, what they did, and how the team reached its interpretation.

The source material is often uneven. Some participants describe a recent event in detail; others respond to a hypothetical prompt. One person may use the same term differently from another. Notes may be partial, recordings may have gaps, and interviewers may ask follow-up questions inconsistently. A synthesis should expose these differences instead of compressing them into a single confident story.

A useful evidence trail makes it possible for another teammate to understand the claim, inspect its support, and disagree productively. This is more valuable than making the research deck look unanimous. Patterns can inform product choices, but a small qualitative sample is not a statistical estimate of a market.

Start with a narrow research question

Before interviews begin, write down the decision the research may inform and the question the team needs answered. “Understand why new admins abandon setup before inviting colleagues” is more actionable than “learn about onboarding.” A narrow question helps interviewers choose relevant prompts and keeps synthesis from expanding into every topic that happened to come up.

Record what the research is not designed to answer. Five interviews can reveal language, workflow variation, and useful hypotheses; they cannot establish how common a behavior is across a large customer base. Research conducted with current customers may not represent non-customers. Interviews about a concept do not equal observed use of a shipped feature.

Agree on a participant context sheet: recruitment source, role, relevant experience, date, and any constraints on quoting or sharing. Use the minimum detail needed to interpret the evidence. Remove direct identifiers when they are not needed, and follow the organization’s research consent and retention practices.

The reusable interview synthesis template

Use one record per interview. Keep the headings stable so records can be compared later. The template can live in a research repository, a document, or a spreadsheet; choose a format the team will actually maintain. Avoid creating a second authoritative record if an existing research system already owns participant consent, recordings, and study documentation.

Study and source: study name; research question; interview date; interviewer; participant code; recruitment context; consent and quote-sharing constraints; source links; and any recording or transcript gaps. This section tells a future reader where the material came from and what can safely be reused.

Context and task: participant role or relevant experience; recent situation discussed; task they were trying to complete; tools or people involved; and what happened next. Prefer concrete, recent examples over general claims. Do not infer personal characteristics that are irrelevant to the research question.

Evidence: direct quote or close paraphrase; timestamp or note location; observed action; interviewer prompt; and confidence in the transcription or note. Keep quotations brief and exact. Use brackets or a note to clarify an edit; never silently improve grammar in a way that changes the participant’s meaning.

Interpretation: what the researcher thinks the evidence may mean; alternative explanations; what is still unknown; and whether another source supports it. Mark interpretation as interpretation. Do not attribute a team’s preferred explanation to the participant unless they said it.

Synthesis tags: workflow stage; need or friction; workaround; consequence; frequency within this study only; and related evidence from other participants. Tags should help retrieval, not imply universal categories. Define each tag and revise the codebook when the team discovers ambiguity.

Product implication: opportunity or question to investigate; decision, if any; decision owner; rationale; and follow-up research or experiment. Keep participant evidence separate from the product choice. A product decision is made by the responsible team, not by the interview record.

Fill the template in a disciplined order

First create the source record while the conversation is fresh. Add the participant code, study question, date, and source location. Check that the interview was recorded or documented under the agreed process. If the transcript is machine-generated, mark it as unreviewed until key quotes and names are checked against the source.

Second write a neutral account of the concrete episode. What was the participant trying to do? What did they do? What happened? Use the participant’s own vocabulary where possible. Separate a recalled event from a hypothetical response, and separate what the researcher observed from what the participant reported.

Third select a small number of excerpts that directly support the research question. Include enough surrounding context to preserve meaning, with a timestamp or source pointer. A quote that sounds compelling but does not answer the research question is an anecdote, not evidence for the decision at hand.

Fourth write the interpretation and a plausible alternative. If the participant says they exported a report because “the dashboard felt slow,” possible explanations include performance, discoverability, trust, habit, or an external reporting requirement. The interview may not distinguish them. Preserve the unresolved question rather than choosing the interpretation that matches the roadmap.

Finally add tags and implications after reviewing the source. This order reduces the chance that a desired feature shapes what the analyst notices. Ask a second researcher or teammate to inspect a sample of records, especially when the study will influence a consequential product decision.

Compare interviews without erasing variation

Build a comparison matrix with participants as rows and research questions or workflow stages as columns. Add a short evidence note and source pointer in each cell. A blank cell means “not covered or unknown,” not “does not happen.” This prevents an unasked question from becoming a negative finding.

Look for recurring patterns and meaningful exceptions. A pattern might be that several participants create a separate spreadsheet after exporting a report. The exception may be a team that avoids exports because an administrator requires all reporting to remain in one system. Both matter: the first suggests a recurring job, while the second reveals a constraint or segment difference.

Count only within the sample and name the denominator. “Four of six interviewees in this study described maintaining a parallel spreadsheet” is a sample description, not a population rate. Do not convert it into “two-thirds of customers do this” unless a suitable quantitative method supports that inference.

Keep disagreement visible. Researchers may code a quote differently; participants may have different goals; and a behavior may depend on role or workflow. Discuss the disagreements, preserve the source excerpts, and revise definitions when needed. Forced consensus can hide a genuine segment distinction.

Example: interpreting a customer workaround

Imagine three anonymized interviews about onboarding. One participant says, “I paste the setup steps into our internal wiki because the new admin never sees the invite email.” A second forwards the invite manually. A third completes setup alone and adds teammates later. The shared evidence is not simply “invites are broken.” The accounts suggest at least two distinct paths: invite visibility and delayed team setup.

A traceable record would store each excerpt with a source pointer, the participant’s context, and what actually happened. An analyst might interpret the evidence as an activation handoff problem, while noting alternatives such as email filtering, role ownership, or an intentional single-user evaluation. The product team could decide to inspect invite delivery and setup ownership before changing onboarding.

This example is illustrative, not customer evidence about ProfMe or any other product. Its purpose is to show how the same surface behavior can have multiple explanations and why a quote should remain connected to the underlying context. Sources: ProfMe Professional Memory

Common synthesis mistakes

Do not treat frequency of mention as severity. A rare issue can block an important workflow, while a frequently mentioned preference may have little effect on task success. Record consequence and context separately from counts.

Do not mistake a feature request for the underlying need. Ask what the participant was trying to accomplish, what they tried, and what happened. The requested solution is valuable evidence about their mental model, but it may not be the only solution.

Do not let a vivid quotation stand in for the whole sample. Use a quote to make a finding understandable, then state the evidence base and limits. A carefully selected quote is not a prevalence measure.

Do not merge statements from different people into one composite quotation. Do not use generative AI to create synthetic participant language. If AI helps organize notes, label the result as generated, verify every extraction against source material, and keep human review in the loop.

Do not leave findings detached from their sources. A slide with a conclusion but no participant code, date, or link is difficult to audit and may be impossible to correct later. Keep source access governed and share only what the audience needs.

Use AI carefully in the research workflow

AI can help draft a neutral recap, locate candidate excerpts, or apply a known tag set to a transcript. It can also omit a caveat, blend two participants, misattribute a quote, or turn an analyst prompt into a finding. Treat machine-produced notes as a navigation aid until reviewed against the source.

Give the system a bounded task: identify candidate passages related to “invite handoff,” include timestamps, preserve exact wording, and mark uncertain matches. Ask it to separate direct quotes from its own summary. Then sample and verify every excerpt that will support a published finding or product decision.

Before uploading research data, assess participant expectations, consent, vendor processing, retention, access, model-training terms, and deletion. Sensitive user research may include personal or commercially confidential information. Use only tools and configurations approved for that data, and minimize identifiers where practical.

ProfMe publicly describes searchable meeting context and Professional Memory for connecting conversations, people, and decisions. That may be relevant to teams who want continuity around research discussions, but it does not establish a dedicated research repository or a validated qualitative analysis feature. Confirm what the current release supports and keep research records in the system approved for participant data. Sources: ProfMe search and provenance

Turn findings into decisions and next questions

For each finding, state the question, the evidence, the interpretation, the affected workflow, the uncertainty, and the next action. If the team decides to act, name the decision owner and keep the rationale close to the source. If it decides not to act, note why and what would change that decision.

Link follow-up experiments or quantitative checks to the specific hypothesis. If interviews suggest a setup handoff problem, inspect where users stop in the flow or test a revised invitation step. The next method should match the uncertainty: interviews are useful for meaning and context; instrumentation can help describe observed product behavior; surveys can quantify answers to clearly defined questions when sampling permits.

Review the repository after the project ends. Correct misattributed quotes, mark superseded interpretations, update access where team roles change, and apply the study’s retention plan. Good synthesis is not a one-time slide; it is a transparent chain from question to evidence to decision.

Frequently asked questions

Sources and further reading

Original research and product documentation are labeled separately.

• Official documentation Granola product manager meeting notes: customer interviews and research
• Official documentation Fireflies AI Apps and custom notes workflows
• ProfMe documentation ProfMe search and provenance
• ProfMe documentation ProfMe meeting capture
• ProfMe documentation ProfMe Professional Memory
• ProfMe documentation ProfMe AI and recording notice

Article ID: customer-interview-synthesis-template · Canonical publication URL: https://www.profme.in/blog/customer-interview-synthesis-template · Author: Satish Rajnale, Senior AI Product Engineer