Y

Customer-facing delivery · Beginner

The discovery call

3 min read

Why it matters

Customer-facing delivery appeared in 62% of the Forward Deployed Engineer job descriptions we read. The first conversation with a customer sets the scope of everything that follows. Engineers who jump to a solution in the first ten minutes usually build the wrong thing, beautifully.

The concept

A discovery call has one job: understand the problem well enough to propose a small, measurable first step. Cover five areas:

  1. The workflow today. Who does what, in which tools, how often, and how long it takes. Ask them to share their screen and walk through a real case.

  2. The pain and its cost. Hours spent, errors, backlog, missed revenue. Ask for numbers they already track.

  3. The data. Where it lives, who owns it, its format, volume and sensitivity. Can you get a sample, and under which agreement?

  4. The decision makers. Who sponsors the project, who will use it, who can say no (security, legal, IT)?

  5. Success. What would have to be true in eight weeks for them to call this a success?

Listen more than you talk. A useful ratio is that the customer speaks for most of the call. Close by reading back what you heard and agreeing next steps with owners and dates, then send them in writing the same day.

Worked example: a claims team

The insurer, people and numbers in this example are illustrative, not from a real engagement.

An insurance operations lead says: "We want AI for claims." A discovery call produces these notes:

discovery-notes.md
# Discovery: motor claims intake (call 1)
Attendees: Priya (Ops lead, sponsor), Rahul (claims handler), you.

Workflow today
- Claims arrive by email with photos and PDFs (about 400 a day).
- Handlers read each one, fill 22 fields in the claims system, and route it.
- Average 9 minutes per claim; backlog peaks on Mondays.

Pain
- Monday backlog breaches the 24-hour acknowledgement target (they track this weekly).
- 6% of claims routed to the wrong team (from their QA sample).

Data
- Emails and attachments in a shared mailbox; claims system has an API (read and write).
- Contains personal data: names, phone numbers, vehicle numbers. Security review needed.

People
- Sponsor: Priya. Users: 30 handlers. Approvers: IT security (Anil), DPO.

Success in 8 weeks (Priya's words)
- "Handlers only check fields instead of typing them, and Monday backlog is gone."

Next steps
- Priya: share 200 anonymised sample claims by Friday.
- You: send a one-page pilot proposal by Tuesday.
- Anil: send the security questionnaire.

Notice what is not in the notes: a model, an architecture or a promise. Those come in the pilot proposal, once you have seen the data.

Common mistakes

  • Pitching in the first call. Every minute you spend presenting is a minute you do not learn.

  • Only talking to the sponsor. The handlers know the edge cases; security knows the blockers.

  • Accepting "AI for claims" as a requirement. Keep asking until you reach a workflow, a metric and a number.

  • No written follow-up. Memories diverge within days. Send notes and next steps the same day.

Interview angle

FDE interviews often include a role-play: "I am a customer who wants an AI assistant. Go." Interviewers look for structured questions about workflow, data, users and success, not for a solution. End by summarising and proposing a small next step.

Practice task

  1. Ask a friend who works in operations, sales or support to describe one repetitive task. Run a 30-minute discovery call with the five areas.

  2. Write the notes in the format above and send them for correction. Count how many facts they correct.

Further reading