B2B Customer Discovery Interviews: How to Learn What Buyers Won’t Tell a Stranger

B2B customer discovery interviews are not about persuading a stranger to hand over their company’s internal process. They are about earning enough trust to understand a specific job, the friction around it, and whether fixing that friction is important enough for someone to change how they work.

A recent discussion in r/SaaS captured a common founder concern: how can you validate a vertical AI product before building it when prospective customers may be reached through cold outreach and understandably protect sensitive operational information? The useful answer from the community was simple: do not open by asking for “the process.” Ask about a recent annoyance, a failure, or the spreadsheet someone had to repair. That distinction turns an invasive research request into a practical conversation about work. (reddit.com)

For founders planning a six-to-nine-month build, this is more than an interviewing tactic. It is a way to reduce the biggest early-stage risk: spending months automating a workflow that is inconvenient but not urgent, sensitive but not accessible, or interesting to users but impossible to buy.

Why prospects will not explain their internal process

When a founder asks, “Can you walk me through your internal process?”, the recipient has to make several uncomfortable calculations at once. Are they exposing confidential information? Will their answer make them look inefficient? Is this founder trying to sell them something? Do they have time for an abstract conversation with a stranger?

In a regulated, operationally complex, or traditionally “boring” industry, the hesitation is even more rational. The process may involve customer data, pricing rules, proprietary know-how, regulated documents, contractual obligations, or informal workarounds that management would rather not advertise. An employee may not be authorized to discuss any of it, even if they personally want the problem fixed.

That does not mean discovery is impossible. It means the unit of research must get smaller.

Instead of trying to map an entire business operation, investigate one recurring job. Instead of asking for trade secrets, ask for a specific recent incident. Instead of requesting a 30-minute “discovery call,” request a brief perspective on a problem the prospect experiences firsthand.

The central insight from the Reddit conversation is worth treating as a research rule: people may guard their process, but they are often willing to complain about what went wrong this week. That is where the evidence is.

The difference between a process question and an incident question

Compare these two openers:

• “I’m researching how companies manage compliance documentation. Can you walk me through your internal process?”
• “When a compliance document arrives incomplete or late, what usually happens next for your team?”

The first asks the prospect to educate you, assess confidentiality risk, and volunteer a broad operational map. The second asks them to recall an event they have already lived through. It is narrower, easier to answer, and far more likely to reveal actual behavior.

A useful B2B customer discovery interview is built around evidence of past behavior, not generic statements about future preferences. Y Combinator’s guidance on talking to users similarly emphasizes learning from real customer behavior and using interviews to test what should become an MVP, rather than treating a conversation as a request for feature ideas. (ycombinator.com)

The goal of B2B customer discovery interviews

The goal is not to get validation for your idea. It is to build a defensible picture of a problem worth solving.

That picture should answer five questions:

1. Does the problem happen often enough? A once-a-year irritation rarely supports a standalone workflow product unless the consequence is extreme.
2. Is the consequence meaningful? Look for lost revenue, delayed delivery, rework, compliance exposure, customer churn, staff burnout, or missed deadlines.
3. Who feels the pain versus who controls the budget? The person doing manual work may be an enthusiastic user but not the buyer.
4. What do they do today? Existing tools, spreadsheets, outsourced labor, email chains, checklists, and ignored problems are all competitors.
5. What would have to be true for them to adopt a new system? Security, integration, accuracy, audit trails, procurement approval, data access, training, and ownership matter as much as product functionality.

A founder who obtains answers to these questions does not need a prospect’s complete operating manual. They need enough repeated evidence to make an informed hypothesis: “This role has this painful job, in this context, and a credible solution could create measurable value.”

Steve Blank’s customer-development framework has long framed startup work around getting outside the building, testing hypotheses, and validating the problem before treating a proposed solution as settled. His more recent teaching materials still emphasize field interviews, evidence reviews, and permission to pivot as central parts of the process. (steveblank.com)

Pick a narrow job before you contact anyone

“Vertical AI for construction,” “AI for insurance,” or “AI for legal teams” is not an interview topic. It is a market label. It is too broad to produce a useful outreach message or a clear conversation.

