How to Conduct Customer Interviews That Lead to Better Product Decisions

Quick answer: A useful customer interview is not a sales call with research language added on top. It is a structured conversation designed to learn how people currently solve a problem, what triggers the problem, what they have already tried, what costs or frustrations they experience, and what evidence should change your product or service decisions. Start with a specific research objective, recruit people who have relevant recent experience, ask open questions about real behavior rather than hypothetical preferences, probe for examples, avoid pitching until the research portion is finished, take disciplined notes, and analyze multiple interviews for repeated patterns before making a decision.

Good interviews are structured enough to answer specific research questions but flexible enough to follow useful evidence when it appears. Image: Dennis Mojado, Wikimedia Commons, CC BY 2.0.

Customer interviews are one of the fastest ways for a small business to learn why people buy, why they hesitate, how they work around a problem, what they misunderstand, and what they consider valuable. They are also easy to misuse. A founder can talk to ten people, hear compliments, and still learn almost nothing because every question was leading. A product team can collect dozens of suggestions and still make a poor decision because it asked people what features they wanted instead of understanding the job they were trying to accomplish. A service business can interview only loyal customers and mistakenly conclude that its onboarding process works for everyone.

This guide treats interviewing as a practical research system rather than a conversation trick. It covers objective setting, participant selection, recruitment, consent, discussion guides, questioning techniques, note-taking, remote interviews, pricing questions, prototype reactions, accessibility, analysis, synthesis, and decision-making. It also explains when an interview is the wrong tool and when you should use surveys, analytics, usability testing, support data, or experiments instead.

1. Begin With a Decision, Not a List of Questions

The first step is to identify the decision the research should improve. “Understand customers better” is too broad to guide an interview. A useful objective is narrower: “Understand why trial users fail to complete setup,” “Learn how independent accountants currently collect documents from clients,” “Understand what makes first-time buyers distrust our checkout,” or “Find out what small retailers do when inventory counts are wrong.”

Write the decision you expect to make after the interviews. Examples include choosing which problem to prioritize, deciding whether a workflow deserves redesign, determining which customer segment needs separate onboarding, changing the language on a service page, or deciding whether an idea deserves a prototype.

Why this matters: Interviews produce rich information. Without a decision boundary, every interesting comment can become a distraction. A decision-focused objective tells you what evidence matters and what can wait for another round.

Success check: Complete the sentence: “After this research, we should be better able to decide whether to ______.” If you cannot finish it clearly, refine the objective before recruiting anyone.

2. Turn Assumptions Into Research Questions

Teams often begin with beliefs disguised as facts: “Customers abandon because the price is high,” “People want a mobile app,” “Freelancers hate monthly billing,” or “Our users understand this terminology.” Convert each assumption into something research can investigate.

For example:

• Assumption: “People stop because setup takes too long.” Research question: “Where does setup become difficult, and what do users do next?”
• Assumption: “Customers want automation.” Research question: “Which tasks do customers repeat often enough that automation would matter?”
• Assumption: “Price is the main objection.” Research question: “What factors do buyers compare before deciding whether the service is worth paying for?”
• Assumption: “Users understand our dashboard.” Research question: “How do users interpret the information shown on the dashboard, and where do they become uncertain?”

GOV.UK user-research guidance recommends agreeing research questions early and turning unfounded opinions into questions that can be tested. That discipline is especially valuable for small businesses because founders are often close to the product and may confuse repeated internal discussion with evidence.

3. Decide Whether Interviews Are the Right Method

Interviews are strong when you need depth: motivations, context, workflows, language, workarounds, decision criteria, frustrations, and the sequence of events around a problem. They are weaker when you need precise prevalence or behavior at scale.

Use interviews when you want to learn:

• how people currently perform a task;
• what happened the last time a problem occurred;
• how buyers compare alternatives;
• why a process feels difficult;
• which constraints shape a decision;
• what language customers naturally use;
• what people tried before they bought your solution.

Use a survey when you need estimates across a large sample. Use analytics when you need to know what users actually do inside a digital product. Use usability testing when you need to observe whether people can complete tasks with an interface. Use an A/B test when you need causal evidence about a specific change. Use support-ticket analysis when you need repeated operational problems. Interviews often work best in combination with these methods rather than replacing them.

4. Define the Participant You Actually Need

