The Forward Deployed Engineer playbook for AI startups

Executive overview

Most enterprise software markets have an incumbent product to displace. AI agents don't — the category is undefined, the workflows are new, and product discovery can only happen from inside the customer's organisation. The Forward Deployed Engineer (FDE) model solves this: engineers embedded at customer sites fill the gap between what the product does and what the customer actually needs.

Developed at Palantir by Shyam Sankar in the mid-2000s, the model turns what looks like expensive services into a product moat — as long as the team is disciplined about generalising what they learn.

The FDE model is doing things that don't scale, done scalably, over and over again for each new market segment.

Origins at Palantir

• Palantir's customers (intelligence agencies, military) couldn't describe their workflows, so standard product discovery failed.
• Stephen Cohen demoed software to spies, asked what was wrong, and wrote everything down — early-stage founder behaviour.
• The expected next step — find PMF, embrace distance, scale uniformly — never worked because every customer's problem was slightly different.
• The insight: lean into that heterogeneity. Build a platform, not a product. Send engineers to each site to customise it.
• Shyam Sankar formalised this into the FDE strategy — product discovery through field deployment rather than through sales conversations.

How the model is structured

• Two core roles: Echo team (embedded analysts, domain experts, account owners) and Delta team (deployed engineers who build the custom solution).
• Echo profile: deep domain knowledge plus a "heretic" mindset — someone who understands how things are done today and knows it's insufficient.
• Delta profile: fast prototypers who can ship rough, working code under pressure; craftsmen who prioritise clean abstractions are the wrong hire.
• A typical engagement: enter with a hypothesis, set a leadership presentation at ~3 months, then expand org-wide if it lands.
• Only pursue problems in the CEO's top five priorities — below that, there's no organisational energy to push through the friction.

FDE vs consulting: the key distinction

• The risk of devolving into consulting is real — founders should take it seriously, not dismiss it.
• Consulting builds what the customer asks for. FDE builds what the customer actually needs (often different).
• The financial signature of a healthy FDE business: early contracts lose money, then margins turn positive as product leverage grows and headcount per deployment falls.
• The signal you're scaling correctly: delivering the same outcome at the second customer takes less effort than the first.

The product team's role

• Product's job is not to design flows for millions of users — it's to hold the product vision across customers.
• The failure mode: FDE builds something for one customer, product ships that directly. The result is over-specialisation.
• Correct loop: FDE builds a gravel road at customer A; product generalises it into a paved highway that also fits customers B through E.
• Palantir's ontology (objects, properties, links) emerged this way — one level of abstraction up from any single customer's schema.
• Get FDEs from multiple similar customers in the room when designing a generalised feature; removes the "too specific vs too general" argument.
• Product should also be delivering leverage to the FDE, not just to the end user — the FDE is a customer of the platform.

Pricing and contracts

• Don't sell software installation. Sell a solved problem — a delivered outcome.
• Contracts should grow over time as you earn access to higher-value problems at the same customer (land and expand).
• The KPI is not "how much custom work per customer" but "value of outcome delivered" and "product leverage per FDE."
• Early on, take on all the risk: charge on success or on expansion. The enterprise doesn't believe you can execute; you do.
• On-premise deployments add friction — you'll need executive air cover to bypass IT gatekeepers.

Hiring and team-building

• The best FDE teams at AI startups today have someone from Palantir in a core role; the mechanics are genuinely different from standard software sales.
• FDE training is founder training — every site is a mini-startup with product leverage behind it.
• Palantir has produced an outsized number of startup founders because the company never stopped doing the grinding, learning work of a new startup.
• Join a young company, not necessarily a small one: young companies still learn, which is the skill that makes founders.

Demo-driven development

• At Palantir, one canonical demo (stopping a terrorist plot) was the lens through which every new feature was evaluated.
• Integrating a new feature required showing how it helped the analyst in that demo — forced product coherence.
• Demo-driven development shifts the question from "what can I build?" to "what does the customer want?" — the same reframe the FDE model makes at the account level.
• A good demo creates desire: the customer wants to reach out and take it. That's the signal you've found a real pain point.

Why AI agents need the FDE model now

• SaaS has an incumbent product to beat — the segmentation is known, the workflow is defined, you can scale by replacement.
• AI agents have no incumbent product. What "AI agents" even means is still being discovered; in five years it will likely split into many distinct categories.
• Model capabilities are improving faster than enterprise adoption. The gap between what AI can do and what organisations have deployed is enormous — that gap is the opportunity.
• Startups are the FDEs for OpenAI's research: filling the adoption gap between capability and real-world use, the same way Palantir's field teams filled the gap between platform and customer workflow.