Customer Discovery: A No-BS Guide for Founders

What Customer Discovery Actually Is (And Why Most Founders Skip It)

Most founders have an idea, get excited, and start building. Three months and $20,000 later, they launch and hear crickets. No one buys. Not because the product was bad, but because nobody needed it badly enough to pay for it.

That's the problem customer discovery solves. It's a structured process of getting out of your own head and talking to real people before you commit serious time and money to any direction. Not friends. Not family. Not your co-founder who agrees with everything you say. Actual potential customers, with actual problems, who either will or won't pay to fix them.

I've been through this process across five SaaS exits. The businesses that worked weren't the ones with the best features - they were the ones where I understood the customer's pain better than they could articulate it themselves. That understanding comes from conversations, not assumptions.

Customer discovery isn't a phase you finish. It's a practice you keep running. But the early-stage version of it - the pre-build, pre-launch discovery - is the most important. Get that wrong and everything downstream is harder. Get it right and your messaging writes itself, your sales conversations get easier, and your product decisions become obvious.

The data backs this up in a sobering way. Research consistently shows that somewhere between 35% and 42% of startups fail specifically because there was no real market need for what they built. That's not a funding problem. That's not a technical problem. That's a founder-spent-zero-time-validating-before-building problem, and it's entirely preventable.

The Origin of Customer Discovery (Why This Framework Exists)

The phrase didn't come out of thin air. Customer discovery traces its roots to Steve Blank, a serial entrepreneur who spent decades watching startups fail in Silicon Valley and started noticing a consistent pattern. His observation was simple but damning: most startups lack a process for discovering their markets, locating their first customers, validating their assumptions, and growing their business.

Blank formalized this into what he called the Customer Development model, laid out in his book The Four Steps to the Epiphany. The core insight was that a startup is fundamentally different from a big company - it's a temporary organization searching for a repeatable and scalable business model, not executing a known one. That search requires a completely different approach than traditional product development.

Eric Ries, one of Blank's students, built on this foundation to create the Lean Startup methodology. The customer discovery phase sits at the front of that model: before you build anything significant, you form hypotheses, get out of the building, and test them against reality. The hypotheses testing emulates the scientific method - pose a business model hypothesis, design an experiment, get out of the building and test it, then either validate, invalidate, or modify what you thought you knew.

What made this framework stick is that it directly addresses the most expensive mistake founders make: building first and validating second. Blank's mantra - there are no facts inside your building, so get outside - is simple enough to tattoo on the back of your hand. Most founders still ignore it.

The One Mistake That Kills Most Discovery Efforts

Confirmation bias. You pitch your idea, the person nods politely and says "wow, that sounds really interesting," and you walk away thinking you've validated something. You haven't. You've just heard someone being polite.

The fix is simple but counterintuitive: don't tell people your idea during a discovery interview. Not at the start, and ideally not at all until you've finished asking questions. The moment you reveal your solution, you've biased the conversation. People will start fitting their answers to your concept instead of describing their actual reality.

What you want are unprompted descriptions of pain. You want to hear someone say "I lose about four hours every week manually compiling this report and it drives me insane" - without you having said a word about your report-automation idea. That's signal. A polite "yeah that sounds useful" after you've pitched them? That's noise.

The other version of this mistake is asking hypothetical questions. "Would you use a tool that did X?" is a worthless question. People are notoriously bad at predicting their own future behavior. What they tell you they'd do and what they actually do are two completely different things. Anchor every question to past behavior, specific events, real experiences - not imagined futures.

Customer Discovery vs. Customer Validation: Know Which Game You're Playing

These two phases get conflated constantly, and confusing them leads to wasted effort. They serve different purposes at different stages.

Customer discovery is about understanding the problem. You're exploring whether a real, painful, widespread problem exists - and whether the people who have it would actually spend money to fix it. The output of customer discovery is a set of findings and validated (or invalidated) assumptions. You're in learning mode, not selling mode.

Customer validation is what comes next. Once you've established that a real problem exists and you have a hypothesis about how to solve it, validation is where you test whether your proposed solution actually works - and whether you can build a repeatable, scalable process around selling it. You're moving from "is this a real problem?" to "can we build a business around our answer to it?"