Do not recruit “people who might be interested.” Recruit people whose recent experience is relevant to the question.

If you are studying abandoned checkout, you may need people who started checkout recently and did not complete it. If you are studying payroll problems, you may need small-business owners who run payroll themselves. If you are exploring a service for first-time landlords, interviewing experienced property managers can produce expert commentary but may not reveal beginner needs.

Create a short participant profile containing behavior, context, and timing. Example: “Owners or operations managers at businesses with 5–30 employees who have changed payroll providers or seriously evaluated alternatives within the last 12 months.”

Include exclusion criteria too. If your goal is to understand new customers, long-term power users may distort the findings. If you are studying a nontechnical audience, employees of software companies may not be representative.

Common mistake: Recruiting whoever is easiest to reach. Convenience is useful only if the people actually match the behavior you need to understand.

5. Include Variation That Could Change the Experience

A small qualitative sample should still include meaningful diversity. The relevant dimensions depend on the product: business size, job role, device, digital confidence, disability, geography, language, purchase history, experience level, or frequency of use.

Suppose you are researching appointment booking for a local service. A sample made entirely of frequent repeat customers may miss the uncertainty experienced by first-time visitors. If the service is digital, users with low digital confidence or assistive technology may reveal barriers that confident desktop users do not see.

GOV.UK guidance emphasizes researching a broad range of users, including people who may have access or digital-skill barriers. The business lesson is not that every research round must represent every possible customer. It is that you should deliberately include variation related to the decision instead of assuming the easiest participants are “typical.”

6. Choose a Practical Sample Size

Qualitative interviews are not a statistical poll. The purpose is to identify patterns, explanations, and meaningful differences, then decide whether you have enough evidence to act or whether another research round is needed.

GOV.UK service guidance notes that rounds of in-depth interviews often use roughly four to eight participants, with additional rounds when more clarity is needed. For a small business, five to eight well-matched interviews can be a useful first round for a focused problem. If you have two clearly different user types, you may need several participants in each group rather than combining them.

Do not treat “five interviews” as a universal rule. A narrow, repeated workflow may become clear quickly. A complex market with several buyer roles may require more. Continue until new interviews mostly confirm known patterns or reveal a specific subgroup that deserves its own investigation.

7. Recruit With a Neutral Message

Your recruitment message should explain the topic without revealing the answer you hope to hear.

Weak recruitment: “We are building an amazing automated invoicing tool and want feedback from people who hate manual invoices.” This attracts people primed to agree with the solution.

Better recruitment: “We are researching how small businesses create, send, and track invoices. We are looking for owners or staff who handle invoicing regularly. The session will focus on your current process and recent experiences.”

Include the approximate duration, format, incentive if offered, privacy expectations, and whether the session may be recorded. If you are recruiting existing customers, make clear that participation is optional and that honest criticism is useful.

Avoid having the account manager recruit only the happiest clients. Randomize or broaden outreach so the sample can include people with friction, confusion, or incomplete adoption.

8. Use a Screener to Protect the Sample

A screener is a short set of questions used before the interview to confirm that the participant matches your criteria.

Good screener questions ask about actual behavior: “When did you last send a customer invoice?” “Which tools do you currently use?” “How many employees are involved?” “Have you changed providers in the last 12 months?”

Avoid screeners that reveal the “correct” answer. Asking “Do you struggle with inefficient invoice tracking?” encourages people to qualify themselves by agreeing. Ask instead: “How do you track whether an invoice has been paid?”

Keep the screener short. Its job is participant selection, not conducting the research before the interview begins.

9. Handle Consent and Recording Transparently

Tell participants what the research is for, how long it will take, who may observe, what will be recorded, how notes will be used, and whether quotations may be shared internally. Obtain informed consent before recording audio or video.

Do not hide a recorder in the background because “everyone records calls.” Research creates a different expectation. If a participant declines recording, decide whether notes are sufficient or whether the session should be rescheduled with someone else according to your research requirements.

Store recordings and notes only as long as needed and follow applicable privacy laws, contracts, and organizational policies. Avoid collecting sensitive personal information unless it is necessary to answer the research question.

Practical rule: If a piece of data would create risk without improving the decision, do not collect it.

10. Build a Discussion Guide, Not a Script You Must Read Word for Word

