The problem
AI products sold with a POC create a seam that didn't exist when software was sold with a demo. The SE proved the model could do the job on data the SE controlled. The FDE has to prove it on data the customer controls, under the customer's permissions, inside a workflow the customer's team already runs.
The typical flow:
1. SE runs a two-to-four-week POC on an export, a sandbox, or synthetic records. 2. Buyer sees good outputs and signs. 3. Deal closes; an FDE is assigned with a Slack intro and a link to the SOW. 4. FDE asks for production access, discovers the data looks nothing like the POC export, and learns that the "auto-update the CRM" step was a mock. 5. Customer asks why the deployment is slower than the POC. Trust drops in the first month.
The underlying issue: a POC is evidence that something is possible. A deployment needs evidence that it works for named people on real data. Those are different artifacts, and nobody is assigned to translate one into the other.
The fix: a POC-to-deployment brief, written by the SE before close
Generated from POC artifacts and call recordings, reviewed by the SE, and read by the FDE before kickoff.
Required sections
#### 1. What the POC actually proved
- Data used: source, row count, date range, and how it differs from production (cleaned, sampled, de-duplicated, synthetic)
- Model, prompts, and configuration that produced the outputs the buyer saw
- The eval results, if any existed, and the cases that failed
- Which steps were real and which were mocked: retrieval, writes back to systems of record, permission checks, notifications
The mocked-steps list is the most valuable line in the document. Every mocked step is unscoped engineering work.
#### 2. What was promised
Quoted from Gong calls and email, not paraphrased:
- Outcomes the buyer was told to expect, with any numbers mentioned
- Integrations named in the sales cycle
- Timelines given ("live in 30 days")
- Anything the SE flagged as a stretch at the time
#### 3. The customer's people
- Sponsor and what they personally need from this to succeed
- Daily users the POC was shown to, and their reaction
- IT or security contacts who gate production access, and what they asked for
- The person who will own the system after the FDE leaves, if known. If unknown, mark it as the first open question.
#### 4. Access and data reality
- Systems the deployment must read from and write to
- Known permission model (who can see which records) and whether the POC respected it
- Data quality issues seen during the POC
- Procurement or security reviews still open
#### 5. Open risks
The three things most likely to make the deployment look worse than the POC, in the SE's own judgment.
The prompt
Run after the deal closes, against the POC repo or notebook, call transcripts, and SOW:
You are writing a POC-to-deployment brief for a forward deployed engineer.From the POC artifacts, call transcripts, and SOW below, produce the five sections: 1. What the POC proved (data, config, eval results, and a REAL vs MOCKED table for every step) 2. What was promised (direct quotes with call/date references) 3. Customer people (sponsor, users, security contacts, post-deployment owner) 4. Access and data reality 5. Top three risks that would make production look worse than the POC
Rules: quote, don't paraphrase, for anything the customer or SE said. If a fact is missing, write UNKNOWN and say who would know. Never fill a gap with a plausible guess. ```
The meeting
A 45-minute SE-to-FDE session before customer kickoff:
1. **15 minutes on the mocked-steps table.** For each mocked step: why it was mocked, what the real version needs, who on the customer side unblocks it. 2. **15 minutes on promises.** The FDE decides which promises become the pilot's success metric and which get reset with the sponsor in week one. Resetting early costs less than missing late. 3. **15 minutes on people.** Who to call first, who to avoid surprising, who has opinions about the tool that never came up in the sales cycle.
The SE stays on the account Slack channel for the first 30 days. Questions the brief did not answer go there, and the SE updates the brief template so the next POC records the answer.
How the FDE uses it
The brief becomes the input to the FDE's pilot charter (see the [eval-gated pilot playbook](/playbooks/fde-eval-gated-pilot)): the outcome comes from the promises, the eval set starts from the POC's failed cases, and the out-of-scope list starts from the stretch promises the sponsor agrees to drop.
Metrics
- Days from close to first production write
- Number of mocked POC steps discovered after kickoff (target: zero; each one is a brief failure)
- Promises reset in week one versus missed at day 60
- Customer-reported "you already asked us that" moments in the first month
What breaks this
- SEs paid on close with no stake in deployment. Tie a small part of SE comp or recognition to time-to-first-production-write.
- POCs built in throwaway notebooks. Require POC work to live in a repo the FDE can open.
- FDEs assigned after kickoff is scheduled. The brief needs a reader before the customer meeting, not during it.
To learn the FDE side of this seam in depth, [FDE Academy](https://open-fde.ai/) covers discovery, thin slices, evaluation, pilots, and handoff as a free 20-chapter guide.