If validation fails - if the product doesn't resonate, if the sales process doesn't repeat, if customers churn quickly - you return to discovery. You haven't failed; you've learned something expensive but valuable. The cycle between discovery and validation is normal. Many successful companies run through it multiple times before finding their footing.

The practical implication: don't start pitching a solution until you've genuinely finished learning about the problem. I've watched founders skip straight to validation because they were impatient to build. They paid for that impatience with months of development on the wrong thing.

Building Your Personas Before the First Interview

Before you book a single call, you need to get clear on who you're actually trying to talk to. This is where personas come in - and I don't mean the fluffy marketing personas with fake names and stock photos. I mean a working hypothesis about the specific type of person who has the problem you're investigating.

A useful discovery persona answers a few specific questions: What is this person's role? What are they responsible for? What does success look like in their job? What metrics are they measured against? Who do they report to, and who reports to them? What tools and processes do they rely on today to handle the problem area you care about?

For B2B products especially, you need to build two distinct profiles: the user and the buyer. The user is the person who will actually interact with your product daily. The buyer is the person who controls the budget and makes the purchase decision. These are often different people, and they care about completely different things. A VP of Sales cares about pipeline and quota attainment. The SDR who will actually use your sequencing tool cares about whether it saves them time and doesn't break. Both opinions matter, but they matter at different points in your process - and failing to distinguish between them is a common reason discovery interviews produce misleading results.

For most B2B SaaS products, run at least three to five personas through your discovery process: the end user, the department head who will sponsor the buy, and the economic decision-maker who will approve the spend. Each will have different pain intensities, different vocabulary for describing the problem, and different criteria for what a "good solution" looks like.

An effective practice from the HBS Rock Center is to create a one-page bio for each persona - not a bullet-point slide, but a narrative description that feels like a real person you could imagine sitting across from you. When a persona feels real, you interview better because you're listening for whether this specific person's reality matches your hypothesis, not just collecting generic responses.

How to Structure a Customer Discovery Interview

Keep it to 25-30 minutes. Anything longer and you're asking for a favor most people won't grant. Frame it as a "quick conversation" rather than a formal interview. You want them relaxed and candid, not prepared and performative.

Here's the structure that works:

• Two minutes: Context setting. Tell them why you're talking - you're researching a problem space, not pitching a product. Make it clear you're trying to learn, not sell.
• Three minutes: Qualification. Understand their role, their responsibilities, and how they relate to the problem area you're investigating. If they're not the right profile, you'll know quickly.
• Twenty minutes: Open-ended questions. This is the core. Ask about their current processes, the frustrations they hit, what workarounds they've built, and how much pain they'd assign to each problem. Shut up and listen.
• Five minutes: Close. Ask if they know anyone else you should talk to. A warm referral from inside their network is worth more than a cold outreach to 50 strangers.

The best questions anchor to past behavior, not future hypotheticals. "Tell me about the last time you dealt with X problem" yields far more useful data than "would you want a tool that does Y?" Past behavior predicts purchase decisions. Future hypotheticals just produce polite speculation.

Record every call with permission. Don't try to take comprehensive notes while also actively listening - you'll do both badly. Review the recording afterward and pull the exact phrases people used. Those phrases are pure gold for copywriting and positioning later.

The Questions That Actually Get You Answers

Here's a working list. You won't use all of them in one session - pick five to seven and let the conversation breathe.

• "Walk me through how you handle [problem area] today, step by step."
• "What part of that process frustrates you the most?"
• "Tell me about the last time that frustration cost you something real - time, money, a deal."
• "What have you already tried to fix it?"
• "Why didn't that solution stick?"
• "If you could change one thing about how this works, what would it be?"
• "Who else on your team deals with this problem?"
• "Is there budget currently allocated to solving this?"
• "Who makes the call on buying tools for this problem?"
• "How are products like this usually purchased in your organization? Walk me through the approval cycle."
• "What would have to be true for you to say yes to a solution like this tomorrow?"

That last cluster - budget, authority, urgency - tells you whether you're talking to a real buyer or just someone with opinions. Both are useful, but you need to know the difference.

