How to interview SaaS customers for marketing decisions

A useful customer interview helps you understand a real situation well enough to make a marketing decision. Ask how someone encountered a problem, assessed alternatives, and tried to solve it. Keep their account separate from your interpretation, then use the evidence to choose what to test next.

Start with a decision you need to make

Choose a question that could change your work. You might need to decide which audience to prioritize, what a launch page should explain, or why suitable people abandon an evaluation. “Learn about our customers” is too broad to guide a useful interview.

Write your current explanation and at least one plausible alternative. If you think onboarding fails because the instructions are unclear, consider whether the integration is unsuitable or the task lacks urgency. Preparing alternatives makes it easier to notice evidence that challenges your first view.

Select a recent episode relevant to the question. A customer who just evaluated your product can describe a buying process. A person who stopped during setup can describe that obstacle. Neither automatically represents every potential customer.

Recruit people who can describe the relevant experience

Choose participants through the workflow you want to understand. Include different outcomes where useful: customers who reached a result, people who did not finish, and people who solved the problem another way. Keep these groups identifiable in your notes.

Describe the purpose, expected effort, and how you intend to use the conversation. Make recording a separate, explicit agreement. A person can participate without agreeing to have their name, words, or company published.

If you offer an incentive, keep it independent of positive feedback or a purchase. Record the recruitment route because it may affect what you hear. Helpful people in your personal network can provide useful observations, but their willingness to assist may differ from that of a stranger evaluating the product.

The audience definition guide can help establish who is relevant. Avoid recruiting only people whose stories are likely to confirm your preferred message.

Build a short discussion guide

Organize questions around the episode, not around your feature list. Start with context, move through the events in order, and finish with the outcome and unresolved questions.

Useful prompts include:

• What was happening when this became something you needed to address?
• Walk me through the last time you did this work.
• What did you try first, and what happened?
• Which alternatives did you consider, including doing nothing?
• Who else took part in deciding or using the solution?
• What made the next step easy or difficult?
• What changed after you tried it?

Use follow-up questions to understand a specific detail: “What do you mean by unreliable?” or “What happened after the check failed?” Avoid turning the interview into a checklist that prevents you from following an important answer.

Ask for episodes instead of predictions

“Would you use a tool that saves time?” encourages an agreeable answer without telling you how the person works. “What happened the last time this task took longer than expected?” gives them something concrete to describe.

When someone says a problem is important, ask how it affected a real decision. Did they assign work, change a release, seek budget, or tolerate the issue? Consequences and actions provide more useful context than a hypothetical urgency score.

Do not assume that every participant remembers events precisely. Ask whether they can distinguish what happened from what they think usually happens. If an artifact would help, invite them to describe it or share only what they are comfortable sharing. You do not need access to confidential records to understand the sequence.

This is empathy in practice: understand the circumstances before deciding what the person's behavior means. A stalled evaluation may reflect a competing obligation rather than indifference to the problem.

This sequence helps recover an actual workflow. It is a discussion aid rather than a script or a survey of how common the experience is.

Open the full-size graphic

Listen without supplying the answer

Give the participant time to finish. Use their language in follow-up questions instead of substituting your product terminology. A question such as “How did that affect the release?” leaves more room than “Did that hurt your productivity?”

If they ask for help with your product, decide whether to pause research and help, or schedule a separate support conversation. Record the change. An interview that becomes assisted onboarding has a different context from an independent account of prior behavior.

Keep product explanations short until you understand the episode. A demonstration can help investigate how someone interprets a capability, but reactions after the demo should be recorded as such. They are different evidence from what someone said before seeing the product.

You can be warm and useful without praising every answer. Repeated approval can unintentionally teach someone which responses you want.

Replace leading questions with answerable prompts

These rewrites preserve the topic without putting your conclusion into the participant's mouth:

At the end, recap one or two observations and ask what you misunderstood. A participant correcting your summary can be more informative than another broad question. Record the correction before writing the synthesis.

Capture observations and interpretations separately

Use a note format that retains the question, the relevant answer or paraphrase, its context, and your interpretation. Mark direct quotes distinctly. If your notes are approximate, do not later present them as verbatim quotations.

A fictional observation: “The engineer checked logs in two systems before deciding whether to rerun a failed API test.” One interpretation is that gathering context creates friction. Another is that the extra check is a necessary safeguard. Ask what each system contributes before concluding that one should disappear.

Capture disagreement, exceptions, and evidence against your hypothesis. A clean story that omits awkward details may be easier to present but less useful for making the decision.

Document the interview date and participant's role using only the identifying information you need. Keep raw material appropriately restricted. A public guide or team summary usually needs less detail than the original notes.

The fictional observation supports a follow-up question. It does not by itself establish that the second system is unnecessary or that the product should remove the check.

Open the full-size graphic

Compare interviews without pretending they are a survey

After each conversation, summarize the episode and its implications. Then compare interviews using the same categories: trigger, workflow, alternative, decision participants, obstacle, result, and remaining uncertainty.

Repeated observations can strengthen a hypothesis, but a small selected group does not establish how common a behavior is across the market. “Three participants described the same handoff problem” is a defensible summary of those conversations. “Most SaaS teams have this problem” requires different evidence.

Look for conditions that explain differences. A buyer and a user may describe different concerns. A team with an existing internal tool may evaluate your offer differently from one using a manual process. These differences can change audience selection or the offer itself.

Turn the evidence into a bounded change

End the research round with the decision it was meant to inform. State what you observed, what it suggests, what remains unknown, and the next action. A useful action might be testing clearer compatibility information, recruiting another audience, or observing an evaluation rather than rewriting every message at once.

For messaging, use the SaaS messaging guide to connect claims with evidence. For a broader market choice, use positioning against real alternatives.

Download the customer interview guide and evidence log to prepare questions, capture episodes, and record a decision. If you want to publish a customer's story, use a separate case study process with agreed wording and publication approval.

Explore the SaaS growth guides and templates to choose another problem to work on.