A discussion guide gives the interview a logical flow while leaving room to follow useful evidence. GOV.UK guidance for in-depth interviews recommends reviewing research questions, organizing topics, writing starter and follow-up questions, testing the guide, and including an introduction and activity instructions.

A useful guide usually includes:

1. introduction and consent;
2. brief background;
3. recent real experience;
4. current workflow;
5. problems and workarounds;
6. decision criteria or alternatives;
7. optional prototype or concept section;
8. closing questions.

Write more follow-up prompts than you expect to use. Examples: “What happened next?” “Can you show me?” “How often does that happen?” “Who else is involved?” “What did that cost you in time or money?” “How did you decide?” “What made that difficult?”

11. Start With Recent Behavior

People are much better at describing something they actually did than predicting what they might do.

Instead of asking, “Would you use a tool that automatically reminds customers to pay?” ask, “Tell me about the last overdue invoice you had to follow up on. What happened from the moment you noticed it was late?”

Then probe:

• How did you notice it?
• What did you do first?
• Which tool did you use?
• Who was involved?
• How long did it take?
• What was frustrating?
• What happened if the customer did not reply?

Behavioral detail produces evidence about real constraints. Hypothetical enthusiasm often produces false confidence.

12. Ask for Stories, Not Opinions

Opinions are easy to generate. Stories expose process.

“Do you think onboarding is confusing?” may produce a vague yes or no. “Think about the first time you set up your account. Where were you, what were you trying to do, and what happened?” produces specific evidence.

If a participant makes a broad claim—“This always takes forever”—ask for the last example. If they say, “Everyone hates this,” ask who they have seen struggle and what happened. Specific events let you distinguish a repeated problem from a strong impression.

Good interviews repeatedly move from general language back to observable detail.

13. Avoid Leading Questions

A leading question suggests the desired answer: “Wouldn’t it be easier if this were automated?” “How frustrating is our checkout?” “Do you like the new design?”

Use neutral alternatives:

• “How do you handle this today?”
• “What is easy or difficult about that?”
• “What do you think this screen is for?”
• “What would you expect to happen next?”
• “How does this compare with your current approach?”

Neutral wording protects you from confirmation bias. Your job is not to get the participant to validate the idea. Your job is to learn whether the idea deserves validation.

14. Avoid Asking People to Design the Product for You

Customers are excellent sources of evidence about problems, context, priorities, language, and current behavior. They are not automatically responsible for designing the solution.

If someone says, “You should add a dashboard,” ask what problem the dashboard would solve. “What would you need to see there?” “When would you open it?” “What do you do today because that information is missing?”

A feature suggestion is often a compressed expression of an unmet need. Unpack the need before adding the feature to a roadmap.

This is especially important in B2B interviews, where experienced customers may confidently propose implementation details based on their own company’s process. The need may be real while the proposed design fits only that company.

15. Separate Problem Interviews From Sales Calls

If you pitch early, participants begin reacting to your product instead of describing their world. They may also become polite because they know you are trying to sell.

Keep the first part of the session focused on their experience. If you want to show a concept, explain that you will do so later. Finish the discovery questions first.

At the end, if the participant is a legitimate sales prospect, you can transition clearly: “The research portion is finished. If you are interested, I can show you what we are working on.” This boundary protects the data and the relationship.

16. Ask About Alternatives and Workarounds

A problem is more credible when people already spend time, money, effort, or attention trying to solve it.

Ask:

• What do you use now?
• What did you use before?
• Have you built a spreadsheet or manual workaround?
• Have you paid someone to handle the task?
• What happens when you do nothing?
• What have you tried and abandoned?

Workarounds reveal urgency. If someone repeatedly exports data, cleans it manually, and reconciles it in a spreadsheet every Friday, that is stronger evidence than saying “reporting could be better.”

17. Ask About the Trigger

Many products are purchased only when a specific event occurs: hiring the first employee, losing a client, receiving an audit request, moving to a new house, reaching a transaction threshold, changing managers, or experiencing a security incident.

Ask what happened immediately before the participant began looking for a solution. “What made you decide the old process was no longer acceptable?” “Why did you start searching that week instead of six months earlier?”

Triggers help with positioning, timing, acquisition, and product design. They also distinguish a persistent annoyance from a problem strong enough to create action.

