The problem you describe is not the problem you have
Q1 2026Every engagement starts with a stated problem. "We need more pipeline." "We need to automate onboarding." "Our team can't keep up." The stated problem is real in the sense that someone senior believes it, budget has been attached to it, and a meeting has been called about it. It is almost never the problem.
I learned this the slow way, across fourteen years of enterprise discovery calls. A travel platform once asked for capacity: more hands to work an onboarding queue that never emptied. Three hours of manual work per property, four to six months to ramp a new hire. The stated problem was throughput. The actual problem was that the entire process lived in people's heads. Every onboarding was an act of translation from tribal knowledge to keystrokes, which is why it was slow, why it produced errors, and why new hires took half a year to matter. Hiring against that problem would have made it worse. More people, more translation, more variance.
The gap between stated and actual problems is not a failure of honesty. It is a failure of vantage point. The person describing the problem is describing what it looks like from their seat, and their seat is inside the system that produced it. A VP of Sales sees deals dying in stage three and says "we have a closing problem." Sit in the pipeline reviews for two weeks and you find the deals were dead at qualification; stage three is just where the death certificate gets signed. The closing problem is a qualification problem wearing a costume.
There are reliable tells. When the same decision gets made three different ways depending on who is in the room, the problem is upstream of whatever anyone is describing. When a fix has been attempted twice and failed twice, the fix was aimed at a symptom. When the description of the problem includes a solution ("we need a new CRM"), someone has already skipped diagnosis, and the interesting question is what they skipped past.
The discipline that works is boring and slightly invasive. Read the deals that died, in the original, not the summary. Sit in the reviews and say nothing for the first three. Follow one unit of work, a deal, an onboarding, a ticket, through every handoff, and write down where it waits. Ask the people two levels down what they actually do when the documented process fails them, because it fails them daily and their workarounds are the truest map of the system you will find.
I hold a rule from my finance years, when the job was drafting prospectuses: you cannot describe a company to investors until you can explain how it makes money and where that could break, in writing, under liability. Discovery deserves the same standard. If I cannot write the problem statement in a way the client reads and says "that's uncomfortable and correct," I have not finished diagnosing, and anything I prescribe is a guess with an invoice attached.
The stated problem still matters. It tells you where it hurts, and pain is data. But treating the stated problem is how companies end up with a new CRM configured to automate a broken process, a hiring plan that scales a leak, or an AI tool bolted onto a workflow nobody can define. The most expensive sentence in business is "so we bought something for that."
Start with the assumption that the description is a symptom. Respect it, examine it, and then go find the disease. The clients who get the most from me are the ones willing to hear that the problem they budgeted for is not the one we are about to solve.