Start with a role, a trigger, and a desired outcome.

For example:

• A property-management coordinator receives a maintenance request and needs to route it correctly before a tenant escalates.
• A freight broker receives documents from a carrier and needs to identify missing fields before a shipment is delayed.
• An accounting manager receives vendor invoices and needs to resolve exceptions before month-end close.
• A clinic administrator receives referrals and needs to identify missing information before scheduling can proceed.
• A commercial insurance account manager receives renewal materials and needs to compare changes before the client deadline.

Each example is a “job episode”: something happens, a person has to act, information moves between systems, and a result is expected. That is a far better unit of discovery than an industry-wide process map.

Use a job-episode hypothesis

Before outreach, write one page containing only assumptions. A useful template looks like this:

This document is not a strategy deck. It is a list of things you may be wrong about.

Your interviews should be designed to falsify the assumptions quickly. If most people say the suspected issue happens rarely, is already handled well by an incumbent, or cannot be changed because of a binding workflow, that is progress. You have learned before building.

How to write cold outreach that earns a response

Cold outreach is harder in low-glamour industries, but it also creates an advantage for founders who sound specific, respectful, and prepared. Most outreach fails because it looks mass-produced, leads with an AI pitch, or asks for too much.

The recipient should understand three things immediately: why you selected them, what small question you are asking, and what they are not being asked to disclose.

A practical outreach formula

Use this sequence:

1. Relevant observation: Name the role, job, or operational moment you are researching.
2. Acknowledge boundaries: State that you are not asking for confidential information.
3. Make the request tiny: Ask for 10–15 minutes or one reply to a concrete question.
4. Offer an easy alternative: Invite them to forward the note, answer asynchronously, or share a sanitized artifact.
5. Do not pitch too early: The initial purpose is learning, not a demo.

Here is a workable example:

Hi Maya — I’m researching how AP teams handle invoice exceptions when documents arrive incomplete or do not match the PO. I’m not looking for confidential details or a sales call; I’m trying to understand where the follow-up work tends to pile up. Would you be open to a 15-minute conversation about the last time an exception delayed payment? If someone else owns this workflow, I’d appreciate a pointer.

The message works because it has a defined scope. It also gives the prospect a dignified way to decline, redirect, or keep the discussion at a safe level.

Avoid leading with “I’m building an AI platform that transforms…” That framing creates immediate vendor skepticism and can make a prospect feel they are being recruited into a sales funnel. At the earliest stage, “AI” is usually your implementation hypothesis, not the customer’s problem statement.

Build a small, high-quality list

Do not send 1,000 generic messages before learning from the first ten. Build an initial list of 30 to 50 people in the same role, company band, and operational context. Personalize enough to demonstrate that you understand their world, but do not pretend to know their pain before they have described it.

Basic deliverability matters, especially when research depends on a small number of high-value contacts. Founders can reduce avoidable bounces by using an email address verification tool before launching a carefully targeted sequence.

A reasonable early target is not “a 10% reply rate.” It is a set of conversations rich enough to reveal patterns. Five detailed calls with people doing the same job can be more useful than 50 vague replies from mismatched contacts.

Ask about the last time the problem happened

The best discovery question is usually time-bound and concrete: “Tell me about the last time…”

A recent event has actors, tools, timestamps, handoffs, exceptions, and consequences. It forces the conversation away from polished company narratives and toward the messy reality where valuable software opportunities live.

Questions that uncover workflows without demanding secrets

Use questions like these:

• “Can you walk me through the last time this task became difficult?”
• “What triggered it, and what did you need to accomplish?”
• “What happened first after you noticed the issue?”
• “Who else had to get involved?”
• “Where did the information live at that point?”
• “What did you use: a system, a spreadsheet, email, chat, or something else?”
• “What made the situation slow, frustrating, or risky?”
• “How did you know it was finally resolved?”
• “What did it delay or prevent?”
• “How often does a version of this happen?”
• “What have you already tried to make it better?”
• “If you could remove one part of that experience, which part would it be?”

These questions do not require the contact to reveal customer identities, pricing, business rules, credentials, or sensitive data. Yet they can uncover where documents arrive, where work changes hands, why exceptions occur, and why existing tools fail.

