Customer Discovery: Finding the Real Problem

Illustrative. The engagement below is a composite, written to teach the move. The dialogue is invented rather than transcribed, and contains no statistics. (The real, cited deployments live in the Engagements section; this section teaches the craft through illustrations, tagged like this one.)

Discovery is the first phase of every engagement and the one most engineers skip. You're handed a problem, you can see three ways to build it, and the urge is to start. Resist it. The customer has handed you the problem they can articulate, which is almost never the problem you're actually being paid to solve. Discovery is the work of finding the gap between the two before you write a line of code.

This is the part of the job an AI Engineer doesn't do. Get it right and the build shrinks, because you built the right thing once. Get it wrong and you ship something that works, demos well, and that nobody uses.

Before reading on

A regional logistics company brings you in. The VP of Operations says, "We want an AI assistant that answers our dispatchers' questions about shipping regulations. They waste too much time looking things up."

Write down the first three questions you'd ask. Then keep reading.

Most engineers, handed that sentence, start designing: a retrieval system over the regulations, a chat interface, maybe a fine-tune. Hold off. Everything in that sentence is a proposed solution ("an AI assistant") wrapped around a symptom ("waste too much time"). You don't yet know the problem.

Move 1 — Separate the request from the outcome

The VP asked for a Q&A assistant. That's a request. Underneath every request is an outcome the person is actually accountable for: the thing their boss measures them on. Your first job is to climb from the request to the outcome, because the outcome is what you'll be judged on too.

The climb is one question, asked a few times: "What changes for you if this works?"

You: "Say the assistant is perfect, and dispatchers get instant, correct answers. What's different for you three months later?"

VP: "Fewer compliance holds. When a dispatcher gets a hazmat routing wrong, the shipment gets flagged at a checkpoint and sits. That's the number my boss asks me about."

That answer just moved the project. The request was "answer questions faster." The outcome is fewer compliance holds, and those are not the same system. A faster lookup tool might never reduce holds, because the dispatchers who cause holds aren't the ones stopping to look things up. They're the ones who are sure they already know the answer.

Bad / Good / Great — the opening discovery question

Bad — "What data do you have, and where does it live?" You've started building. It's an engineer's reflex, and it tells the customer you heard "retrieval system" and stopped listening. You'll get a data-source list and a system that answers questions nobody important was asking.

Good — "Can you tell me more about the questions dispatchers are asking?" Better: you're curious about the work. But you're still inside the customer's framing. You'll learn a lot about questions and nothing about whether answering them is what actually moves the number.

Great — "If this works perfectly, what's different for you in three months?" You've gone past the request to the outcome the buyer is measured on. Now every later decision has a yardstick: does this reduce compliance holds? When you later argue for spending build time on the hard hazmat-routing case instead of the easy FAQ, this is the sentence that wins the argument, because the VP told you that's the number that matters.

Move 2 — Follow the work, not the spec

You now have the outcome from the buyer. But the buyer doesn't do the work. The next move is the one engineers find most uncomfortable, and the one that separates a forward-deployed engineer from a vendor: go sit with the people who actually do the job. Not a requirements meeting. The actual desk, the actual shift.

You spend a morning next to two dispatchers. The first, new on the job, does exactly what the VP described: stops, looks things up, slow but careful. She would barely use your tool; she already double-checks everything.

The second has fifteen years in. He's fast, confident, and never looks anything up. He goes from memory. Watching him, you notice he's working from a laminated card taped to his monitor, last updated who-knows-when. Twice that morning he routes a shipment the way he's always done it. You can't tell, sitting there, whether either was a hold waiting to happen. Neither could he.

That's the real problem, and no one would ever have told it to you, because the person causing the holds doesn't know he's the one causing them. The dispatchers who'd use a Q&A tool aren't the ones creating holds. The dispatcher creating holds doesn't ask questions; he's certain. A tool that waits to be asked will be used by exactly the wrong people.

The real problem is that confidence and correctness have come apart, and nothing in the workflow catches it. That reframes the whole system: you don't want a chatbot the dispatcher chooses to consult. You want something that watches the routing decision as it's made and flags the ones that don't smell right, quietly, without making a fifteen-year veteran feel second-guessed. That last constraint is its own design problem you now know to solve for.

The probe to expect

When you bring this reframe back, the buyer often pushes:

VP: "I asked for a Q&A assistant. Now you're telling me you want to build something that monitors my dispatchers? That's a harder sell internally."

Don't retreat to the easy build. Hold the outcome up, because it's the one they gave you:

You: "You told me the number that matters is compliance holds. A Q&A tool only helps the dispatchers who already stop to check, and from a morning on the floor, those aren't the ones causing holds. If we build the assistant you asked for, it'll demo well and it won't move your number. I'd rather build the thing that moves the number. Here's how we keep it from feeling like surveillance..."

That's the forward-deployed move: you used their stated outcome to argue against their stated request, and you came with the next problem already half-solved. That isn't obstruction. It's refusing to let them pay for something that won't work.

What "done with discovery" looks like

You can leave discovery when you can say, in plain language a non-engineer would nod at:

• The outcome the buyer is measured on. (Compliance holds, not "answer speed.")
• Who actually has the pain, confirmed by watching them, and whether it's the same people the buyer named. (It wasn't.)
• The real problem, which is usually a reframe of the request. (Confidence ≠ correctness, with nothing to catch the gap.)
• One sentence on why the obvious build is the wrong build. If you can't say this, you haven't done discovery; you've taken an order.

The transferable pattern

Climb from the request to the outcome, then go watch the work until the real problem contradicts the request. Every engagement has this shape: someone hands you a solution dressed as a problem, the people who bought it aren't the people who feel the pain, and the truth is on the floor, not in the meeting. The deliverable of discovery isn't a requirements doc. It's a reframe you can defend with one sentence about the outcome: the outcome they gave you themselves.

Next: Scoping & Solution Architecture. Turn the reframe into a system you can actually commit to building, and say no to the three things that aren't it.