Customer development: How to run useful customer interviews

01Define the decision the interviews should inform

Start with a sentence: “After this round, we want to decide whether to keep investigating self-service repair tracking.” That is more useful than “find out what customers want”. Write down who might lack information, when they need it, how they obtain it today and what happens without it.

For our example, we do not yet know whether customers struggle with finding a status, an uncertain completion date or a missing repair document. Each could require a different solution. Before commissioning a portal, we want to understand which issue affects their work.

• Assumption: customers repeatedly contact the service company because they do not know the next step in a repair.
• Disconfirming evidence: they receive updates on time and call for technical advice that a portal would not resolve.
• Evidence to seek: a recent specific incident, the communication involved and its consequences.
• Decision afterwards: continue investigating, narrow the audience, change the question or stop.

If the team cannot agree on the audience and purpose, first establish a shared product vision and strategy. Interviews can then test clear assumptions instead of becoming separate searches for evidence supporting each person’s favourite idea.

02Recruit for relevant experience

Use criteria you can check. For the repair portal, we might seek people who personally handled a company equipment repair recently. Set the period according to how often that event normally occurs. Being a “small business owner” does not establish relevant experience.

In B2B research, distinguish the user, purchase approver and process owner. A technician may need repair details, a manager a completion date and an accounts team a document. Do not merge those needs into one persona. Include people whose current approach works well and people who stopped using the service.

Explain the topic, duration, format and any incentive in the invitation. For example: “We are exploring how businesses keep track of equipment repairs. We would like to discuss a recent repair you handled. The conversation will take approximately half an hour.” Do not suggest that dissatisfaction is the expected answer.

Existing customers are a useful starting point, but a group consisting only of friendly, satisfied contacts can produce a narrow picture. Record recruitment sources and how each participant meets the criteria. Repeated responses from the same kind of contact may reveal a recruitment limitation rather than sufficient evidence.

03Prepare a guide and agree how records will be used

Write the main research question, follow-up topics and time for analysis. GOV.UK’s planning guidance connects research activities to the questions that need answering. Rehearse the guide to find unclear wording before using it with participants.

Before taking notes or recording, explain the purpose, who will have access and how long the material is needed. Obtain appropriate agreement to participation and the chosen recording method; people can decline a recording. GOV.UK’s notes and recording guidance provides a practical framework. Avoid unnecessary personal details or confidential repair documents in the working summary.

Introduce any note-taker. One person can lead while the other captures important statements and uncertainties. This makes it easier to listen instead of attempting a verbatim transcript throughout the conversation.

04Ask about events and behaviour, not hypothetical approval

Eric Migicovsky’s Y Combinator talk emphasises real experiences over hypothetical reactions to an idea. For our portal, we turn that principle into questions about the last repair. The guide supports a coherent conversation; it is not a checklist to recite mechanically.

Use short follow-ups such as “What happened next?”, “Who else was involved?” and “How did you know it was complete?” Ask for an example when someone gives a general judgement. Summarise your understanding and let them correct it. A pause does not need to be filled with your own interpretation.

05Investigate the experience without defending the idea

An illustrative participant says: “We kept having to call them.” That does not yet establish a need for a portal. Ask about the last repair: when they called, whom they spoke to, what they needed and what response they received. They may have needed to approve a more expensive repair. A status display alone would not solve that problem.

Another invented response might be: “The update was in my email, but my colleague needed confirmation for their customer.” This raises a question about transferring information between roles. Record it as a hypothesis to investigate, not an immediate requirement for team accounts.

When a participant suggests a feature, acknowledge it and explore the situation that prompted the request. Give equal attention to cases where the current approach works. The goal is not to extract a problem from every conversation at any cost.

GOV.UK’s in-depth interview guidance also covers neutral questions and specific stories. If you later show a proposed solution, make that a separate activity with a different purpose. Responses after the pitch are no longer an independent account of the original problem.

06Turn notes into traceable evidence

After each interview, complete a short record: role and context, specific incident, current process, consequences, previous attempts, contradictions and open questions. Label an estimate as an estimate. Separate exact quotations from paraphrases, and the team’s assumptions from what was actually said.

GOV.UK’s analysis guidance separates observations from interpretations. Compare findings within relevant groups and actively examine contradictions. Two employees of one company are not equivalent to independent accounts from two different businesses.

Qualitative interviews do not establish a representative market percentage. A recurring issue provides a direction for further investigation, not a forecast of future customers. If you need to understand how the problem crosses touchpoints, continue with customer journey mapping.

07Agree the next test, not a collection of feature requests

Write a decision and its reasoning. For example: “First, check whether the service operation can provide a reliable current completion date. Then test how customers receive it.” A portal without dependable information would move the same problem onto another screen.

• A recurring issue with a documented consequence: design the smallest useful next experiment and its expected outcome.
• Conflicting needs between roles: separate the groups and investigate the missing perspective.
• Compliments without a specific experience: revisit recruitment or questions before committing to development.
• A current solution that works well: investigate a different problem or defer the investment.

An interview alone does not demonstrate willingness to buy a particular product. Our idea-to-MVP guide covers further demand validation. If the uncertainty concerns using a proposed interface, run an interactive prototype test. With a clear learning goal, define the scope of the first release.

At Listify, we can help turn an uncertain idea into testable questions, design inputs and a decision about the next step. The outcome should be a usable brief alongside a record of what remains unknown. Prototyping and application development can follow when the evidence provides a sound reason to proceed.

Any subsequent web application development can be scoped around the validated task, required data and a measurable outcome for the first release. You do not need to arrive with a finished feature list.

08Frequently asked questions about customer interviews