A customer interview can reveal the questions people ask while evaluating a product. Start with the decision you need to understand, not a request for a flattering testimonial. The output should help the team explain a real customer task more clearly.
Choose a narrow research objective. For example: understand what an operations manager needed to verify before replacing an email-based approval process. That objective produces more useful questions than “What do you like about our product?”
The brief and synthesis below are hypothetical. They contain no actual customer findings, quotations, or claims about how common a behavior is. Use them to prepare an authorized interview, then replace the example material with evidence from the real conversation.
Write the interview brief
Include the research objective, participant criteria, intended use of the notes, recording plan if any, consent process, interviewer, and synthesis owner. Decide what may be quoted publicly and what is for internal research only.
Keep commercial permission separate from research participation. A customer may agree to explain a workflow without agreeing to be named in a case study. Record the actual agreement rather than assuming that a friendly conversation authorizes every later use.
For the fictional approval-software study, participant criteria might be someone who recently evaluated or changed an approval process and participated in the decision. That is more useful than interviewing any available account contact and assuming they know the buying story.
Ask for a specific sequence of events
Use questions that invite concrete recollection. Follow the participant's actual example before asking them to generalize.
- What was happening when your team first considered changing the process?
- Can you walk me through one request that exposed the problem?
- Who needed to agree that a change was worthwhile?
- What did you need to verify before considering a tool?
- Where did you look for that information?
- Which explanation was missing or difficult to trust?
- What alternatives did you consider, including keeping the existing process?
- What would have made the evaluation easier to complete?
Avoid supplying the desired answer inside the question. “How much time did our clear documentation save you?” assumes both clarity and savings. A neutral question about what helped or obstructed the evaluation leaves room for an inconvenient but useful answer.
Ask follow-ups about terms that are ambiguous. If someone says a tool was “too complex,” find out which task or requirement made it feel that way. Do not translate the phrase into a universal product conclusion without the surrounding example.
Keep observation and interpretation separate
Use a note structure with the participant's account, the supporting timestamp or note reference, the interviewer's interpretation, and the content question it suggests. Preserve uncertainty and disagreement instead of forcing every comment into a neat theme.
| Hypothetical note | Possible interpretation | Content question |
|---|---|---|
| A participant describes checking whether two managers could approve a request. | The approval sequence may be hard to evaluate from current copy. | Can a buyer see a concrete two-approver example? |
| A participant describes asking support about export format. | The evaluation may require more specific export documentation. | Are supported outputs and limits clearly documented? |
| A participant says they kept email for a small team. | The current process may remain adequate for some situations. | Can content explain when a tool is unnecessary? |
These are possible interpretations of invented notes. Real synthesis should retain the actual evidence and alternative explanations. A support question could reflect a missing page, an unclear page, or a participant who never found the page.
Translate themes into bounded content work
For each proposed article or page change, identify the reader question, supporting interview evidence, additional product verification needed, and the nearest existing page. Often the right action is to improve a section rather than publish another article.
In the fictional example, a two-approver walkthrough might belong on the product's workflow page. Export-format details might belong in documentation. A guide about when email is sufficient could serve an earlier evaluation decision. These are different jobs even though they arose in the same interview.
Do not turn every memorable phrase into a target keyword or every participant into a market segment. Keep the proposed action proportional to the evidence. A small qualitative study can generate useful hypotheses without estimating how frequently the whole market holds a view.
Review the output before publication
Verify product claims with the product owner and current documentation. Confirm permitted quotations and attribution through the agreed process. Remove private operational details that are unnecessary for the educational purpose.
The final research note should say who was eligible, how participants were selected, what was discussed, what remains uncertain, and which content decisions follow. Do not label a handful of interviews an industry benchmark.
Use the sales-question backlog method to connect the research with editorial work. The goal is to make the next customer explanation more specific and useful while keeping the evidence and its limits intact.