Buyer Research for B2B SaaS Founders

Buyer research fails when the question is too broad. “Why would companies buy our product?” produces a mixture of roles, use cases, and opinions that cannot guide a sales message. Instead, define one buyer-and-problem pair: a particular role, in a particular operating context, trying to resolve one recurring situation. For example: “How does a RevOps manager at a 50–200 person SaaS company experience unreliable lead-routing?” This is narrow enough to investigate and broad enough to inform an initial go-to-market motion. Do not start with a persona document full of assumed traits. Start with a problem episode: a recent moment when the buyer noticed something was wrong, tried to handle it, and faced consequences. Your goal is not to confirm that the problem exists in theory. It is to understand how the buyer labels it, what triggers action, who becomes involved, and what makes solving it feel worth the effort.

• Write a one-sentence research scope: “I am studying how [role] at [company context] handles [specific recurring problem].”
• Exclude adjacent roles for the first round. A VP Sales and a RevOps manager may both care about routing, but they can have different evidence requirements and buying authority.
• Choose a problem with observable workarounds. If you cannot name the current workaround, your scope is probably still too abstract.

A small initial customer base is not a reason to delay research; it is a reason to be precise about whom you include. Use every available source, but keep the roles distinct. Customers can explain why they adopted your product. Prospects who did not buy can reveal objections and alternatives. Former colleagues, friendly operators, and relevant community members can help you understand the workflow without pretending to validate demand. Aim for contrast rather than volume. If you have four customers, do not interview all four about the same generic topic and call the pattern proven. Select people who differ on one meaningful variable: company size, maturity of the process, urgency of the problem, or whether they own the budget. Then compare what remains consistent. A repeated sequence across a small group is more useful than a long list of isolated feature requests.

• Start with 6–10 conversations: 3–5 current or former customers, 2–3 qualified non-customers, and 1–2 knowledgeable adjacent practitioners.
• Recruit for a recent experience. Ask for people who handled the issue in the last 90 days, not people willing to discuss strategy generally.
• Keep a source label for every insight: customer, lost deal, prospect, practitioner, or internal assumption. Do not treat them as equivalent evidence.
• If access is limited, ask each participant for one introduction to someone with the same job but a different company context.

An interview should reconstruct a real event, not collect reactions to your positioning. Asking, “Would you use a tool that automates this?” invites politeness and speculation. Asking, “Tell me about the last time this broke” produces details: what happened first, which systems were checked, who complained, how long the workaround lasted, and what risk the buyer tried to avoid. Prepare a short discussion guide, but use it as a route map rather than a script. Begin with the participant’s role and workflow, then move into one recent incident. Delay any mention of your product until the end, if you mention it at all. For customer interviews, explicitly separate the pre-purchase experience from their current experience; otherwise, knowledge of your product will rewrite how they describe the past.

• Open with context: “What are you responsible for, and where does this process sit in your week?”
• Find the episode: “When did this last become a problem? What made you notice?”
• Follow the sequence: “What did you do next?” “Who else got involved?” “What did that cost in time, risk, or missed work?”
• Expose alternatives: “How were you handling it before?” “What did you consider instead?” “Why did that option not stick?”
• Close with language: “If you had to explain this problem to your manager, what words would you use?”

During the interview, prioritize specificity over speed. When a participant says, “Reporting was a mess,” do not translate it into your own product language. Ask what “mess” meant in practice. It might mean manual spreadsheet reconciliation, arguments over definitions, delayed board preparation, or lost confidence in pipeline numbers. Those are different problems with different buyers, urgency, and proof requirements. Avoid leading the witness. If you ask, “Was the main issue that your data was fragmented?” you have supplied the answer. Better: “What made the process difficult?” If the participant introduces fragmentation, ask for an example. A useful rule is that each important claim needs an event, artifact, or consequence. “We needed better reporting” becomes useful only when connected to a concrete deadline, decision, or failed workaround.

• Record with permission, or take structured notes in three columns: exact words, observed facts, and your interpretation.
• Mark direct language with quotation marks, but do not invent clean quotes after the call. Paraphrase when your notes are incomplete.
• Ask one follow-up for every vague noun: issue, visibility, efficiency, alignment, scale, and automation all need unpacking.
• Write a five-minute debrief immediately afterward: trigger, current workaround, consequence, stakeholders, alternatives, and unresolved questions.

Do not summarize interviews as a pile of notes. Create a problem map that shows the buyer’s journey from status quo to action. Across interviews, look for the same causal chain: trigger, diagnosis, attempted workaround, consequence, internal conversation, evaluation criteria, and reason to change or delay. This tells you how the buyer sees the problem, rather than merely which features they requested. Separate frequency from importance. A complaint mentioned often may be minor, while a concern mentioned by only a few people may block purchase because it creates legal, financial, or operational risk. Tag each finding by evidence strength and decision relevance. For a small sample, call something a hypothesis unless it appears in multiple comparable conversations or is independently supported by observed behavior such as an existing budget, a documented process, or a live workaround.

• Use a simple table with rows for interviews and columns for trigger, words used, workaround, consequence, stakeholders, alternatives, and buying criteria.
• Mark a pattern “emerging” after two similar accounts, “credible” after three comparable accounts or one strong behavioral confirmation, and “unresolved” when accounts conflict.
• Write a problem statement in the buyer’s frame: “When [trigger] happens, [role] must [job] but currently uses [workaround], creating [consequence].”
• List contradictions deliberately. If larger companies describe the issue as governance while smaller companies describe it as speed, split the segment rather than averaging the answers.

Research is complete only when it changes a decision. Start with messaging: lead with the trigger and consequence the buyer recognizes, not your product category. A hypothetical outreach message to a RevOps manager might refer to lead-routing exceptions after a territory change, rather than claiming to offer “intelligent workflow automation.” The first phrase helps a relevant buyer recognize a familiar event; the second requires them to interpret your category. Then use the map to decide who to contact, what to test, and what not to build. If interviewees say the operational owner feels the pain but a finance leader approves spend, prepare different conversations for each role. If they consistently use a spreadsheet because approval is the bottleneck, adding more dashboard features may not address the real obstacle. Puffle helps teams find relevant people, research them, and prepare email and LinkedIn outreach for review; use research findings to define the roles, triggers, and language that make that outreach worth reviewing.

• Create one testable message per trigger, not one broad value proposition. Measure replies and booked conversations, then ask new respondents whether the trigger is accurate.
• Build a disqualifier list. For example, do not prioritize companies that lack the systems or process complexity that creates the problem.
• Review the map every 10 conversations or after a meaningful change in segment, product, or pricing.
• Keep an assumption log with an owner and next test. This prevents early interview patterns from quietly becoming permanent “facts.”

If you want help doing this work, these Puffle pages show the product in more detail.

• How Puffle works
• Outbound automation
• Browse all GTM guides