The canonical advice for early-stage founders is "talk to customers." Do 50 interviews. Use a specific framework — Jobs to Be Done, or whatever your accelerator recommends. Don't build anything until you've validated the problem with enough potential buyers.
This advice exists because most founders don't know their market. They're trying to understand a world they've read about rather than lived in, so they interview their way toward credibility.
If you've spent a decade operating in the vertical you're now building for, you've already done the interviews. They were called your job.
What B2B SaaS Customer Discovery Is Actually For
Customer discovery isn't about finding a problem. Any market with real software spend already has identifiable problems — the question is which ones are addressable, urgent enough to pay for, and large enough to build a company around.
For operator founders, that filtering has happened over years of running operations. You know which problems destroyed your margins. You know which ones your team complained about daily. You know which ones you patched with spreadsheets for two years because the software that claimed to solve them didn't.
The real purpose of B2B SaaS customer discovery for operators isn't to find the problem — it's to escape the echo chamber of your own experience. Your problem is real. The question is whether it's also your customers' problem in the form you're framing it, or whether there's a different cut of the same issue that's more actionable to build for.
The Three Questions That Matter
Customer discovery for an operator founder should be narrow, fast, and structured around three questions.
Do other operators in this vertical have the same problem, or is this specific to how your operation was run? The goal is signal. If you talk to 10 operators and 8 describe the same friction in the same terms, you have a problem worth building for. If 4 describe it vaguely and 2 describe something adjacent, you need more specificity before writing code.
What's the current workaround, and what does it cost? Every real problem has a workaround — a spreadsheet, a manual process, a staff member whose entire job is compensating for the broken system. That workaround is your competition. Understanding it tells you what you're replacing and at what cost, which tells you how to price.
Who owns this problem in the organization? In B2B SaaS, the person who experiences the pain and the person who signs the contract are rarely the same. Operators already know this intuitively — you've been on both sides. But mapping it explicitly for each prospect tells you where to focus your sales motion.
How to Run the Calls
The mechanics matter less than the posture.
Don't run B2B SaaS customer discovery calls like investor pitches with the questions reversed. You're not validating — you're learning. The worst interview pattern is explaining your solution, asking if they'd use it, and interpreting enthusiasm as validation. Enthusiasm in a 30-minute call is free. Money is validation.
Open with a specific moment in the workflow you're interested in: "Tell me about the last time you had to [X process] and it didn't go well." Let the story run. The detail in the story is where the real information lives — not the headline answer, but the sequence of things that went wrong, who was involved, and what they tried before giving up.
You know that "our current system works fine" often means "we've stopped trying to fix it." That reading ability is worth more than any customer development framework.
What to Do With What You Hear
Categorize the problems by severity, not by frequency.
Common but low-stakes problems attract feature requests, not software sales. A daily annoyance that doesn't cost money or erode trust rarely justifies a purchase decision. High-severity, low-frequency problems are where SaaS companies live — the thing that happens every quarter and destroys a week of work when it does.
Look for the problem that makes someone say "yeah, we just accept that" with a kind of flat exhaustion. That's the real opportunity. Not the feature request, not the enthusiastic "I'd love that!" — the resigned acknowledgment that something is broken and has been for years.
And note whose language your customers use when they describe the problem. That language belongs in your pitch, your onboarding, and your marketing. Buyers who hear their own words reflected back immediately know they're talking to someone who understands the work.
The Shortcut That Isn't a Shortcut
Some operator founders skip customer discovery because they're confident they already know the problem. That confidence is usually warranted. But there's a specific kind of mistake it produces.
Your experience was at your company, in your region, with your team, under the constraints of your particular operation. Vertical software markets are fragmented enough that the workflow in one geography or business size can be materially different from another. The problem you know is real. The scope of it, and the exact form it takes across your market, requires more data than one career's worth.
Twenty calls. Not to validate — you don't need the confidence boost. To hear the specific language, the specific moments, and the specific workarounds that will make your product description, your sales pitch, and your onboarding feel like they were written by someone who lived it.
Because you did live it. The calls are how you translate that into something other people can see.
If you're an operator who's done enough customer discovery to know what you're building, we'd like to hear two paragraphs about it. We'll be back in 48 hours.