18. Explore the Decision Journey

When the research concerns purchasing, map the sequence rather than asking only why someone chose your company.

Explore:

1. the trigger;
2. initial search;
3. alternatives considered;
4. people involved;
5. information needed;
6. objections;
7. trial or demo behavior;
8. final decision;
9. post-purchase confirmation or regret.

In B2B contexts, the user, buyer, approver, finance contact, IT reviewer, and executive sponsor may be different people. One interview can reveal only one perspective. If the buying process is important, recruit across roles.

19. Be Careful With Pricing Questions

“Would you pay $50?” often produces weak evidence. Participants are not spending real money during the interview, and saying yes costs nothing.

Better questions explore current spending and trade-offs: “What do you pay today?” “What would you compare this against?” “Who approves this expense?” “What would make the price feel too high?” “What happens if you do not solve the problem?”

If you need actual willingness-to-pay evidence, combine interviews with real pricing tests, purchase behavior, or structured pricing research. Interviews can reveal the logic behind value perception, but they should not be treated as a substitute for market behavior.

20. Use Silence as a Research Tool

Interviewers often rush to fill a pause. That can interrupt the participant just before they remember something useful.

Ask a question and wait. If the participant finishes a sentence, wait another moment before moving on. A short silence often produces a second, more reflective answer.

Do not use silence as pressure. The goal is space, not discomfort. If the participant appears confused, rephrase the question neutrally.

21. Follow the Unexpected Detail

A discussion guide is not a checklist that must be completed in order. If a participant says something surprising and relevant, probe it.

Suppose your guide is about invoicing, but the participant mentions that every invoice is first approved in a messaging app because the accounting system is “too slow.” That may reveal a hidden workflow worth understanding.

Ask: “Can you walk me through that?” “Who posts the approval?” “What happens if someone misses the message?” “Why did the team begin doing it that way?”

Useful research often comes from the gap between the process people say they have and the process they actually use.

22. Ask Participants to Show, Not Just Tell

When possible, ask people to demonstrate the real process: open the spreadsheet, show the folder structure, walk through the booking site, explain a form, or share the email template they use.

Observation exposes details that memory omits. A participant may say their workflow takes “a few minutes,” then reveal six tabs, two spreadsheets, and a manual copy-paste step.

Protect privacy. Let participants hide confidential records, use sample data, or describe sensitive steps instead of exposing information they should not share.

Observation and follow-up questions often reveal the real workflow behind a simplified verbal description. Image: Jwslubbock, Wikimedia Commons, CC BY-SA 4.0.

23. Use a Note-Taker When Possible

Interviewing and taking detailed notes at the same time is difficult. If you have a second team member, assign one person to lead and one to capture evidence.

The note-taker should record concise statements, behaviors, tools, sequence, obstacles, and strong quotations. Separate direct evidence from interpretation. For example:

Evidence: “Participant checks three bank accounts manually every morning.”

Interpretation: “May need consolidated cash visibility.”

Do not mix them invisibly. The interpretation may be wrong; the evidence remains useful.

If you interview alone, use recording with consent and take lightweight timestamps or keywords during the session, then expand notes immediately afterward.

24. Write Down Contradictions

Contradictions are often more informative than consistency.

A participant may say, “Price is not important,” then describe choosing the cheapest option. They may say, “I never forget,” then show a reminder spreadsheet. They may claim a process is easy but spend 20 minutes explaining exceptions.

Do not confront the participant aggressively. Note the discrepancy and ask for examples. Behavior and artifacts often deserve more weight than self-description.

25. Run a Practice Interview

GOV.UK research guidance recommends testing the interview structure before fieldwork. Run the guide with a colleague or someone who resembles the participant profile.

Watch for:

• questions that are too long;
• questions that contain two ideas;
• leading language;
• topics that repeat;
• awkward transitions;
• sections that take too much time;
• missing follow-up prompts.

A 45-minute interview guide often contains only 20–25 minutes of planned questions because probing and storytelling consume the rest. If your guide contains 60 questions, it is not a realistic guide.

26. Structure a 45-Minute Interview

A practical structure is:

• 0–5 minutes: introduction, consent, context;
• 5–10 minutes: participant background relevant to the research;
• 10–30 minutes: recent experience, workflow, problems, alternatives;
• 30–38 minutes: concept, prototype, or focused follow-up if needed;
• 38–43 minutes: missing topics and prioritization;
• 43–45 minutes: closing and next steps.