Questions to avoid in the first conversation

Some questions are not forbidden, but they are low-signal or premature:

• “Would you use an AI tool that does this?”
• “What features would you want?”
• “How much would you pay?”
• “Can you explain your whole process?”
• “Would my product save you time?”
• “Who is the decision-maker?” asked before you understand the user’s problem.

These invite speculation, politeness, or defensiveness. A prospect may say they would buy an imagined solution because it costs them nothing to be encouraging. That is not evidence of a market.

Better evidence includes a current workaround, a budget already allocated to a related tool, an internal project to solve the issue, executive attention after an incident, or willingness to introduce you to the person responsible for the outcome.

Ask to see artifacts, not sensitive systems

One of the strongest suggestions in the community response was to ask whether someone can show the spreadsheet, document, checklist, or template they actually use. That is often a much easier request than a formal 30-minute discovery interview, and it can expose more operational truth in minutes than abstract discussion does. (reddit.com)

But “show me the spreadsheet” needs careful handling. Never pressure a contact to screen-share customer data, credentials, pricing information, proprietary reports, or anything outside their authority to disclose.

Instead, invite safer forms of evidence:

• A blank version of a checklist or template.
• A redacted example document.
• A recreated, fictionalized example of an exception.
• A description of the columns or fields in a tracker.
• A screenshot with sensitive values obscured.
• A walkthrough of the steps without sharing the underlying records.

The point is not to collect their data. It is to understand the structure of the work.

What artifacts reveal that interviews miss

A spreadsheet can reveal that the real product is not “document extraction” but exception ownership. A shared inbox can reveal that the bottleneck is not classification but unclear handoff. A checklist can reveal that the workflow requires proof, traceability, and approval—not simply a faster answer from a model.

Artifacts also expose the language customers use. Their column headings, labels, and status names can tell you how they conceptualize the job. That language should influence your product positioning, onboarding, data model, and eventual sales copy.

If a prospect cannot share anything, respect that boundary. Ask them to describe the artifact at a high level: “What are the five things you track every time?” or “What makes an item turn red?” You can still learn the workflow logic without seeing the underlying records.

Separate the user, champion, buyer, and blocker

A classic B2B discovery mistake is treating the interviewee as “the customer.” In many vertical SaaS markets, several people matter:

• User: Does the work every day and feels the friction.
• Champion: Wants the problem fixed and helps move the idea internally.
• Economic buyer: Controls a budget or can justify the spend.
• Technical or security approver: Evaluates integration, privacy, security, and reliability.
• Process owner: Decides whether a workflow may change.
• Blocker: May not dislike the product, but has enough risk or workload to stop adoption.

You need to understand all of them before treating a problem as commercially validated.

A coordinator may desperately want a tool that removes repetitive work, while a manager may fear losing control, and IT may refuse an application that needs broad access to customer records. This is not a reason to abandon the idea. It is a reason to refine what you are building and how you sell it.

Map the buying path early

Near the end of a discovery conversation, ask questions such as:

• “If your team wanted to improve this next quarter, who would need to agree?”
• “Would this be solved by your team, IT, operations, finance, or an outside vendor?”
• “What would someone need to trust before using a new tool here?”
• “Is there an existing software category or budget that this would replace?”
• “Have you purchased something similar before? What made that process easy or difficult?”

These questions are not a hard sales close. They help you distinguish a real opportunity from a problem that is personally frustrating but structurally unsellable.

Why AI makes trust part of the product

For a traditional SaaS product, prospects may mainly ask whether it integrates with their systems and saves time. For an AI product, especially one touching internal documents, decisions, customers, or regulated work, they will also ask what the model sees, what happens when it is wrong, who is accountable, and whether people can review its outputs.

That means early research should investigate trust requirements alongside workflow pain.

NIST’s AI Risk Management Framework organizes AI risk work around four functions: govern, map, measure, and manage. The framework is voluntary, but it is useful language for founders because it pushes the conversation beyond model capability toward operational controls, evaluation, and accountability. (nist.gov)

Trust questions to include in discovery

For every promising use case, ask:

