The FDE Is the Product Builder Wearing a Visitor Badge

OpenAI raised more than $4 billion in May for a company whose product is deployment. Anthropic launched a $1.5 billion joint venture the same month for the same job. Google Cloud, Databricks, Salesforce, and every startup selling agents has a listing for the role. Forward deployed engineer is, by the count of people writing guides to it, the hottest job in AI.

I think it is a job this site has been describing for a year under a different name, from the other side of the building.

The short version

The forward deployed engineer is an engineer employed by a vendor, embedded in a customer, and accountable for the outcome the software produces there. Palantir popularized the role around 2008 and ran four vintages of it; the one thing 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 needs the same six skills the Product Builder OS describes. The FDE arrived at them from services. The Product Builder arrived from product. Same collapse, one seat. I wrote it up as a new wave of the handbook, seven chapters, because the two mistakes companies are making with the role, confusing it with sales engineering and sending engineers into customers before the product can absorb what they learn, are both expensive and both avoidable.

Where the role came from

Palantir's origin story for the FDE is that selling data integration software into agencies did not work, because the agencies could not operationalize what they bought. So the company stopped shipping software and started shipping engineers. The embedded ones were Deltas. Each was paired with an Echo, a deployment strategist who owned adoption and politics. Until 2016 the company employed more FDEs than product engineers.

Nabeel Qureshi's account of the role is the one everyone cites, and it earns it. Three or four days a week on site. Build the version that solves this customer's problem fast, overfit and all. Let product development take it back and generalize it. That loop produced Foundry's ingestion tooling, its visualization layer, and its app builder, each of which started as one FDE's hack for one customer.

Natalie Meurer, five years a Palantir FDE and now running agent engineering at Sierra, traces four vintages: platform stability, then data integration, then custom solutions, then enablement, each stacked on the last. Her finding is that one thing survived all of them. Every forward deployed engineer is accountable to the customer.

Why now

Two forces, one seat.

Code got cheap. Meurer's framing is that when a prompt to a coding agent produces a working solution, what remains valuable is translating an ambiguous customer problem into the right build and guaranteeing it works. That was always the FDE's edge. It used to be buried under plumbing. The plumbing is now done by an agent.

And outcome pricing arrived. I have written about why Sierra is growing so fast: price the outcome, own the last mile, productize what the last mile teaches. Meurer's version from inside the company is sharper. Outcome pricing requires the seller to guarantee the outcome, and the question of how you guarantee it has one answer.

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

Six for six

Hold the role against the Product Builder OS: rapid prototyping, customer proximity, AI fluency, outcomes thinking, storytelling and distribution, end-to-end ownership.

An FDE prototypes on site from week one. Customer proximity is where they sit. AI fluency is the job listing at every lab. Outcomes thinking is the pricing model. Storytelling is how a Delta gets an operations director to change a twelve-year-old workflow, which is why Palantir paired them with Echoes. End-to-end ownership is the thing Meurer says never changed.

The Product Builder is what happens to a PM when building gets cheap. The FDE is what happens to a services engineer when building gets cheap. I made the product-side argument in Cagan Built the Church and in the handbook's opening wave. The FDE is the services-side proof that the collapse is real, and that it runs in both directions toward the same seat.

The two mistakes

The new wave exists because companies adopting the role are making two errors, and I have watched both from the vendor side.

The first is hiring sales engineers and calling them FDEs. The two look identical on a resume. One is done when the customer signs and the other has just started. Get it wrong and you have beautiful pilots and no production, and I would bet a large share of the 95 percent of enterprise AI pilots MIT NANDA found with no measurable impact are this mistake at industrial scale. Where the FDE starts and the sales engineer stops is a single line, and it is the chapter I would read first.

The second is sending engineers into customers without changing the product. That is not a deployment model. It is a consulting firm by accident, with forty bespoke systems to maintain and a product that learned nothing from any of them. Palantir worked because Foundry existed to absorb what the Deltas built. Five product changes come before the first hire: a configuration boundary, a per-customer sandbox, an eval harness, an observation record, and a feedback path with a named owner.

The wave

Seven chapters, in order.

The FDE is a Product Builder in disguise, the thesis and the history. FDE vs sales engineer, the one line between them. The transition from PM, engineer, or SE, each arriving with two of the three things the job needs. What has to change in the product before an FDE can do anything but bill hours. The deployment-to-product loop, which is the entire economic case. The economics, including the buyer's lock-in objection and when to stop sending engineers. And building the team: reporting line, hiring bar, the Delta and Echo pairing, comp.

The buyer's objection, taken seriously

Andrew Ng has warned that letting a vendor's FDEs wire your processes to their stack reduces your optionality, and that your own AI engineer on staff is the better structural bet. He is right as stated. Plank's guide adds Gartner's expectation that enterprises will walk away from FDE-heavy engagements on cost.

The fix is in the contract. The observation record, what the agents did in your org and what got reversed, belongs to you and ports with you. Every configuration the FDE built is readable and exportable. Enablement is a deliverable with a test: your engineer can change the deployment without the vendor by day 60. A vendor who agrees has answered the concern. A vendor who will not has told you what their moat is, and it is not the product.

I am on the vendor side of that table with Heidi, and I would rather write those terms myself.

Try this week

If you sell AI into enterprises, find the person who is accountable when a deployment does not produce the outcome the customer bought. Not the person who gets 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 the new 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 · Andrew Ng on forward deployed engineers

This post opens a new wave in the running argument on AI Product Management: the job did not get harder, the parts we trained people for got cheap, and what one person can own is what is left.

Related answer: What is a forward deployed engineer?