If the participant is telling a highly relevant story, do not interrupt merely to preserve the schedule. Shorten lower-priority sections instead.

27. Conduct Remote Interviews With Extra Preparation

Remote interviews are convenient but introduce technical and contextual issues.

Before the session:

• send a calendar invitation and simple connection instructions;
• confirm the participant can use the meeting tool;
• provide a phone backup if appropriate;
• test recording and screen-sharing;
• ask the participant to close sensitive windows if they may share their screen;
• prepare links or prototypes in advance.

Remote sessions can be excellent for observing software workflows because participants use their own device and environment. They can be weaker when the physical environment or in-person service is central to the problem.

28. Make Interviews Accessible

Accessibility is part of research quality. Ask participants whether they need captions, interpreters, larger text, breaks, alternative meeting software, extra time, or another accommodation.

If your product serves people with disabilities, do not assume a generic interview represents their experience. Include users who actually use assistive technologies or who experience relevant barriers.

For remote research, verify that the conferencing tool works with captions and screen readers where required. Send materials in accessible formats before the session when helpful.

29. Interview Existing Customers and Noncustomers Separately

Existing customers know your product. Their answers are shaped by that familiarity. Noncustomers may reveal how the market solves the problem without your product.

Use customer interviews for onboarding, adoption, value realization, support, retention, and expansion. Use noncustomer interviews for discovery, alternative workflows, category expectations, and reasons people do not switch.

Do not combine the two groups and report “customers said…” when half were not customers. Label segments during analysis.

30. Talk to Churned or Lost Customers

Former customers can reveal friction that loyal users have learned to tolerate.

Recruit churned users soon enough that the experience is still fresh. Ask about the sequence leading to cancellation, what they expected, what disappointed them, what they used afterward, and whether the decision was triggered by one event or accumulated frustration.

For lost sales, ask what alternative won and why. Avoid turning the interview into a win-back pitch. If the participant believes every answer will trigger a sales response, honesty may decrease.

31. Do Not Overinterpret Compliments

“I love the idea” is not the same as adoption. Participants are often polite, especially when speaking directly to the founder.

When you hear praise, ask for evidence: “What part would change what you do today?” “When would you use it?” “What would it replace?” “What would stop you from using it?”

Strong signals include repeated pain, existing workarounds, money already spent, deadlines, switching behavior, and concrete attempts to solve the problem. Compliments are pleasant but weak.

32. Analyze Immediately After Each Interview

Do not wait until all sessions are complete before reviewing notes.

After each interview, spend 10–15 minutes capturing:

• top three observations;
• surprises;
• contradictions;
• important quotations;
• unanswered questions;
• changes to the guide for the next session.

Iterative analysis lets the research improve while it is running. If three participants mention the same unexpected step, add a probe for it in later interviews.

33. Use an Evidence Table

Create a spreadsheet where rows are participants and columns represent themes or research questions. Example columns:

• trigger;
• current process;
• tools used;
• frequency;
• main pain point;
• workaround;
• decision criteria;
• buyer roles;
• switching barrier;
• notable quote.

Keep entries short. Link to detailed notes when necessary.

This structure prevents the loudest interview from dominating memory. It also makes differences between segments visible.

34. Code Patterns Without Turning Qualitative Research Into Fake Statistics

You can count repeated themes, but be careful with percentages from tiny samples. Saying “80% of users want X” when four of five interviewees mentioned it creates false precision.

Use language such as:

• “Most participants described…”
• “A repeated pattern across six interviews was…”
• “This issue appeared only among first-time users…”
• “Two participants had a different workflow because…”

When prevalence matters, validate with a larger quantitative method.

35. Separate Findings From Recommendations

A finding describes evidence. A recommendation proposes action.

Finding: “Five of six participants copied invoice data from email into a spreadsheet because the current system did not show payment status across accounts.”

Recommendation: “Prototype a consolidated payment-status view and test whether it reduces manual checking.”

This separation lets the team debate solutions without arguing about what participants actually did.

36. Prioritize Findings by Consequence

Not every complaint deserves product work.

Score findings using factors such as:

