There's a specific way operator founders get customer discovery wrong that almost never happens to first-time founders. First-timers are appropriately nervous about whether the problem is real. Operators have the opposite problem: they're so certain the problem is real that they skip past the questions that would actually make the product better.
The confidence is earned. That's what makes it a trap. You've spent 10 or 15 years inside the workflow — you've seen the broken parts close enough to smell them. But operator founder customer discovery is a different discipline than knowing your industry, and conflating the two costs months.
You've already done the research — but it was the wrong research
Your career is a decade of pattern recognition about what's broken. That's not nothing — it's the reason you spotted the problem at all. But your career research tells you what is broken. Product customer discovery tells you what broken costs, who owns the decision to fix it, and what alternatives buyers have already tried and rejected.
Most operators don't know these things with precision. They know the workflow. They don't know the buying committee.
Consider: an operator who spent 12 years as a commercial HVAC technician knew exactly what dispatch software got wrong — the job sequencing was manual, the communication between office and field was broken, the invoicing lagged by days. He knew all of this. What he didn't know when he started building: his target customers — owner-operators with 5–10 trucks — had already tried three different dispatch tools in the past two years and abandoned all three. The problem wasn't that the software was bad. It was that buyers had been burned enough times to be deeply skeptical of any new solution, including a better one.
That context changes the entire go-to-market. You're not selling software — you're selling a reason to trust again. You can't figure that out from your own scar tissue. You have to ask.
What to discover when you think you already know
These aren't generic discovery questions. They're calibrated for buyers who have probably already heard a pitch like yours and didn't buy.
What have you already tried? Not "is this a problem" — you both know it's a problem. The question is what they've done about it and why it failed. The answers reveal the actual barrier: implementation, pricing, adoption, trust, internal politics. You need to know which one you're solving for.
Who in your company actually makes this decision? Operators often assume they know the answer from their own experience running or working in companies like this. They're wrong more than they expect. The person who lived the problem is rarely the person who authorizes the budget to fix it. Map the real buying committee before you design your sales motion.
What would you stop using tomorrow if I gave you something better? What you're replacing matters as much as what you're building. Switching costs, contract lock-ins, and organizational inertia around existing tools are often bigger blockers than product quality. You need to know what you're actually competing against — which is frequently a spreadsheet, not software.
What would make this not worth switching for? This is the adoption risk question, not the buying risk question. Even if they say yes in the demo, something will stop them from actually deploying it. Find out what that is before you build the product around a feature set that doesn't address the real friction.
The discovery trap: confirming instead of stress-testing
Operator founders do customer interviews. They often do a lot of them. The issue isn't the quantity — it's the structure. When you're certain the problem is real, every interview becomes a validation exercise rather than a learning exercise.
You hear "yes, that's a real problem" in interview after interview, and you call that product-market fit research. What you've actually done is confirm what you already believed. The harder questions — the ones that would surface the actual risks — didn't get asked because you weren't looking for them.
The antidote is deliberate disconfirmation. Build explicit questions into every interview designed to surface the ways your product won't work: "Tell me the version of this where you buy it and don't use it." "What would have to be true for you to not pay for this even if you liked it?" "Who in your position has tried to fix this problem and failed — and what did they learn?"
One founder ran 20 interviews, heard "yes" 18 times, and launched into a market where 12 of those 18 people were field technicians — not the owner-operators who actually controlled the purchasing budget. The confirmation was real. The sample was wrong. Three months of build time later, they were rebuilding the pitch from scratch for a buyer they hadn't talked to yet.
When to stop discovering and start building
Customer discovery without a clear stopping condition becomes a form of procrastination. Three signals that tell you it's time to build:
You can name three specific people who have said "I'd pay $X per month for this" — not "I'd use it," not "that sounds interesting." The price anchor matters. Willingness to pay and willingness to try are not the same thing, and operators who haven't separated them are almost always surprised when pilots don't convert.
You understand why the last product in this space didn't get traction. If you can't articulate the failure mode of the competitor or previous solution in the market, you haven't done enough research. The failure history is the most important context you can have before you start building.
You have at least one design partner willing to be in the room when you build — someone who will give you feedback on a workflow before it's a polished demo, who has skin in the outcome because they've already committed to being an early customer. If you don't have this person yet, you're not ready to build.
These aren't academic milestones. They're the minimum to proceed without wasting your first six months on a wrong assumption about what the market actually needs. Combined with a real read on product-market fit, they're what separates operator founders who build fast from the ones who build twice.
The operators who move fastest through Alder aren't the ones with the most research. They're the ones who know what they don't know — and asked the right questions before writing the first line of code. If that's where you are, tell us about the workflow you want to fix.