Customer Discovery

A discovery call is the hour you pay in to protect the next four weeks. It is not a demo. The customer already bought. Your job is to find out whether the thing they bought is the thing they need, and to decide — honestly — whether you should build it.

That framing is the whole lesson. Most FDE time wasted in the first month traces back to a discovery call that was run as a sales call: polite, affirming, and useless.

The gap between the ask and the problem

Buyers name solutions, because solutions are what they have a word for. "Add an AI chatbot," "automate the compliance review," "put a copilot on the dashboard." Underneath each one is a workflow that has been hurting them for long enough to show up on a CFO's quarterly slide. The workflow is what you are being paid to change. The solution is a guess the customer made before you got here.

A small set of questions does most of this work. They look dumb written down, which is why people skip them.

• What does this look like today, end to end? Walk the ticket from arrival to close. Draw it if you have to. The bit everyone forgets to mention is usually where the real cost lives.
• Who decides when this is done? A named person, not a committee. If the answer is "we'd discuss it," the decision does not exist yet, and nothing you ship can finish.
• What happens if we do nothing? If the honest answer is "not much," there is no POC worth running. That is not a bad outcome. It is the discovery that saved both parties a quarter.
• What have you already tried? Previous attempts are free information, and the way the customer describes why they failed tells you how they will judge you.
• Where does the data actually live? Not where the architecture diagram says it lives. Where the person doing the work copies and pastes it from.

What a good discovery call sounds like

discovery

1. >You typed: You mentioned wanting an AI chatbot for the support portal. Before we talk about that, can you walk me through what happens today when a customer opens a ticket?

3. WhyThat is the whole brief. Four minutes times 40% of a known volume of tickets is a dollar figure, and 'they all look identical' is a strong signal that a narrow tool beats a general chatbot.

4. >You typed: If we made the billing ones 30 seconds instead of four minutes, who would notice first, and how would they measure it?

6. WhyA named owner, an existing dashboard, and a metric she already watches. This is a scopeable POC and the exit criterion writes itself.

7. >You typed: What have you tried already?

9. WhyNot an eval result — a vibe. That tells you this customer will judge you the same way unless you install the measurement they are missing. Install it in week one.

Count what happened in that six-turn exchange. The named solution dissolved, a workflow replaced it, a measurable target appeared, and the person who decides emerged by name. You could write the first week of the POC from here.

The discoveries that disqualify

Sometimes discovery ends with the right answer being no. A short list of the findings that should move you toward walking away, even — especially — if the contract is signed:

• No named production owner. If nobody on the customer side will take the pager when the agent misbehaves at 2am in month three, the POC will succeed and the system will still die. Build something nobody will carry and you have built a cost.
• Nothing to measure against. No ground truth, no historical outcomes, no dashboard anyone looks at. You can create one, and it costs a week, so the POC needs to buy that week back. If the customer resists measurement, there is no world in which your work will be judged fairly.
• A frozen environment. The data you need is behind three approvals a quarter, and the person who signs them is out until February. The POC is real; the project is not.
• A hostile stakeholder you cannot route around. Not every internal politics can be navigated. If the person whose workflow you would be replacing has veto power over whether this ships, name it in the room before you commit.

Saying no is the professional move, and it is easier to say now than in six weeks. Phrase it honestly: "Given what we heard today, I don't think a POC in this shape converts. Here is what I would want to see change before we tried again." That is not losing a customer. It is being the person a customer calls back.

What to take away

A discovery call is a scoping instrument. The customer named a solution, and your job is to walk their workflow until the real problem shows itself, name the person who will own the production system, find the metric that would settle whether it worked, and decide — honestly, in the room — whether a POC in this shape converts. Four questions do most of the work: what does this look like today, who decides when this is done, what happens if we do nothing, and what have you tried. The discovery that disqualifies — no owner, nothing to measure, a frozen environment, a hostile stakeholder you cannot route around — is the discovery that saved both sides a quarter.

Next: scoping a POC that leads to production, not to another POC — the three commitments to insist on before a line of code is written.