Y

Customer-facing delivery · Intermediate

Handover, adoption and the feedback loop

3 min read

Why it matters

A deployment is successful when the customer's team uses it and can run it without you. Forward deployed engineers also carry the most valuable feedback a product team gets: what breaks in real environments. Doing both well is what separates field engineering from consulting.

The concept

Handover pack. Before you step back, the customer should have:

  1. Architecture overview on one page: components, data flows, where data is stored, who has access.

  2. Runbook: how to deploy, roll back, rotate credentials, and what to do for each alert.

  3. Evaluation and monitoring: the evaluation set, how to rerun it, dashboards and alert thresholds.

  4. Ownership: named owners on their side, and the support route to your company.

  5. Training: short sessions or recordings for users and for the team that will operate it.

Adoption. Measure after launch, weekly: active users, share of cases going through the new flow, the success criteria from the pilot plan, and the reasons people bypass it. Low adoption is data, not failure: ask the people who stopped using it.

Feedback loop. Write field notes for your product team: what you had to build that the product should have done, with evidence (how many customers, how much time). Keep them short and specific.

Worked example: a field note

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

field-note-2026-11.md
# Field note: scanned PDF policy numbers (claims intake, customer: motor insurer)

What happened
- Policy number extraction from scanned PDFs was 71% accurate on our 200-claim
  evaluation set, versus 97% for digital PDFs.
- We added an OCR pre-processing step in the customer's pipeline (3 days of work).

Why it matters for the product
- Scanned attachments are common in insurance intake. The same step will be needed again.

Ask
- Add optional OCR pre-processing to the ingestion connector, or document the pattern.

Evidence: evaluation run ids, the 3 PRs in the customer repo, handler feedback from week 5.

The note is specific, measured and actionable, and it separates what was done for this customer from what the product should change.

Common mistakes

  • Disappearing after launch. Adoption often dips in the first weeks. Check in weekly at first.

  • Knowledge only in your head. If you are the only person who can deploy it, it is not handed over.

  • Feedback as complaints. "The product is bad at PDFs" is noise. A measured field note gets prioritised.

  • Custom code without an owner. Every piece of code you leave behind needs an owner on the customer side.

Interview angle

"Tell me about a time a customer was unhappy with a deployment" and "how do you decide what to build for one customer versus what to push into the product?" are common. Talk about measured adoption, root causes, and field notes with evidence.

Practice task

  1. Write a runbook for one of your projects that someone else could follow to deploy and roll back.

  2. Hand it to a friend, watch them follow it without help, and fix every step where they got stuck.

Further reading