Notice there's nothing in that list about your idea. No "what do you think of an app that..." questions. You're a detective in these conversations, not a salesperson. The moment you start selling, you stop learning.

Who to Talk To and How to Find Them

This is where most founders stall. They know they need to do interviews but don't know how to get people on the phone. Here's what actually works:

LinkedIn manual outreach. Search your target title and industry. Send a short, direct message that leads with the problem, not your product. Something like: "Hey [name], I'm doing research on how [role] handles [problem]. No pitch - genuinely trying to understand the space. Would you have 20 minutes this week?" Response rates for this are low, but the quality of conversations is high.

Cold email. Same principle, different channel. Keep it under five sentences. Ask about their experience with the problem, not whether they want to buy anything. If you're building a B2B product and need to get in front of decision-makers fast, you first need a solid prospect list. I use this B2B lead database to filter by title, industry, company size, and location - it saves hours compared to building lists manually and gives you a clean starting point for outreach. When you need to track down someone's direct email after you've identified them on LinkedIn, ScraperCity's Email Finder can return a verified address from just a name and company - useful when LinkedIn messages go unread.

Communities and forums. Wherever your target customer spends time online - Slack groups, Reddit, LinkedIn groups, industry-specific forums - those are goldmines for recruiting discovery conversations. Drop a post explaining you're researching a pain point and offer to share findings. People respond to researchers more readily than to salespeople.

Your existing network. Don't overthink it. Message people you know who fit the profile. Ask for introductions. The first ten conversations are almost always within two degrees of separation.

Event and conference attendee lists. Industry conferences often publish speaker lists and attendee profiles. That's a pre-qualified list of people who care enough about your space to show up in person. Those people are almost always willing to talk shop.

Steve Blank's original recommendation was to start with a list of 50 names - tapping your network first (former colleagues, investors, lawyers, accountants), then expanding outward. The point isn't perfection at the start; it's getting enough conversations going that patterns can emerge.

Aim for at least 15-20 conversations before drawing conclusions. Patterns don't emerge reliably at five interviews. At 20, you start hearing the same phrases, the same workarounds, the same bottlenecks - and that repetition is your signal.

Getting the Meetings Booked: Outreach Mechanics

The interview itself is only half the battle. Getting someone to agree to it is the other half. A few things that consistently improve booking rates:

• Be specific about the time ask. "20 minutes" books more meetings than "a quick call."
• Lead with curiosity, not ask. Open with something that demonstrates you've done homework on their world.
• Offer a small incentive if needed. A $25-50 gift card is a reasonable offer when reaching out to senior decision-makers cold. It signals you value their time.
• Follow up once. One follow-up is fine. Two is pushing it. Three makes you memorable for the wrong reasons.

For the email side of this, tools like Smartlead or Instantly can help you run structured outreach sequences so you're not managing follow-ups manually across 50 prospects in a spreadsheet. You're not cold selling here - but the mechanics of sequenced outreach apply equally well to booking discovery conversations as they do to booking sales calls.

If you need to go beyond email and reach people by phone, a mobile number finder can surface direct dials for your target contacts - especially useful for senior buyers who rarely respond to unsolicited email but will pick up a direct line. For the actual outreach and follow-up calls, a tool like CloudTalk keeps your call logs organized and lets you set automatic callback reminders so no conversation falls through the cracks.

What You're Actually Listening For

Not every problem you hear about is worth building around. The ones that matter share a few characteristics:

• Frequency: They deal with it regularly, not once a year.
• Pain intensity: When they describe it, you can hear the frustration. They volunteer stories without you having to drag them out.
• Active workarounds: They've already cobbled together some DIY solution - spreadsheets, manual processes, duct-taped tools - which proves the problem is real enough to spend time on.
• Budget exists: Someone on the team already pays for something to partially solve this, even if it's a clunky alternative.

If you're hearing all four of those things consistently across multiple conversations, you're in a real problem space. If you're hearing polite interest but no active workarounds and no existing spend, the problem might be a vitamin, not a painkiller. Vitamins are nice to have. Painkillers get bought.

