The Forward Deployed Engineer Loop
Embed a real engineer inside the customer's building and run a build-show-iterate cycle every single day
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
Palantir's signature go-to-market motion: instead of talking to customers over Zoom, you place an engineer who can actually build product at the customer's own desk four days a week. That engineer learns the problem, builds software to solve it, shows it, gets feedback, and iterates the same night — producing four or five learning cycles a week. Solutions built for one customer get folded back into the core product. It is also why Palantir became a founder factory: each engagement is five reps of building a company in miniature.
Origin
Described by Nabeel Qureshi from ~8 years at Palantir, where he ran this motion at Airbus and the NIH. The 'forward deployed' label and the BD (business development) vs PD (product development) split are Palantir-native. Qureshi notes Looker and the AI labs have since copied versions of it.
Core principles
- 01The forward deployed engineer must be a real engineer empowered to build brand-new product on the spot, not a solutions architect who only configures the existing product.
- 02Being physically in the room builds trust and problem-understanding that remote engagement cannot match.
- 03Price to the customer's outcome (the $100M plane fix), not to the infrastructure — this funds the wasteful discovery.
- 04You must be willing to be almost wasteful in finding the thing, which only works above a certain deal size (customer revenue in the millions).
- 05Solve the actual mission, not just deploy or sell software.
How to run it
- 1
Physically embed at the customer
Get a desk, a laptop, and login access inside the customer's building. Spend roughly Monday to Thursday working alongside their employees rather than interviewing them occasionally over Zoom.
Pro tip Go out to dinner with the stakeholders. In-person time before you have anything to sell is where the trust that closes the deal is built.
- 2
Learn the mission, not the requirements list
Take the customer's actual goal ('ramp A350 production 4x') rather than a spec ('upgrade our data infrastructure'). Learn the ins and outs of their business until you can speak their language and they see you as one of them.
Watch out If you take the requirements document at face value you will build the wrong thing; the stated ask is rarely the real problem.
- 3
Run a daily build-show-iterate cadence
Compress the feedback loop to a single day: meet in the morning, build that night, show it and collect feedback the next day, iterate that night. Aim for four or five of these cycles every week so you are moving incredibly fast.
Pro tip Six weeks of daily cycles can take a rough idea to something a customer will pay millions for.
- 4
Generalize the one-off into the core product
After you have solved it de novo, ask what the unified, productized version of this looks like. Extract the transferable primitive (e.g. mapping messy tables to human concepts) and fold it into the platform so the next customer needs fewer people.
Pro tip Track revenue-per-engineer as your north star: the ratio of engineers-to-customer should fall over time as the product absorbs each lesson.
Watch out If every new customer still needs a from-scratch build, you are a consulting business wearing a product costume — the margins will expose you.
In the wild
Airbus needed to ramp A350 production far faster than ever. Qureshi lived in France ~18 months, flying between countries where components were built. The team pulled Airbus's alien-named SAP tables, joined them, and mapped them to human concepts (part, work order, aircraft) so any worker could ask 'where is aircraft 79 and what work remains?'
→ Production ramped roughly 4x in a year; Airbus's CEO said Palantir played a critical part. The table-to-human-concept mapping became Foundry's 'ontology,' still a core differentiator.
Engineers embedded with an energy company had to learn how oil wells work, discovered that streaming data was valuable for the use case, and built that capability in the field.
→ A product that handles streaming data became part of the core platform.
Common mistakes
Staffing 'forward deployed engineers' who cannot build
Many companies use the label for solutions architects who only listen and configure the existing product. Without the power to build new product de novo, the motion loses its whole advantage — you cannot solve novel problems, only fit customers to what you already have.
Running the full motion below the required ticket size
The wasteful, high-touch embed only pays for itself when each customer's revenue is in the millions. Below that, a full-time on-site engineer per account destroys the economics; you need a lighter ratio (one engineer across ~five accounts) instead.
Is it for you?
Best for
Founders selling high-ticket (millions per deal) software into large, complex enterprises or governments where the real problem is undefined
Not ideal for
Low-ACV or self-serve products, or teams unwilling to be wasteful in discovery — Hex's CEO argues most companies do not need FDEs
From the transcript
“Monday you go in, you do your meetings, Monday night you build something, Tuesday you show it to somebody, Tuesday you get the feedback, Tuesday…”
“you learn about the problem you figure out what software would best address it you build that software you use it to accomplish the goal…”
“they were actually real engineers who could build product themselves”
“you need each customers revenue to be probably in the millions of dollars”
From the episode
How Palantir built the ultimate founder factory
Nabeel S. Qureshi (founder, writer, ex-Palantir)