• frequency across relevant participants;
• severity;
• business impact;
• strategic fit;
• evidence strength;
• ease of testing;
• whether the problem blocks a critical task.

A rare issue that prevents payment may deserve faster action than a common cosmetic annoyance.

37. Turn Findings Into Testable Next Steps

Research should change something. Possible next steps include:

• rewrite confusing copy;
• prototype a workflow;
• change onboarding order;
• remove an unnecessary field;
• segment customers differently;
• run a pricing experiment;
• collect analytics on a suspected drop-off;
• interview a missing user group;
• stop building an idea that lacks evidence.

For each action, record what evidence triggered it and what new evidence would confirm improvement.

38. Use Interviews Before Building, Not Only After Problems Appear

Interviewing is often used as damage control after a product underperforms. It is more valuable earlier.

Before building, interviews can clarify whether the problem exists, how people solve it today, and which constraints matter. During design, they can help refine workflows and language. After launch, they can explain analytics, support issues, and adoption differences.

Continuous small rounds are often more useful than one giant research project because the business can act between rounds.

39. Combine Interviews With Support Data

Support tickets are excellent sources of repeated pain, but they represent only people who contact support.

Use tickets to identify themes, then interview customers to understand context. For example, if many tickets mention “missing reports,” an interview may reveal that the real issue is not absence of a report but uncertainty about which date range to select.

Combining behavioral records with interviews creates stronger evidence than either alone.

40. Combine Interviews With Analytics

Analytics can tell you where users stop, which feature is used, and how long steps take. Interviews can help explain why.

If analytics shows that 40% of users abandon a setup screen, recruit people who recently abandoned there and ask them to walk through what they were trying to accomplish. Do not ask, “Why did you abandon step three?” as if the analytics interpretation is certainly correct. Let them describe the experience first.

41. Use Concept Testing Carefully

When you show an idea, explain that you are testing the concept, not the participant.

Ask:

• What do you think this is?
• What problem would it solve, if any?
• How would it fit into what you do today?
• What seems unclear?
• What would you expect to happen next?
• What concerns would you have?

Avoid “Do you like it?” because liking does not prove usefulness.

42. Observe Usability Separately From Discussion

If the product already exists, do not ask participants to explain the interface while you guide them through it. Give realistic tasks and observe.

For example: “You have received a payment and want to confirm which invoice it belongs to. Show me what you would do.”

Resist helping immediately. If participants struggle, that struggle is evidence. Afterward, ask what they expected and what confused them.

Moderated usability testing and interviews can be combined in one session, but they answer different questions. Interviews explore experience and needs; usability tests reveal whether a design supports a task.

Group discussion can generate themes, but individual interviews are usually better when you need detailed personal workflows or sensitive experiences. Image: IICD, Wikimedia Commons, CC BY 2.0.

43. Know When a Focus Group Is Different

A focus group is not simply a cheaper way to run several interviews at once.

Group dynamics change responses. Participants influence one another, outspoken people can dominate, and sensitive topics may not surface. Focus groups can be useful for reactions, shared language, or exploring social norms, but they are weaker for detailed personal workflows.

If you need to understand exactly how someone handles payroll, negotiates a purchase, or experiences a private problem, individual interviews are usually more appropriate.

44. Avoid Recruiting Only Friends and Family

Friends and family are easy to reach but often want to support you. They may also lack the relevant behavior.

Use them to practice the interview guide, not as your primary evidence unless they genuinely match the target profile. A founder’s cousin who says a business app “sounds useful” is not equivalent to an operations manager who currently performs the task every week.

45. Incentives Should Compensate, Not Purchase Praise

Compensation can improve recruitment and respect participants’ time. State clearly that the incentive is for participation, not positive feedback.

The appropriate amount depends on session length, audience, market, professional seniority, recruitment difficulty, and local norms. Specialized B2B participants may require more than general consumers.

Do not design incentives that create pressure to continue if the participant wants to stop.

46. Protect Research From Stakeholder Interference

If teammates observe interviews, brief them first.

Observers should not interrupt, answer for the participant, defend the product, or message the moderator with ten new questions during the session. Give observers a note-taking template and reserve discussion for afterward.

GOV.UK guidance encourages team participation in research because direct exposure to users improves shared understanding. That works only if observation does not distort the session.

47. Create a One-Page Research Summary