• “What is the worst realistic error this system could make?”
• “Which outputs would need human review?”
• “What evidence would a reviewer need before acting on a recommendation?”
• “What data could never leave your environment?”
• “Would an audit trail matter? What would it need to show?”
• “How accurate would this need to be before it could save real time?”
• “What would make your security or compliance team immediately reject it?”

The answers shape your initial product scope. Sometimes they point to a safer wedge: drafting instead of sending, prioritizing instead of deciding, extracting fields for review instead of making an irreversible update, or operating on a customer-controlled dataset instead of a broad enterprise integration.

Data protection expectations can also affect viability. The UK Information Commissioner’s Office describes a data protection impact assessment as a process for identifying and minimizing project risks, and says one is required when processing is likely to create high risk for individuals. Requirements will depend on jurisdiction and use case, so founders should seek qualified legal guidance rather than treat a framework as legal advice. (ico.org.uk)

Turn conversations into evidence, not anecdotes

Discovery fails when founders collect memorable quotes but cannot distinguish a signal from an outlier. The solution is a consistent note-taking and synthesis process.

After each interview, do not write “They liked the idea.” Record observable facts:

• The exact job episode discussed.
• What triggered the work.
• The tools and artifacts involved.
• The number of people or handoffs involved.
• The failure mode.
• The business consequence.
• The workaround.
• The person who owns the outcome.
• The adoption constraints.
• Any evidence of urgency or budget.

Then score the opportunity cautiously. A simple matrix can help:

Do not turn this into fake precision. The matrix exists to make comparisons explicit. A problem that scores highly on pain but poorly on access may still be a valuable business, but it could require a different initial product or go-to-market motion.

Look for repetition, not unanimous agreement

You do not need every interviewee to say exactly the same thing. In fact, identical answers can be a warning that your questions are leading.

Look for repeated patterns across similar roles and contexts: the same trigger, the same workaround, the same bottleneck, the same consequence, and the same buying objection. When those patterns appear, you can begin testing a narrower solution hypothesis.

Steve Blank has described the purpose of customer development as testing hypotheses with evidence rather than assuming the founder already knows the customer problem and required features. That is the appropriate mindset here: interviews are experiments, not approval sessions. (steveblank.com)

When to sell before you build

“Sell before you build” is sensible only when it means validating commitment, not collecting vague compliments.

For a B2B AI product, the first commitment may be a paid design partnership, a letter of intent, a pilot agreement, access to sanitized sample data, an introduction to the buyer, or a scheduled technical review. The appropriate ask depends on how mature the idea is and how much trust has been earned.

A practical progression from research to pre-sales

1. Problem interviews: Learn about recent workflows and identify a repeated pain.
2. Playback sessions: Show prospects your understanding of the problem in their words. Ask what you missed.
3. Concept test: Present a narrow workflow, not a broad platform. Explain inputs, outputs, review steps, and boundaries.
4. Prototype test: Use a clickable mockup, concierge service, or manual workflow to test value before automation.
5. Pilot conversation: Define success metrics, data access, scope, timelines, review process, and commercial terms.
6. Design-partner agreement: Secure a commitment that reflects genuine effort or budget, not just interest.

A strong pre-sale conversation includes a question such as: “If we could reduce this step from two hours to 15 minutes while keeping a reviewer in control, what would need to be true for you to pilot it?”

That is more useful than asking, “Would you buy it?” It surfaces the conditions of adoption: accuracy thresholds, integration needs, security review, training, contract length, internal ownership, and timing.

Common mistakes founders make in difficult verticals

The concern behind the original Reddit post is valid: access may be hard. But access problems are often worsened by avoidable research mistakes.

Mistake 1: Asking people to design your product

Prospects understand their work better than you do, but they are not responsible for your roadmap. Ask them to describe their world. Your role is to synthesize the opportunity and propose a solution.

Mistake 2: Treating interest as intent

“Cool idea” is not validation. A referral, sample workflow, pilot conversation, budget discussion, or willingness to involve a colleague is stronger evidence.

Mistake 3: Over-indexing on one friendly contact

A single enthusiastic user can lead you toward a highly personalized consulting project. Keep interviewing adjacent companies and roles until you know whether the need repeats.

