If you've spent a decade in a specific vertical, the standard customer discovery advice is mostly beside the point. "Get out of the building." "Don't fall in love with your solution." "Stay in problem mode." These rules are good for founders who don't know their market. They're the wrong frame for operators who've lived in it.
That doesn't mean you skip customer discovery. It means you run a completely different version of it.
What operators already know (and can skip)
The standard customer discovery script is designed to answer one question: does this problem exist and does anyone care about it? Operator founders already know both answers. You've seen the broken workflow hundreds of times. You know which vendors have tried to solve it and why buyers didn't switch. You know why customers are still using the spreadsheet — and it isn't because the problem isn't real.
What you don't need: 50 conversations confirming that the dispatch scheduling process is a mess. Your former colleagues will tell you the problem is real because it is. That's not useful discovery — it's validation theater that feels productive because people are nodding at you.
What operators actually need from discovery
The discovery that matters for operator founders covers three things: language, workflow specifics, and buying context.
Language. Your customers have specific words for the things they deal with. Not the generic terms — the real terms. If you're building software for residential HVAC contractors, the difference between "service call," "maintenance visit," and "install" matters for how you structure the product and write the sales page. If you're building for commercial real estate property managers, "work order" and "maintenance request" are different objects in their mental model, not synonyms. Customer discovery is how you learn the vocabulary that makes your product feel built from the inside.
Workflow specifics. You know the process at a high level. What you often don't know — unless you were specifically in that role — are the micro-steps: what happens between step 3 and step 4, who touches the record in transit, what gets done in a spreadsheet because the existing system can't handle it. Those micro-steps are where product breakthroughs live. The question to ask isn't "what's broken" but "walk me through the last time you did this — what did you actually do, in what order."
Buying context. Who makes the purchasing decision? Is it the owner or the operations manager? Is there a budget line for software or does it come out of discretionary spending? How long does the typical sales cycle run for other tools they've adopted? These answers tell you how to build the sales motion, not just the product.
The discovery trap operators fall into
Operator founders have one specific discovery failure mode: they talk to people they already agree with.
Your former colleagues, industry network, past customers — they're biased toward you. They trust your judgment, they remember the problem the way you do, and they're not going to say the thing that would fundamentally complicate your thesis. They'll tell you what you need to hear to feel good about moving forward.
Useful discovery conversations happen with people who say "actually, we handled that differently" or "we tried something like this three years ago and here's why it didn't work." Those conversations are harder to get and harder to sit through. They're also the ones that save you from building a product that solves the wrong version of a real problem.
A practical rule: in every 10 discovery conversations, at least 3 should be with people who don't know you, have some skepticism about the category, or are currently managing with a workflow that implies they've concluded the problem isn't worth solving. Those are the conversations that sharpen the thesis.
How many conversations you actually need
The right number of discovery conversations is the number you need before you stop hearing genuinely new things.
For operator founders, that happens somewhere between 25 and 40 conversations — much faster than the 50–100 that generalist founders need. You're filling in specific gaps in what you already know, not building foundational market knowledge from scratch.
At 25 conversations, you should be able to articulate: the specific language customers use for the core problem; the 3–4 steps in the workflow where friction is highest; who makes the buying decision and what their primary criteria are; and what product they're currently using (even if it's a spreadsheet) and what would actually make them switch.
If you're still hearing genuinely new things at conversation 40, expand the scope. You're either talking to a population that's too similar, or the market is more fragmented than you expected.
Turning discovery into your first sales motion
The direct output of useful discovery isn't a PRD or a features list. It's the first sales conversation script.
You now know the specific language customers use. You know the workflow step where they're most frustrated. You know who buys and what they care about. The first version of your sales motion is built from those inputs: open with the specific problem in their language, ask about their current workflow at the friction point, show how your product addresses that specific moment.
This is why customer discovery and early sales are the same motion for operator founders — you're learning and building trust in the same conversations. By the time you have something to build, you have 30 people who've had a version of the pitch and are expecting to hear from you when the product is ready. That's a pipeline, not a discovery journal.
For the build sequence that follows, see the guide to how to build an MVP. If you're a vertical SaaS operator who's done the discovery and wants a build partner, tell us what you're working on.