Customer Discovery Questions for B2B Founders: What to Ask, Who to Ask, and What to Do Next

When we were building Data Solver, we didn’t have money for a polished demo. We didn’t have a working product. What we had were sketches — hand-drawn wireframes, scanned and turned into simple diagrams — and a very clear sense of the problem we were trying to solve.

Those sketches opened more doors than we expected. Not because they looked impressive, but because they showed we had thought about it. And the questions we asked in those early conversations — about the problem, about the customer’s current process, about what solving it would actually be worth — turned out to be more valuable than any demo we could have shown.

Customer discovery questions are the structured questions founders ask potential customers before a product exists, designed to validate whether the problem is real, who has it most acutely, and whether the person in the room is actually your early-stage customer. The right questions shape your go-to-market strategy before you've committed to building anything.

This guide covers how to structure those conversations, what to ask at each stage, and what the answers are actually telling you — including when a conversation that doesn’t land isn’t a failure, but a signal you’re talking to the wrong person.

What are customer discovery questions and why do they matter?

Customer discovery questions are not sales questions. They’re not feature requests and they’re not validation-seeking either. They’re genuine attempts to understand whether the problem you think you’re solving is the problem people are actually experiencing — and whether the person you’re speaking to is positioned to help you understand it properly.

The instinct for most founders — especially those with engineering backgrounds, which was true for me — is to skip straight to the solution. You’ve been thinking about this problem for months. You’ve got a direction. You want to talk about it. That instinct is worth resisting, because the moment you introduce the solution, you change what the customer tells you. They start evaluating rather than reflecting. The feedback you get becomes filtered through what you’ve already said.

The right customer discovery questions keep you in listening mode longer. They get the customer talking about their current experience, their workarounds, their frustrations. The signal you pick up in that phase — specific language, emotional cues, how often the problem actually happens — is what shapes everything downstream: your product decisions, your investor pitch, and who you approach first when you’re ready to sell.

For B2B startups specifically, this matters more than many founders assume. Enterprise sales cycles are long. Procurement involves multiple stakeholders. If you spend months building something and then discover your target buyer doesn’t have the budget, doesn’t have the authority, or doesn’t feel the problem acutely enough — that’s time you don’t recover. Good discovery questions surface all of that early, when you can still act on it.