Mistake 4: Pitching AI before naming the job

Customers generally do not buy “AI.” They buy reduced rework, faster turnaround, fewer missed deadlines, greater capacity, fewer errors, or better visibility. Lead with the operational result.

Mistake 5: Ignoring governance until after product-market fit

If your product will touch sensitive data or make consequential recommendations, security, oversight, reliability, and auditability are not enterprise polish added later. They can determine whether a buyer will evaluate you at all.

Mistake 6: Confusing an inaccessible market with a bad market

Some verticals require introductions, industry associations, consultants, conferences, channel partners, or a credible domain expert. The answer may not be more cold email. It may be changing how you earn access.

A 30-day customer discovery plan

Founders do not need to solve market research perfectly before beginning. They need a disciplined first month that converts uncertainty into evidence.

Week 1: Choose a beachhead and write hypotheses

Pick one role, one job episode, one company type, and one suspected pain. Create the interview guide, outreach message, and evidence scorecard. Resist the urge to research three industries at once.

Week 2: Run the first interviews

Contact 30 to 50 carefully selected prospects. Aim for five to eight conversations, plus asynchronous replies. After every call, update the hypothesis document before scheduling the next batch.

Week 3: Synthesize and narrow

Review notes for repeated triggers, workarounds, costs, and blockers. Eliminate assumptions that did not survive contact with reality. Write a one-page problem brief using customer language.

Week 4: Playback and test a wedge

Return to the strongest contacts with a short visual or workflow description. Ask whether your framing is accurate, what would make it unsafe or unusable, and whether they would explore a pilot if you built the narrowest credible version.

At the end of 30 days, you should be able to state one of three conclusions:

• The problem is frequent, expensive, accessible, and worth pursuing.
• The problem is real but the initial solution or target segment is wrong.
• The problem is not important enough, repeatable enough, or reachable enough to justify a six-to-nine-month build.

All three are valuable outcomes. The expensive failure is continuing to build because the original idea sounded promising.

The real advantage: become fluent in the work

Founders entering unfamiliar verticals sometimes think their disadvantage is lack of industry knowledge. In reality, lack of fluency can become an advantage if it makes them curious rather than overconfident.

The goal is not to pretend you are already an insider. The goal is to become the outsider who asks precise questions, remembers the details, respects confidentiality, and recognizes patterns across conversations that no individual operator can see alone.

That is why the best B2B customer discovery interviews do not feel like extraction. They feel like a thoughtful conversation with someone who has taken the time to understand a frustrating part of the recipient’s day.

Start small. Ask about a recent incident. Follow the work, not the org chart. Seek artifacts rather than secrets. Separate pain from purchasing power. Test trust requirements alongside product value. Then ask for a commitment that costs the prospect something meaningful.

If you can do that before writing months of code, you will not merely have better interviews. You will have a sharper product thesis, a more credible sales narrative, and a much better chance of building AI software that a difficult vertical can actually adopt.

FAQ

How many B2B customer discovery interviews should I conduct?

There is no magic number. Begin with 10 to 15 interviews in one tightly defined segment, then continue until the same job episodes, workarounds, consequences, and adoption blockers recur. If every conversation reveals a different problem, your target segment is likely too broad.

Should I mention AI in cold outreach?

Usually, not in the first sentence. Lead with the operational job you are researching and the specific pain you want to understand. Mention AI only when it helps explain the boundary of a concrete concept or when the prospect asks how you might solve it.

What if prospects refuse to discuss their internal workflow?

Narrow the request. Ask about a recent non-sensitive failure, a generalized process step, a blank template, a redacted example, or the tools involved. Respect the boundary; pushing for confidential details reduces trust and produces worse research.

Can I sell a vertical AI SaaS product before it exists?

Yes, but sell a scoped pilot, design partnership, or outcome-oriented commitment rather than a vague future platform. Be transparent about what exists today, what will be built, what success looks like, and what the customer must contribute.

What counts as strong validation for a B2B AI idea?

Strong validation combines repeated, costly pain with evidence of a viable buying path. Look for existing workarounds or spend, an identified owner, willingness to involve decision-makers, acceptance of a pilot discussion, and clear requirements around data, security, and human review.