There's also a useful signal that comes from what people have tried and abandoned. If they bought a tool, used it for three months, and stopped - dig into why. What was wrong with it? What did it fail to do? That gap is often exactly where a new entrant can win. The fact that they tried at all proves the problem was real enough to invest in. The fact that they stopped proves existing solutions aren't good enough.

How to Synthesize What You've Heard

Raw interview notes are not insights. You need a system for turning conversations into actionable conclusions.

After each interview, spend 15 minutes writing a one-paragraph summary covering: the specific pain points surfaced, the exact language the person used to describe them, the workarounds they currently rely on, the budget situation, and who else on their team has influence over this problem. Do this immediately after the call while it's fresh. Don't rely on transcripts alone - your real-time observations about tone, emphasis, and what they hesitated on are just as valuable as the words.

After 10+ interviews, lay all your summaries side by side. Start tagging repeated phrases. You're looking for convergence - the same words appearing across multiple unrelated conversations. When three or four people who don't know each other describe the same frustration using almost identical language, that language becomes your positioning copy. It's not language you had to invent; it's language the market handed you.

Also track divergence. Where did people disagree? Where did one persona describe a problem differently from another? That divergence often reveals segmentation opportunities - the same core product with different messaging for different buyer types, or genuinely different product features needed for different use cases. Don't average it out; pay attention to the outliers.

A simple way to structure this: build a spreadsheet with one row per interview and columns for each hypothesis you're testing. After every call, score each hypothesis: confirmed, partially confirmed, or disproved. By interview 15-20, you'll see clear patterns in the scores - and some hypotheses you were confident about at the start will look very different in the light of actual market data.

The Pivot Decision: When Discovery Tells You to Change Direction

Most founders treat a failed hypothesis as a personal failure. It's not. It's the system working as designed. The entire point of customer discovery is to find out, cheaply and quickly, which of your assumptions are wrong - before you've built a year of development around them.

A pivot is a change in strategy based on what you've learned. It's not giving up; it's updating. You might pivot the target customer (the problem is real, but you had the wrong persona), the problem framing (you were solving the symptom, not the root cause), the distribution channel (the buyer and user are different people than you thought), or the pricing model (the problem is real but not painful enough to support the price you need).

The signal to pivot is consistent and clear: when multiple interviewees aren't exhibiting any active workarounds, when no one has ever paid for anything in this category, or when the enthusiasm in the room disappears the moment you mention price. Any one of those is a warning sign. All three together is a hard stop.

The signal to persevere is equally clear: when people describe the problem unprompted in the same language, when they show you their janky workaround solutions with visible embarrassment, and when they ask you "when can I start using this?" before you've even finished describing your concept. That's the green light.

If you're still generating and pressure-testing multiple concepts before going deep on any single one, the Business Idea Roaster is useful for stress-testing assumptions before you commit to a full interview round. And if you're generating ideas faster than you can validate them, the Daily Ideas Newsletter can help you see patterns in what's getting traction across different markets.

Customer Discovery for SaaS Products Specifically

SaaS discovery has a few wrinkles that are worth addressing directly. The product is invisible until it's built, the sales cycle involves multiple stakeholders, and the pricing model (subscription vs. one-time) affects which conversations you need to have and with whom.

For SaaS, the discovery process needs to surface not just the problem but the buying committee. Who identifies the problem? Who researches solutions? Who demos the product? Who approves the spend? Who actually uses it daily? These can be four or five completely different people inside the same company, and if you don't know who each of them is, you'll optimize your product and pitch for the wrong audience.

The buyer and the user are rarely the same person in B2B SaaS. A VP of Operations might approve a workflow tool purchase, but the team leads who use it every day will make or break adoption. If the VP loves your pitch but the actual users find the interface confusing, you've got a churn problem baked in from day one. Discovery conversations need to reach both levels.

For SaaS specifically, you also want to probe the integration question early. What does their existing stack look like? What tools do they already use for adjacent workflows? If your product needs to connect to five other systems to be valuable, that's critical information that affects both your build roadmap and your sales conversation. Find out what they're already running before you assume anything about what "fits" in their environment.

