The standard advice is to talk to 20 customers before you write a line of code. Get out of the building. Run problem interviews. Build a landing page and see if anyone signs up. Every startup curriculum, every accelerator cohort, every "how I built this" episode is built around some version of this framework.
It's correct. For the founders it was written for.
That founder is entering a market from the outside — a software engineer who noticed an inefficiency in an adjacent industry, or an MBA who spotted a pattern they've read about but never worked in. For that person, 20 customer conversations is the fastest way to find out if they're seeing something real or seeing what they want to see.
That's not the situation of an operator. If you've spent 12 years managing supply chain for mid-market distributors, you don't need 20 interviews to establish whether the problem is real. You've watched it cost real money, real time, and real customer relationships across an entire career. You've patched it, worked around it, and complained about it in every operations review you've ever attended.
The problem is real. The validation question you actually need to answer is different.
What operators actually need to figure out
The relevant questions for an operator who wants to validate a startup idea aren't about whether the problem exists. They're more specific.
Is this the exact version of the problem worth building against? In any complex vertical, there are multiple flavors of the same underlying dysfunction. The scheduling problem, the billing problem, and the compliance tracking problem are all symptoms of the same broken workflow, but they have different economics, different buyers, and different competitive landscapes. Which specific slice has the right combination of pain intensity, purchase frequency, and willingness to pay? That's the question worth answering early.
Who makes the actual buying decision, and is that person reachable through your network? Domain expertise and customer relationships are only a distribution asset if the people you know are the right people. In some verticals, the person who feels the pain every day is not the person who controls the budget. Understanding the actual purchase path — who champions, who approves, who can veto — before you build saves 12 months of sales motion misalignment.
Will this market pay for a software fix, or does the current broken solution persist for non-economic reasons? Some workflows stay broken because of regulatory constraints, organizational inertia, or industry dynamics that have nothing to do with whether a better solution exists. Operators are sometimes too close to the problem to see why it persisted. A few direct conversations about what the current solution costs, and why nothing has changed, can surface this before you've committed to building.
Where the standard validation playbook fails operators
The customer discovery framework was designed to prevent a specific failure mode: building a product for a problem nobody has, because the founder fell in love with a solution rather than a customer. That failure mode almost never happens to operators. Their failure modes are different.
Operators build the right product for the wrong buyer. They solve the problem for the operations manager who lives with it every day, then discover that the CFO makes the purchasing decision and doesn't see the problem in the same terms. The product is real, the pain is real, and the sale still doesn't close because nobody talked to the person with the budget.
Operators build version two before version one has any customers. They know the full solution so completely that they can't resist building the features that require the customer to have already adopted the core workflow. The product ships at version 1.8 but the market needed 1.0 first. Customers who would have paid for the basic version don't buy the comprehensive one.
Operators price based on what they would have wanted to pay as a cost-conscious operator, not based on what the market will actually bear. Former operations managers often underprice dramatically because their reference point is the frugal buyer they used to be. The resulting unit economics don't support the business they're trying to build.
The standard discovery sprint doesn't address any of these failure modes. Running 20 problem interviews confirms the problem exists — which you already knew. It doesn't tell you who controls the budget, what scope is right for version one, or what the market will pay.
The conversations that actually matter
Call five people you've worked alongside who currently hold the role you're building for. Not to pitch them — to ask three specific questions: What are they spending right now on this problem, in time, workarounds, or actual vendor cost? Who in the organization approves a new software purchase in this category? And what would need to be true about a new solution for them to bring it to that decision-maker?
Those three questions give you the commercial picture: does money exist for this, who controls it, and what triggers a buying process. That's what you're actually validating. The problem itself you already know.
Five conversations with the right specificity give you what 20 generic problem interviews won't: confirmation that real money exists, a map of who controls it, and a clear picture of the purchase trigger.
What to do after five conversations
If those conversations confirm the commercial picture — real spend, identifiable decision-maker, clear purchase trigger — you have enough to move into scoping. You don't need 20 more interviews. You need to define what version 1.0 solves, price it with real numbers, and find out if someone will pay before you've finished building it.
The validation isn't about confirming what you already know. It's about eliminating the assumptions you didn't know you were making.
For operators, the risk isn't building the wrong product. It's building the right product for the wrong buyer, at the wrong price, scoped to the wrong version. Five focused conversations before you build are the difference between finding that out now and finding it out after 18 months of runway.