The Forward Deployed Engineer Playbook

The whole role on one sheet — discover the problem, prototype fast, integrate, deploy in the customer’s world, demo, harden, hand off.

A forward deployed engineer (FDE) is a software engineer embedded with a customer to make the product succeed in their environment: find the real problem, build against their data and systems, ship it where they can use it, and leave them able to run it. Palantir popularized the role, and it is now common at AI companies.

The job is measured by the customer’s outcome, not by tickets closed. That is why this playbook keeps returning to the same three things: a written metric, working software every week, and a planned exit.

The loop

1. Discover: Sit with the user. Find the real problem and the metric that proves it’s solved — not the requested feature.
2. Prototype: Build the smallest thing that demos the value this week. Throwaway is fine; a slide is not a POC.
3. Integrate: Connect to their real systems (auth, data, APIs). Integration is where POCs die — de-risk it first.
4. Deploy: Ship it where they can use it — their cloud/VPC/on-prem. Match their security reality.
5. Demo: Tell a story with their data. End on the "so what". Have a fallback for live failure.
6. Harden: Turn the POC into a system: errors, retries, monitoring, a runbook.
7. Hand off: Enable their team. Docs + training. Avoid owning it forever.

The first two weeks

Day 1: meet the champion and two real users; file every account, VPN and data-access request
Days 2–3: shadow the workflow end to end; collect 20 real examples and today’s metric
Day 5: a one-page scope — problem, metric, baseline, constraints, out of scope — signed off
Week 2: a working prototype on their real data, demoed to the people who will use it
Every Friday: a short status note: progress, blockers, decisions needed, next week

Discovery artifacts

Problem statement: one sentence in the customer’s words: who hurts, how often, at what cost
Success metric: one number with today’s baseline and a target, agreed in writing
Constraints doc: where it can run, data rules, systems to integrate, security-review steps
Stakeholder map: champion, budget holder, users, IT and security, likely blockers — and what each needs
Decision log: dated scope calls and who made them — it ends “we never agreed to that”

Prototype tactics

Real data on day one: a demo on synthetic data proves nothing; get a sanitized real sample early
Fake the hard parts: stub the slow integration behind an interface and swap in the real one later
Time-box spikes: one or two days to answer one question (“can we read their PDFs?”), then decide
Build the eval early: turn their examples into a test set before tuning prompts or models
Show it ugly: a rough working version this week beats a polished one next month

Integration checklist

Access first: SSO and service accounts take weeks — request them on day one
Read before write: start read-only; writing to their systems comes after trust is earned
Sandbox vs. production: confirm a sandbox exists and behaves like production — they often differ
Rate limits: their APIs and your model provider both have quotas; measure before you scale
Data mapping: a field-by-field map with a named owner for every ambiguous field

What makes an FDE different

Owns the outcome: Not "I shipped the ticket" — "the customer got value". You’re measured on their success.
Full-stack + human: Backend, frontend, data, deploy — plus discovery, demos, and stakeholder trust.
Speed over polish: A working thing in front of a user beats a perfect thing next quarter.
Reads the room: Exec wants ROI; IT wants security; the user wants their day easier. Speak to each.
Weekly demo: show working software every week — momentum is an FDE’s main currency
Escalate early: blocked over two days on access or a decision? Escalate through the champion
Say no with a trade: “We can add that if we drop X or move the date” — scope changes stay explicit

Measure & hand off

Time to first value: days from kickoff until a user gets value from real data — the headline number
Adoption: weekly active users and repeat use, not logins at the launch meeting
The business metric: the number from discovery, measured against its baseline
Product feedback: patterns seen across customers, written up for the core product team
Runbook: deploy, roll back, rotate secrets, fix the top five failures — tested by their team
Named owner: a person on their side owns it in production before you leave
Exit criteria: agreed at the start: what “done” means and what support continues afterwards

Anti-patterns

Building in a vacuum: Weeks of work, no customer contact → wrong thing. Demo weekly.
Boiling the ocean: Trying to solve everything → nothing ships. Pick one workflow.
Ignoring security early: A great POC that security vetoes at the end. Involve them in week one.
Forever-ownership: No handoff → you become their support team. Plan the exit from day one.
Custom forks: a branch per customer becomes unmaintainable — push needs back into the product
Metric-free success: “They loved the demo” with no number attached cannot justify a renewal

Recipes

