The Discovery Call: How Forward Deployed Engineers Find the Real Problem

A discovery call is the first structured conversation with a client, and its goal is not to propose a solution — it is to locate the real problem: who owns it, what it costs, and what has to be true for a fix to survive in production. For a forward deployed engineer, the discovery call is the highest-leverage hour of an engagement. Most AI projects don't die in the model. They die here, in the first conversation, before anyone has written a line of code.

The numbers back this up. RAND's research puts the failure rate of AI projects at over 80%, and Gartner reports that roughly half of generative AI projects are abandoned after proof of concept. The stated causes vary — data quality, cost, unclear business value — but upstream of most of them sits the same root failure: poor requirements capture. And requirements don't fail in the requirements meeting. They fail earlier, in the discovery call, when nobody asked the questions that would have surfaced the truth.

#Why AI pilots die in the discovery call

Real life is not a case study. Nobody hands you a dossier listing each stakeholder's motivations and agenda. You get 45 minutes with people you've never met, partial information delivered in someone else's vocabulary, and the quiet pressure to sound like you already have the answer. Every real discovery call looks like this.

A mentor of mine, who spent years in consulting before moving into AI deployment, tells a story from a steel manufacturing engagement. Coal arrived at the plant through a sea jetty on barges — a classic optimization problem: schedule barges against tides, maintenance windows, and inventory levels. His team interviewed the unit head and the procurement head, then built a genuinely impressive model linking tide timings, requirements, stock volumes, and barge availability.

During deployment they discovered the real problem. The team already had a digital scheduling tool — it required real-time tracking, and the walkie-talkies on the dock had stopped working. Nobody had budget to replace them. The operation was running blind, and that was causing the delays. Weeks of analytical work, when the answer was a ₹40,000 communication fix.

The model wasn't wrong; the problem was. That is what poor requirements capture actually looks like — not a sloppy spec, but a brilliant solution to the wrong problem. Two disciplines prevent it: asking questions in an order that earns honest answers, and covering the territory systematically so nothing stays hidden. The rest of this article is those two disciplines.

#SPIN questions: earning the truth in the right order

SPIN comes from sales — Neil Rackham's research on how effective sellers ask questions — but it maps almost perfectly onto engineering discovery, because it sequences questions by how much trust they require. Four rungs:

• Situation — safe, structural, factual questions. "How does an order flow through your system today? Which tools touch it?" No trust required; anyone will answer these.
• Problem — friction, pain points, breakdowns. "Where does the handover fail?" This takes some trust: answering honestly means admitting something is broken.
• Implication — what the problem actually costs: financial cost, risk exposure, career consequences. This takes real trust. You are asking someone to quantify their own pain, and sometimes their own exposure.
• Need-Payoff — the client states the value of solving it, in their own words. When they articulate the payoff themselves, trust has been earned — you are no longer defending your intentions.

The order is the point. Open with an implication question — "what is this costing you?" — in minute five and it reads as an interrogation; people close down and you get the sanitized version of reality. Clients guard information for predictable reasons — the fear of losing control, the fear of looking incompetent — which I've written about in client psychology for forward deployed engineers. SPIN works because each rung buys exactly the trust the next rung needs.

#People, Process, System: what the discovery call must cover

SPIN is how you ask. It doesn't tell you what to cover. For that I use a three-lane checklist, and the rule that comes with it is blunt: traverse all three lanes in every discovery conversation. Miss one, and it will surface in production.

• People. Who does this work daily? Who manages it and owns the P&L? Who is afraid of it — the blocker? Whose job changes if AI arrives? Who holds the undocumented knowledge?
• Process. What is the trigger → task → decision → handoff chain? Where does data move and transform? Where are the invisible workarounds? Where do handovers break down? What still requires human judgment today?
• System. What is the actual legacy stack? Where are the hard data constraints? What is off-limits or inaccessible? What is the failure mode at scale, and what accuracy threshold is tolerable?

The same mentor shared a problem he faced directly: a company importing coal and other bulk cargo, with ships burning demurrage while waiting at the jetty and stockouts rippling downstream. Tracking looked like the obvious fix — until the RFID tags kept ending up in the ocean, and procurement made clear they would not buy new ones. On paper, the system lane said tracking was feasible. The people lane — who is afraid of this, whose job does it change, who controls the budget — was where it actually failed. Exactly as the rule predicts: the lane you skip is the one that surfaces in production.

#The Problem Definition Sheet: what you carry out

Discovery has a deliverable. Not notes, not vibes — a filled-in problem definition. Every field on it is the direct result of SPIN questioning across People, Process, and System:

• Problem statement — quantified in the client's own numbers: volumes, hours lost, the metric that is bleeding.
• Decision makers — who needs to decide or act, and who holds veto power. Your Situation questions answer this.
• Key forces acting on them — fears, budget pressure, conflicting agendas. This falls out of Problem and Implication questions.
• Boundaries and constraints — what is off-limits: data that cannot leave, processes that cannot be automated yet.
• Success criteria — how the decision maker will judge success, stated by them, not inferred by you. This is what Need-Payoff questions produce.
• Timeframe — the real urgency, derived from the implication pain, with hard external deadlines named.
• Accuracy necessary — the threshold below which the system makes things worse. An 80%-accurate system can generate enough secondary escalations to be worse than no system at all.

If a field is blank, you didn't fail at paperwork — you skipped a SPIN rung or a checklist lane. Go back and ask.

#Discovery ends where scoping begins

The Problem Definition Sheet is the handoff point. Once you're carrying it, the next discipline is scoping — ranking which version of the problem is worth solving, quantifying volume and AI risk, and drawing the agent's boundaries — which I've covered in how to scope an AI agent before you build it. And when the problem statement turns out to be a symptom whose cause nobody can name, the tool changes from conversation to data — that's root cause analysis. But neither of those can rescue an engagement that skipped discovery. The discovery call is not the formality before the real work. It is the real work — the hour that decides whether everything built afterwards is aimed at the right problem.