Y

Customer-facing delivery · Intermediate

Demos on the customer's data

3 min read

Why it matters

A generic demo shows that a product works. A demo on the customer's own data shows that it works for them, and it surfaces the real edge cases early. Forward deployed engineers give many demos, and most of them are to people who will decide whether to trust the system with their work.

The concept

A good field demo follows a simple script:

  1. Start from their problem. Open with the workflow and the numbers from discovery: "Today a claim takes 9 minutes. Here is one from last Monday."

  2. Use their data, anonymised if needed and with permission. Pick a typical case first, then a hard one.

  3. Show the human in control. Where does a person review, correct or override?

  4. Show a limit on purpose. Pick a case the system gets wrong or refuses, and show how it is caught. This builds more trust than a perfect run.

  5. Close with evidence and a next step. Evaluation results on their sample, and the decision you are asking for.

Prepare for failure. Record a backup video of the full flow, keep a local copy of the data, and know which step is most likely to fail (network, rate limits, a slow model call).

Worked example: a demo script

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

demo-script.md
# Demo: assisted claims intake (20 min, Priya + 4 handlers)

1. (2 min) Recap: 9 min per claim, Monday backlog, 6% misrouted. Agenda and what we ask for today.
2. (5 min) Typical claim from last Monday: email in, 8 fields extracted, routing suggested.
   Handler Rahul confirms two fields and saves. Show the time taken.
3. (4 min) Hard claim: two vehicles in one email. System extracts both and flags the claim
   for review instead of guessing. Show where the handler resolves it.
4. (3 min) Evaluation on 200 labelled claims: field accuracy per field vs manual QA sample.
   Name the weakest field (policy number from scanned PDFs) and the plan for it.
5. (4 min) Questions. Write down every question and who owns the answer.
6. (2 min) Ask: approval to start the 5-handler live phase on 18 Nov.

Backup: screen recording of steps 2 and 3; local copy of both claims; offline slides.

The script is timed, uses real cases, shows a limitation deliberately and ends with a specific ask.

Handling live failures

When something breaks, stay calm and narrate: "The model call has timed out. In production this retries and alerts us; let me show you the recorded run while it recovers." Then note it and follow up in writing with the cause and the fix. A calm recovery with a clear explanation often reassures customers more than a flawless demo.

Common mistakes

  • Feature tours. Showing every button instead of one workflow end to end.

  • Only happy paths. Customers know their messy cases and will ask. Show one first.

  • Unclear ask. Ending with "any questions?" instead of a decision you need.

  • Promising on the spot. "We can definitely do that" to a new request. Say you will scope it and come back.

Interview angle

Some FDE interviews ask you to demo a project you built to an interviewer playing a customer. Use the script: their problem, a typical case, a hard case, evidence, a clear ask. Interviewers watch how you handle questions you cannot answer.

Practice task

  1. Write a 15-minute demo script for one of your projects using the six steps.

  2. Deliberately break something during a practice run (disconnect the network) and practise your recovery line.

Further reading