Field Feedback Template For FDEs: The Evidence Packet

FDE work often creates an awkward handoff. You are close enough to hear where a customer workflow breaks, but the team that could change the product was not in the room. A sentence such as “Customer X needs better handling for Y” may be urgent, but it does not let a receiving team distinguish an access issue, source-data problem, workflow flaw, evaluation gap, capability limitation, or local exception.

Proposed method: this packet is FDE Brief editorial synthesis, not an Anthropic operating standard or proof that a packet improves adoption. Its purpose is modest: preserve enough evidence that another team can decide what the report means.

Why field feedback needs a record

Anthropic’s current Applied AI Research Engineer posting says the role should engage hands-on with strategic customers, package learnings into scalable approaches, and synthesize adoption patterns, common blockers, and capability gaps for Product and Research. Its current Manager, Forward Deployed Engineering posting calls for reusable playbooks, integration templates, an internal knowledge base, and translation of field insights into product improvements.

Those are employer-authored descriptions of responsibilities at one company, checked October 8, 2026. They do not establish a universal FDE process or show that every customer report should become roadmap work. The interpretation here is simply that the handoff must be inspectable before it can responsibly influence a broader decision.

The five-field packet

Field	What to capture	Why it matters
Workflow and user	The user, job, decision or output, and system boundary.	Prevents a vague request from standing in for the real work.
Observed blocker and evidence	Expected versus actual behavior, test case or input, environment details, and a sanitized artifact, trace, or evaluation reference.	Separates what happened from an explanation of why.
Workaround and risk	What the field does today, plus delay, review burden, reduced scope, reliability, privacy, or support risk.	Makes an existing workaround visible instead of silently turning it into supported behavior.
Pattern qualification	Label it local exception, needs another example, or candidate reusable pattern.	Keeps a hypothesis from being mistaken for a generalization decision.
Decision requested and owner	One requested call, a receiving owner, and the next evidence needed if the answer is not yet.	Asks for a decision rather than attention.

If a blocker cannot yet be reproduced, record that plainly. Reporting should not wait for a perfect test case; it should make the missing evidence visible.

Worked fictional example: a document workflow

This example is fictional. A claims analyst uses multi-document renewal packets to identify policy exceptions. On three sanitized packets with tables and addenda, an assistant cites the wrong clause after combining documents. The expected behavior is a clause citation with document and page. The current workaround is manual verification for all renewal packets.

What a usable packet says

Workflow: identify a policy exception before issuing a coverage decision; the assistant proposes citations and a human reviews them.
Evidence: three sanitized packets, expected and actual citations, and the configuration/version used; the packet does not claim a root cause.
Workaround and risk: mandatory manual verification keeps the workflow bounded, but removes the time-saving claim; it must not be represented as a supported unattended flow.
Qualification: needs another example, because three similar cases are not proof of a general pattern.
Decision: ask the named product or technical owner whether the next step is a bounded evaluation, a retrieval/design investigation, a documented limitation, or more evidence.

The example demonstrates evidence quality, not a real customer incident, a recommended model architecture, or an outcome claim.

Use the packet before escalating

Open it at the moment of friction. Capture the workflow and observed result before the account story absorbs the technical detail.
Separate fact from explanation. Put observed evidence in one field; label suspected cause as a hypothesis.
Keep the workaround attached. The receiving team needs to see what the field is doing instead and where that substitute stops being safe or supportable.
Ask for the smallest next decision. Add an eval, document an exclusion, investigate a defect, collect another example, promote a shared pattern, or decline generalization.
Close the loop in the same record. Log the answer, owner, and disposition so the next FDE does not treat the same blocker as brand-new evidence.

What this signals in an FDE story

A strong FDE interview story can move from an ambiguous complaint to a bounded technical claim: the workflow, the evidence preserved, the workaround and tradeoffs, and the decision that followed. That is more revealing than saying only that feedback was sent to Product.