What customer discovery questions should you ask about the problem? (#problem-questions)

The first half of any discovery conversation has one job: establish whether the problem is real from the customer’s perspective, not yours.

At Data Solver, the conversations that gave us the most useful signal were the ones where we spent the first twenty minutes on the problem and the customer’s current process — before we mentioned anything about what we were building. The arc we used was consistent: problem first, impact second, solution third. Not the other way around.

Questions about the current experience

Start broad and let them tell the story. Avoid yes/no questions — you want the customer talking and yourself listening.

• “How do you currently handle [the thing you think is a problem]?”
• “Walk me through what that process looks like in practice.”
• “What breaks down most often when you’re trying to do this?”
• “How much time does that typically take you?”
• “What have you tried to fix it?”

That last question is particularly revealing. If someone has never tried to solve the problem, it may not be painful enough to drive a purchase. If they’ve patched together a complex workaround using multiple tools, manual steps, or something they’re slightly embarrassed about — that’s a strong signal the problem is real and the existing solutions are inadequate.

Questions about impact

Once the problem is established, shift to what it costs them — in time, money, or decisions made on incomplete information.

• “What does it cost you when that breaks down?”
• “What decisions are you making on incomplete information because of this?”
• “If this was working properly, what would be different?”

You’re listening for frequency, cost, and frustration. A problem that happens once a year and takes an hour to deal with is a different proposition from one that happens every week and costs someone a full day. The impact questions are also what give you the material for your investor buy-in conversations later — the clearest articulation of the problem’s value often comes directly from the customers who have it.

What to avoid in customer discovery questions

Asking whether they’d use your solution. Asking whether they think a product like yours would be valuable. These are leading questions that generate false positives. You want to understand the problem on their terms, which means asking about their experience, not about their opinion of yours. Rob Fitzpatrick’s The Mom Test is the most useful short read on this if you want to go deeper.

How do you know if you’re talking to the right early-stage customer?

This is the question most founders skip, and it’s the one that wastes the most time.

Not every potential customer is your early-stage customer. At Data Solver, we had conversations that ended before they started — not because the problem wasn’t real, but because the organisations we were talking to were simply not built to work with a startup at our stage. They were used to enterprise vendors. Procurement was a separate process. Their instinct was to evaluate us against a checklist designed for companies ten times our size.

The feedback from those conversations — “come back when the product is more developed,” “we’d need to see the full platform,” “security accreditation would be a requirement before we could consider this” — wasn’t a reflection of our product. It was a reflection of their buying process. And even if we’d impressed them in the room, we weren’t getting a sale. Recognising that signal early, rather than chasing it for months, was one of the more expensive lessons we learned.

Questions that filter for early-stage readiness

• “If you found something tomorrow that solved this, how would the decision to buy it typically work?”
• “Who else would be involved in making that call?”
• “Is there a budget already set aside for solving this, or would it need to be created?”
• “Have you ever worked with an early-stage startup before — brought them in before they had a full product?”

That last question is the most direct filter. Organisations that have never bought from a startup at an early stage have internal machinery that isn’t built for it. That doesn’t mean the problem isn’t real for them. It means they’re probably not your first customer.

The user versus buyer problem

There’s a separate but related issue in B2B that catches a lot of founders out: the user is rarely the buyer. The person who feels the problem most directly often doesn’t control the budget. At Data Solver, we had excellent conversations with end users — consultants, analysts, department heads — who genuinely understood the problem and were engaged with our thinking. But unless that person could make a purchasing decision, or had a clear path to the person who could, the conversation had a ceiling.

Questions that surface the real decision-maker

• “Are you the person who would make a decision like this, or would it need to go up to someone else?”
• “If you wanted to push for something like this internally, who would you need to bring along?”

The answers shape everything about how you follow up. If they’re the buyer, you pursue the relationship directly. If they’re not, you ask them to help you get to whoever is — a warm introduction from a genuine advocate is worth far more than cold outreach to a procurement function.

Understanding how early product decisions interact with the people who make them is something that extends to the founding team itself — worth reading alongside this if you’re navigating early alignment decisions internally.

How do you introduce your solution without turning it into a pitch?

Once you’ve established the problem is real and understood the customer’s current experience, you can introduce your thinking. Not a pitch. Not a demo. Your thinking — the direction you’re heading, the assumption you’re testing, the approach you’re considering.

Frame it as a hypothesis, not a solution

The difference matters. A pitch invites evaluation — the person starts assessing whether they’d buy it. A hypothesis invites collaboration — the person starts thinking about whether you’ve understood the problem correctly.

Something like: “We’re working on the assumption that the real issue is X — does that match what you’ve described?” Or: “Our approach is to tackle this from Y direction — is that the part of the problem that would actually move things for you?”

This keeps you in listening mode. It gives the person permission to tell you you’re wrong. And push-back at this stage — “actually, the bigger issue is Z” — is far more useful than agreement. Agreement tells you nothing. Redirection tells you where the real problem sits.

What you’re listening for

Whether they push back on your framing of the problem, not your solution. If they say “actually, the bigger issue is Z” — that’s the signal you came for. If they nod and say “yes, that sounds right” — probe further. Polite agreement is not validation.

The connection between how you frame the problem at this stage and how you eventually articulate product vision is tighter than most founders expect. The language customers use to describe their problem is often better product vision language than anything you’d write in isolation.

What visual aids do you need in a customer discovery meeting?

Less than you think. More than nothing.

In the early days of Data Solver — this was before AI-assisted design tools made prototyping fast and cheap — we couldn’t afford proper wireframes. What we had were hand-drawn sketches: paper diagrams of how we were thinking about the problem and how our solution would approach it. We scanned them, cleaned them up slightly, and brought them into investor days and early customer conversations.

What the sketches actually did

They weren’t impressive. They weren’t meant to be. But something consistent happened in those meetings: technical evaluators — the people who understood the problem space deeply — would lean into the sketches not to assess the product, but to probe our thinking. They’d challenge the architecture. Ask how we were approaching a particular constraint. Push back on our assumptions about the data model. The diagram wasn’t showing them a product. It was showing them how our minds worked.

That’s the job of early visual aids: give people something to react to. Something concrete enough to push back on, specific enough to start a real conversation, rough enough that they don’t feel they’re being sold something.

What’s changed and what hasn’t

Today, tools like Figma and Lovable make it possible to create a simple clickable prototype without significant cost or time. You might even put together something with mock data behind it that demonstrates the core interaction. But the principle hasn’t changed: you’re not trying to impress with finish. You’re showing that you’ve thought clearly about the problem and have a credible direction of travel.

What you actually need at each stage

• Before any conversations: a simple diagram of your thinking — how you understand the problem and your intended approach. Hand-drawn is fine.
• Once conversations are generating interest: a lo-fi clickable prototype covering the core use case. Not a full product, not a polished UI — the one interaction that makes the solution tangible.
• What to avoid: anything so developed it shifts the conversation from “help me understand your problem” to “let me show you what I’ve built.” The more finished it looks, the less honest the feedback you’ll get.

For more on calibrating prototype fidelity to purpose, the clickable prototype guide covers this in detail.

What customer discovery questions do you ask at the end of the conversation?

Know this before you walk in. Not afterwards.

If you go into a discovery conversation with no clear sense of what success looks like, you’ll walk out with a vague feeling about whether they liked you — and very little you can act on. The ask at the end needs to be specific, and it needs to match who’s in the room.

When they can open doors

If you’re talking to an investor, advisor, or well-connected potential customer, you’re not asking for money or commitment. You’re asking for a name.

“Is there someone you think we should be talking to?”

A warm introduction from someone who found the conversation credible is worth far more than any amount of general encouragement — and it’s a test of how seriously they actually took what you said.

When they’re a potential user without buying authority

Ask if they’d be willing to be a design partner. This framing does something specific: it shifts the relationship from “startup trying to sell me something” to “building this with me.” The chance to influence a product that might eventually solve your problem is genuinely attractive to people who feel that problem acutely — and in an enterprise context, where people rarely get a say in the tools they’re given, it taps into something real.

When they have some buying authority

You’re looking for a memorandum of understanding or a letter of intent. Not a sale. A written signal of serious intent. For investors, an MOU from a potential customer is worth considerably more than verbal encouragement from ten others. And for you, it’s the proof you need to know whether the problem is real enough for them to commit — even at an early stage.

At Data Solver, we used all of these depending on who was in the room. The MOU was the primary ask when we had genuine traction with someone who understood the problem and had the authority to act. The design partner framing worked when someone was enthusiastic but couldn’t make a decision alone. And some of the most valuable conversations ended with just a name — one person we should call — who turned out to be more receptive than anyone we’d approached directly.

The one rule that applies across all of these

Be honest about where you are. Don’t suggest the product is more developed than it is. The cost of honesty in a first meeting is small. The cost of overpromising — and then failing to deliver — is losing the relationship entirely. If you can’t win a pilot on honest terms, you’ll never win them as a long-term customer.

This connects directly to building your sales pipeline before the product is ready — the signals you gather in discovery conversations are the foundation everything else is built on.

How do you tell useful feedback from polite encouragement?

Not all feedback is equal. Learning to distinguish signal from noise is one of the most practically useful things early discovery teaches.

What useful feedback looks like

Specific, problem-focused, and either confirms or challenges your core assumption. “We spend about three days a month cleaning this data before we can use it” is useful. “We’d definitely be interested in something like this” is not — it tells you nothing about whether they’d buy, use, or advocate for it internally.

What misleading feedback looks like

It often comes from people who are intellectually engaged, curious, or genuinely warm — but who are not your early-stage customer. They’ll ask smart questions, suggest features, express interest. And then you never hear from them again. This happened to us more than once at Data Solver, especially with contacts from investor networks who were interested in the problem space but weren’t facing it directly themselves.

The test that matters

Is this person willing to put anything on the line? Not money — you’re too early for that. But time, a name, a written signal of interest. If yes, the feedback matters. If no, treat it as directionally interesting but not as validation.

The lesson we eventually took from the conversations that went nowhere wasn’t about how to present better. It was about reading the room earlier. Some of the feedback we got — particularly from larger organisations asking to see a finished product — wasn’t rejection. It was a signal that we were in the wrong conversation for our stage. Those organisations weren’t our early-stage customers. They might be future customers. But the energy we spent pursuing them would have been better spent on people who were set up to work with us as we actually were.

The right question after a conversation that doesn’t land is not “what should we have done differently?” It’s “was this person ever the right fit for us at this stage?” More often than not, the answer is no — and recognising that quickly is what good startup marketing timing is actually about.