The Forward Deployed Engineer Is a Product Builder in Disguise

Every few years the industry rediscovers the same fact under a new name: software that ships without the person who built it does not get adopted. Palantir learned it around 2008, selling data integration into agencies that could not operationalize what they bought. Their answer was to stop shipping software and start shipping engineers. They called the embedded ones Deltas, and for most of the company's first decade it employed more of them than it did product engineers.

In 2026 the role is everywhere. OpenAI raised more than $4 billion for a company whose product is deployment. Anthropic launched a $1.5 billion joint venture for the same job. Google Cloud, Databricks, Salesforce, and nearly every startup selling agents has a job listing for it. It is, by most accounts, the hottest engineering role in the industry.

I think it is the Product Builder, arriving from the other side of the building.

The short version

A forward deployed engineer is an engineer employed by a vendor, embedded inside a customer, and accountable for the outcome the software produces there. Palantir popularized the role around 2008 and ran four vintages of it, each adding responsibility without shedding the last: platform stability, then data integration, then custom solutions, then enablement. The thread that survived every vintage is customer accountability. The role exploded in 2026 because code got cheap and outcome pricing arrived, and both make the person who guarantees the result the scarcest seat in the company. That seat requires the same six skills this handbook attributes to the Product Builder. The FDE got there from services. The Product Builder got there from product. They are the same job with different badges.

Where the role came from

Nabeel Qureshi, who spent years as a Palantir FDE and wrote the most cited account of the experience, describes the split plainly. FDEs embedded with the customer three or four days a week and wrote code that got the job done, technical debt and all. Product development engineers back at headquarters took what the FDEs built and generalized it. His line for the division: your job was to solve the problem and not worry about overfitting; PD's job was to take whatever you built and generalize it.

That loop produced the product. Palantir's data ingestion tooling, its visualization layer, and its app builder all started as things FDEs hacked together on site for one customer and PD later turned into Foundry components. The customer paid for the first version. Every later customer got it cheaper.

Natalie Meurer, five years a Palantir FDE and now running agent engineering at Sierra, breaks the role's history into four vintages. 2008 to 2012 was platform stability, getting the software to run on the customer's boxes. 2012 to 2016 was data integration and ontology modeling. 2016 to 2020 was building custom solutions on top. 2020 onward added customer enablement. Her observation is that these were not eras that replaced each other. Each one stacked on the last, so the total job kept growing.

What did not change across any of it, in her words: every single forward deployed engineer is accountable to the customer.

Why it is exploding now

Two forces arrived at once, and they point at the same seat.

The first is that code got cheap. Meurer's framing is that when a prompt to a coding agent produces a working solution, the marginal cost of software collapses and what remains valuable is translating an ambiguous customer problem into the right build, deploying it reliably, and guaranteeing it works. That was always the FDE's comparative advantage. It used to be buried under plumbing. The plumbing is now done by an agent, so the advantage is the whole job.

The second is outcome pricing. Sierra bills per resolved case. Salesforce put a work-completion metric on its earnings slide. I have written about why Sierra is growing so fast and the answer is an operating model, not a model: price the outcome, own the last mile, productize what the last mile teaches you. Meurer's version is sharper. Outcome pricing requires the seller to guarantee the outcome, and the question of how you guarantee it has one answer. That is forward deployed engineering.

So the vendors are not adopting the FDE because Palantir made it fashionable. They are adopting it because their pricing model has a guarantor-shaped hole in it, and the FDE is the shape.

The same six skills

Now hold the role up against the Product Builder OS, which defines the AI-era product role as six skills: rapid prototyping, customer proximity, AI fluency, outcomes thinking, storytelling and distribution, and end-to-end ownership.

An FDE prototypes on site, in the customer's environment, from the first week. Customer proximity is not a practice they schedule, it is where they sit. AI fluency is the job description at every lab hiring for the role. Outcomes thinking is the pricing model. Storytelling is how a Delta gets a skeptical operations director to change a workflow that has run the same way for twelve years, and Palantir paired every Delta with an Echo, a deployment strategist, because the politics of adoption are half the work. End-to-end ownership is the one thing Meurer says survived every vintage.

Six for six.

The difference is where each role came from. The Product Builder is what happens when a PM starts shipping because the cost of building fell. The FDE is what happens when a services engineer starts owning outcomes because the cost of building fell. Same collapse, two directions, one seat. I made the product-side version of this argument in Old PM vs Product Builder. This wave is the services-side version, and I think reading both is the fastest way to see that the role is not a job title. It is what one person can own once building is cheap.

What this wave covers

The chapters that follow take the role apart. Where the FDE starts and the sales engineer stops, because the confusion between them is expensive. How to make the transition from PM, engineer, or SE. What has to be true in the product before an FDE can do anything but bill hours. The loop that turns deployment into roadmap. The economics, including where the model stops paying. And how to build and run the team.

The argument underneath all of it is the one I keep making on AI Product Management: the job did not get harder. The parts we trained people for got cheap, and the parts nobody trained for are what is left. The FDE is the clearest evidence I have found that this is true on the services side too.

Start this week

If your company sells AI into enterprises, go find the person who is accountable when a deployment does not produce the outcome the customer bought. Not the person who is blamed. The person whose job it is.

If you cannot name them, you have found the hole your pricing model is about to fall into, and you have found what this wave is for.

Sources: Nabeel Qureshi, Reflections on Palantir · Natalie Meurer, The Dirty Secret of Forward Deployed Engineering, AI Engineer 2026 · Plank, What Is a Forward-Deployed Engineer · MarkTechPost on the OpenAI Deployment Company and Anthropic joint venture (May 2026)