If you're noodling on what problem to anchor your SaaS product around, the SaaS AI Ideas Pack is worth a look as a creative starting point - but note that ideas from a pack still need to go through real customer discovery before you build anything.

Common Discovery Mistakes (Beyond Confirmation Bias)

Confirmation bias gets the most attention, but it's not the only trap. Here are the others I see founders fall into repeatedly:

Talking to too-easy-to-reach people. Your network is not a random sample. The people you can get to a call in 24 hours are usually people who are already predisposed to support you. That introduces selection bias. Force yourself to do cold outreach to strangers who have no social obligation to be nice to you.

Stopping at 5 interviews. Five conversations feel like a lot when you're doing them. They're not. At five, you've heard five opinions. Patterns don't appear reliably until 15-20 conversations with the right profile. There's a reason this is the baseline recommendation - not because it's a magic number, but because it's the minimum before signal starts separating from noise.

Only interviewing users, not buyers. The person who will use your product day-to-day and the person who will sign the check are often different people with different pain points and different success criteria. If you only talk to users, you'll build great features but have no idea how to sell. If you only talk to buyers, you'll have a compelling sales pitch for a product nobody can figure out how to use.

Treating discovery as a one-time event. Discovery is ongoing. Markets change. Customer needs evolve. What was true about your ideal customer six months after launch may be very different from what you learned pre-build. The best founders build a continuous cadence of customer conversations into their rhythm - not just at the beginning, but as a permanent operating habit.

Not asking about budget early enough. Founders feel awkward asking about money. Get over it. Knowing that someone has a painful problem tells you nothing if they have zero budget to solve it. You need to know whether the problem is expensive enough to warrant a paid solution, and whether the organization has an existing budget line or would be creating a new one. Both are useful to know, and neither is something to be squeamish about.

Turning Discovery Into Your Business Model

Once you've done 15-20 interviews, you should have enough raw material to start mapping a real business model. The language your interviewees used - their exact words to describe the problem - becomes your marketing copy. The workarounds they built become the features you prioritize. The budget they're already spending tells you your price anchor.

Specifically, you should be able to answer these questions clearly before you build anything:

• Who exactly has this problem? (Role, industry, company size, org structure)
• How painful is it, and how often does it occur?
• What are they doing today to address it, and why isn't that working?
• What would they need to see to be confident a solution is worth trying?
• Who has the authority to buy, and what does the approval process look like?
• What existing budget would this come from?
• What does "success" look like for them 90 days after implementation?

If you can answer all of those from interview data - not assumptions, not guesses, but things you actually heard from multiple real people - you're ready to move into validation. If you can't, you need more conversations.

The good news: once you have those answers, building the first version of your product gets dramatically easier. You're not guessing what to prioritize. You're translating a clear picture of the customer's world into a product that fits it. That's a fundamentally different - and much less risky - position than building from pure inspiration.

When You've Done Enough Discovery

There's no magic number, but a practical signal is this: when you can finish your interviewee's sentences. When you know what they're going to complain about before they say it. When you could write their job description, explain their workflow, and articulate their frustrations more precisely than most of their colleagues could. That's when you've done enough to move forward.

At that point you're not guessing what to build. You're translating what you've heard into a product or service architecture. That's a fundamentally different - and much less risky - position than building from pure inspiration.

Customer discovery doesn't guarantee success. But skipping it dramatically increases the odds of building something nobody asked for. Given how much time and capital goes into launching anything, a few weeks of conversations upfront is one of the cheapest forms of risk reduction available to any founder.

Startups that conduct rigorous validation - including real problem interviews with representative customers and willingness-to-pay testing - see failure rates from the "no market need" category drop dramatically compared to those that skip it. The math isn't complicated. The conversations are free. The cost of not having them is everything you pour into a product no one buys.

Do the calls. Take the notes. Build what the market is telling you it needs. And if what the market is telling you doesn't match what you expected to hear - treat that as the most valuable thing you've learned, not a reason to stop.

If you want real-time help working through what you're hearing in your discovery calls and turning it into a product and sales strategy, I work through this kind of problem directly inside Galadon Gold with founders who are in the thick of it.