After the round, summarize:

• research objective;
• participant profile;
• method;
• main findings;
• important differences between segments;
• evidence examples;
• limitations;
• decisions or next experiments.

Do not bury decisions inside a 60-slide deck. Link detailed notes for people who need depth.

48. Record Limitations Honestly

Every research round has limits: small sample, one geography, existing customers only, remote sessions, incomplete representation, or self-reported behavior.

Write these down. Limitations do not invalidate the research; they define how far the conclusions should travel.

“Six owners of five-to-20-person agencies repeatedly described this problem” is useful. It is not evidence that all small businesses have the same problem.

49. Build a Research Repository

Store interview notes, participant metadata, findings, clips or quotations where the team can retrieve them. Use consistent names and dates.

A lightweight structure might be:

• 2026-08 Invoice Discovery Round 1
• Research plan
• Discussion guide
• Participant notes
• Evidence table
• Summary
• Decisions and follow-ups

Keep sensitive identifiers separate or minimized. The repository should improve organizational memory without becoming a privacy risk.

50. Revisit Old Findings Instead of Relearning the Same Lesson

Before starting new interviews, search previous research. You may already know part of the answer.

Old findings are not automatically current, especially when products, markets, regulations, or user behavior changed. But they can prevent redundant questions and help you identify what needs revalidation.

51. A 30-Minute Planning Workflow

If you need to launch a small interview round quickly, use this sequence:

1. Minutes 0–5: Write the decision you need to make.
2. Minutes 5–10: Convert assumptions into three research questions.
3. Minutes 10–15: Define participant behavior and exclusions.
4. Minutes 15–20: Draft five core open questions and ten probes.
5. Minutes 20–25: Draft recruitment and consent language.
6. Minutes 25–30: Create an evidence table and schedule a practice interview.

This is enough to create a disciplined first round. Improve the guide after the practice session.

52. Worked Example: A Small SaaS Company With Low Trial Activation

Imagine a small software company offering appointment scheduling to independent therapists. Analytics shows many people create an account but never publish their booking page.

The team initially assumes setup is too long. Instead of immediately removing steps, they define the decision: “What should we change first to increase successful setup?”

They recruit six people who created an account in the last month and did not publish a page, plus four who successfully published one. Interviews begin with recent behavior: “Tell me what you were trying to accomplish when you signed up.”

Three non-activators reveal that they stopped not because of setup length, but because they did not understand whether client data would be private. Two others were waiting for a colleague to approve pricing. One thought the booking page would automatically replace an existing website and became confused.

Successful users report that the process itself was manageable but say a privacy explanation was difficult to find.

The team now has several hypotheses: improve privacy explanation, clarify website integration, and detect multi-person approval cases. The original “shorten setup” solution becomes lower priority. Research changed the decision rather than merely confirming it.

53. Worked Example: A Local Service Business Considering a Subscription

A cleaning company is considering a monthly subscription plan. The owner asks existing clients, “Would you like a subscription discount?” Most say yes.

This sounds promising but is weak evidence. The owner runs a better round with customers who booked at least three times in the last year.

Questions focus on behavior: “What usually makes you book?” “How far in advance?” “What changes your schedule?” “Have you ever delayed booking because you were unsure whether you needed the service?”

The interviews reveal two distinct patterns. Busy families value predictable recurring dates. Occasional customers book only before events and do not want another subscription. The business decides to test a recurring plan only with the first segment rather than converting the entire service model.

54. Troubleshooting: Participants Give Very Short Answers

Ask for a specific recent event. “Tell me about the last time.” Use follow-up probes. Avoid stacking multiple questions. Give silence.

If responses remain short, the participant may not have enough relevant experience. Review your screener.

55. Troubleshooting: Everyone Agrees With the Idea

You may be pitching or leading. Stop showing the concept early. Ask about current behavior and alternatives. Recruit people who have rejected similar products or who do not use your service.

56. Troubleshooting: Every Interview Produces a Different Problem

Your research objective may be too broad or your participants too diverse. Segment the evidence. A small retailer and a 200-person enterprise may legitimately have different workflows.

Narrow the next round.

57. Troubleshooting: Stakeholders Want a Percentage

Explain that interviews provide qualitative depth, not population estimates. Use interviews to identify themes and hypotheses, then validate prevalence with a survey, analytics, or behavioral data if the business decision requires it.