A two-week proof-of-concept plan

Week 1
  Mon      kickoff: confirm problem, metric and baseline; file every access request
  Tue      shadow 3 users; collect 20 real examples (good, bad and weird)
  Wed      spike the riskiest integration: can we read their data at all?
  Thu      first end-to-end path on 5 real examples, however ugly
  Fri      scope signed off; status note; build the eval set from the examples

Week 2
  Mon-Wed  harden the happy path; score it against the eval set every day
  Thu      dry-run the demo with the champion; fix whatever confuses them
  Fri      demo to users and the decision maker; agree go / no-go criteria

The riskiest integration goes on day three, not day nine: if their data cannot be reached, you want to know while there is still time to change plan.

Turn a vague ask into a scoped success metric

ask:        "Use AI to make our analysts more productive."
which job:  "Which task eats the most analyst time?"   -> writing the weekly market summary
how much:   "How long does it take today?"            -> 6 hours each, 12 analysts (72 hours)
what good:  "What would make it trustworthy?"          -> every number cited to a source

metric:     hours to produce the weekly summary (baseline 6, target under 2)
guardrail:  100% of figures traceable to a source document

The guardrail matters as much as the metric: a faster summary with one invented number loses the customer’s trust for good.

A weekly status note

Subject: Invoice matching POC, week 2

Done:       matching on 2,000 real invoices; 71% auto-matched, 0 false matches over $500
Next:       exception-queue UI; demo to the AP team on Thursday
Blockers:   ERP write access is in security review (asked 9 days ago); need help from Dana
Decision:   partial matches go to the queue instead of auto-approving: yes or no by Wednesday?
Risk:       the PO export drops freight lines; workaround in place, real fix needs their ERP admin

Name the person who can unblock each item, and phrase decisions as yes-or-no questions with a date. Five lines read on a phone get acted on; two pages do not.

A demo that survives a live failure

1. open with their problem in their numbers: "2,000 invoices a month, 4 minutes each"
2. run the workflow live on their real data, narrated as the user's day
3. show one failure on purpose and how the system handles it (the exception queue)
4. land the metric: "71% auto-matched, about 95 clerk-hours back every month"
5. keep a recorded run ready in case the network or a service goes down
6. close with the decision you need, and by when

Showing a failure deliberately builds more trust than a flawless run, because every buyer knows the real system will fail sometimes.

Questions about The Forward Deployed Engineer Playbook

What is a forward deployed engineer?

A forward deployed engineer is a software engineer who works directly with customers, often on site or embedded in their teams, to make a product deliver results in their specific environment. The work spans discovery, rapid prototyping against the customer’s real data, integration with their systems, deployment in their cloud or data center, demos for stakeholders, and handing the result over to their team. The role was popularized by Palantir and has spread to AI companies, where adapting models and agents to messy enterprise workflows needs engineering skill rather than configuration alone.

What is the difference between a forward deployed engineer and a solutions engineer?

Solutions or sales engineers mainly support the sale: they run technical demos, answer security questionnaires and design proofs of concept, usually before a contract is signed and often without writing production code. Forward deployed engineers are builders who ship working software in the customer’s environment, frequently after the deal, and are measured on whether the customer actually gets value. In practice the line blurs, and many companies blend the roles, but an FDE spends far more time writing and deploying code, while a solutions engineer spends more of it in front of buyers.

What skills does a forward deployed engineer need?

Strong general software engineering across the stack: backend services, data pipelines, APIs, some frontend, and deployment with containers, cloud and Kubernetes. For AI roles, add practical experience with LLMs, retrieval, agents and evaluation. Just as important are the customer-facing skills: running discovery conversations, turning vague requests into measurable goals, demoing to executives, writing clearly and handling pressure and ambiguity. FDEs also need judgment about when to build a quick hack and when to push a need back to the product team, and the discipline to hand work off cleanly instead of becoming permanent support.

How do you run a successful proof of concept?

Agree before you start on one workflow, one success metric with a baseline, and the criteria for a go or no-go decision, all in writing. Get access to real data and systems on the first day, and attack the riskiest integration first rather than polishing the easy parts. Build an evaluation set from the customer’s own examples so progress is measurable, and demo working software every week to the people who will use it. Keep the timeline short, typically two to six weeks, and finish with a demo that ends on the metric and a clear decision.

Go deeper

FDE roadmap →Customer discovery questions →