58. Troubleshooting: The Founder Keeps Defending the Product

Assign a neutral moderator. Remind observers that criticism is evidence, not an attack. Do not explain what the participant “should” understand during usability observation.

59. Troubleshooting: Participants Describe an Ideal Future Instead of Reality

Return to the past: “When did this happen last?” “What did you actually do?” “Show me the document.” “Who did you contact?”

Future ideas can be captured at the end, but behavior should anchor the analysis.

60. Final Interview Checklist

• There is a clear decision and research objective.
• Participants match relevant recent behavior.
• The sample includes meaningful variation.
• Recruitment language is neutral.
• Consent and recording are explicit.
• The guide starts with real experience.
• Questions are open and non-leading.
• Follow-up probes ask for examples and sequence.
• The researcher avoids pitching during discovery.
• Evidence and interpretation are stored separately.
• Analysis happens after each session and across the round.
• Findings are separated from recommendations.
• Limitations are documented.
• At least one concrete decision or experiment follows the research.

Frequently Asked Questions

How many customer interviews should I conduct?

For a focused qualitative round, several well-matched interviews can reveal useful patterns. GOV.UK guidance notes that in-depth interview rounds often use roughly four to eight participants. The correct number depends on the diversity of the audience and whether new sessions continue revealing important new patterns.

Should I interview customers who love the product?

Yes, but not only them. Include new users, people who struggle, churned customers, lost prospects, or noncustomers when those groups are relevant to the decision.

Should I record interviews?

Recording can improve analysis, but obtain informed consent and store recordings securely. If recording is unnecessary, detailed notes may reduce privacy risk.

What is the best first question?

A strong first substantive question asks about a recent relevant experience: “Tell me about the last time you tried to…” This grounds the discussion in behavior.

Can I ask participants what features they want?

You can listen to feature ideas, but probe the underlying problem. Ask what they are trying to accomplish, what happens today, and why the feature would matter.

How do I know whether a problem is important?

Look for repeated evidence, severity, existing workarounds, cost, urgency, switching behavior, and consequences when the problem is not solved. Compliments and hypothetical interest are weaker evidence.

Can customer interviews validate pricing?

They can explain value, alternatives, approval processes, and current spending. Actual willingness to pay should ideally be tested with behavior, structured pricing research, or real purchase decisions.

Should interviews be remote or in person?

Use the format that best supports the research question. Remote is convenient and useful for digital workflows. In-person or contextual research may be better when environment, equipment, or physical service delivery matters.

What is the difference between interviews and usability testing?

Interviews explore experiences, needs, context, and decision-making. Usability testing observes whether someone can complete realistic tasks with a design. They can be combined, but they answer different questions.

What should I do after the final interview?

Synthesize patterns across participants, document differences and limitations, separate findings from recommendations, and decide the next action: change, prototype, test, measure, or run another research round.

Conclusion: Interview for Evidence, Not Approval

The most valuable customer interview is not the one that produces the most compliments. It is the one that changes your understanding of the problem enough to improve a decision.

Start with a decision. Recruit people with relevant experience. Ask about what happened rather than what they imagine. Follow workarounds, triggers, trade-offs, and contradictions. Let participants show you the process. Keep the pitch until the research portion is finished. Analyze several interviews together rather than reacting to the loudest quote.

The biggest mistake is using interviews to confirm a solution you already decided to build. If every question contains your assumption, the research can only echo it back.

Your first action can be simple: write one business decision, list three assumptions behind it, and turn those assumptions into research questions. That gives you the foundation for a useful interview round.

Sources and Further Reading

• GOV.UK Service Manual — Plan user research for your service
• GOV.UK Service Manual — Using in-depth interviews
• GOV.UK Service Manual — Plan a round of user research
• GOV.UK Service Manual — Learning about users and their needs
• GOV.UK Service Manual — User research in discovery

Image Credits

• “Interview.jpg” — Dennis Mojado, Wikimedia Commons, CC BY 2.0.
• “Wikimedia UK office meeting.jpg” — Jwslubbock, Wikimedia Commons, CC BY-SA 4.0.
• “Focus Groups National Network meetings IMG 0287 (5348183807).jpg” — IICD, Wikimedia Commons, CC BY 2.0.