Part of the Product Creator Series — this one follows the piece on generative-AI prototyping tools.
Consider a product failure: an AI feature takes six months to ship. The customer tries it twice, then goes back to the spreadsheet.
Meanwhile the roadmap keeps filling with requests from discovery calls — calls that describe, in confident detail, a workflow no one on your team has ever stood inside. The description gives you a map of the workflow. Watching the work lets you check where that map is wrong.
The fastest path to a product that works is not a better model or a longer discovery call. It is putting your best engineer inside the customer’s actual workflow before you decide what to build. That is the Forward Deployed Engineer model — technical people, engineers first and increasingly PMs and designers, embedded with customers to learn what it actually takes to deliver an outcome.
And it is not a Palantir trick. Most people file the FDE under “Palantir” and miss that it is a general law of product discovery — available to a founder with one engineer and a plane ticket.
How Palantir Built Products, and Why Everyone Misread It
The model was born from a constraint, not a strategy. Palantir’s first customers were intelligence agencies that could not openly describe what they needed — so the company had to discover requirements by watching the people doing the work [1].
That constraint hardened into a structure. Until 2016, Palantir employed more Forward Deployed Engineers than software engineers [2]. The embedded layer was not a billable side hustle bolted onto the product organization. It was the product-discovery organization.
The industry watched this for a decade and concluded Palantir was a consulting firm wearing a software costume. Then the stock returned 640% over five years from its 2022 low [13]. The label was wrong, and the lesson was expensive — which is roughly the going rate for lessons you decline to learn the cheap way.
None of this was a Palantir invention so much as a rediscovery. Steve Blank and Bill Campbell pushed founders toward the same instinct — you learn what to build by getting out of the building — long before Palantir made it famous. What Palantir added was the nerve to bet on the outcome rather than the spec, and the discipline to do it on every expansion: defense and intelligence into aviation, healthcare, oil and gas. Each one FDE-driven.
If embedding works this reliably, why does almost everyone build the opposite way?
Why the Spec-Execution Model Loses to the FDE Model
Because the dominant model is the reverse of discovery. The client dictates the spec, the vendor builds to it, and accountability stays with the client. So when the result underperforms, the client blames the vendor, the vendor points at the spec, and neither side owns whether the thing works. That is not a knock on any one firm — it is the model. The FDE move flips the arrow: engineers embed to discover what is needed, then sign up for the outcome, not for a document someone else wrote in a conference room.
A second engine makes the model harder to copy. Field discoveries feed reusable platform primitives, core engineering generalizes the pattern, and the next deployment starts further ahead [11]. The advantage compounds instead of resetting. That is part of what the market prices when it values Palantir near $400B against Accenture’s $150B — a model that turns each engagement into permanent platform capability, rather than one that resets at contract end and bills by the hour.
And here is what the spec-execution model structurally cannot see. Roughly 80% of the value in AI adoption comes from process redesign and organizational change, not from the model itself. That value is only visible from inside the workflow — and the spec was written before anyone watched the work. You cannot specify what you have not seen.
Why 95% of AI Projects Never Reach Production
A 2025 MIT NANDA analysis found that 95% of enterprise generative-AI pilots produce no measurable business impact. The model is rarely the culprit. The breakdown is in deployment, and the attrition starts earlier than most teams admit: for every 33 AI proofs of concept, only four reach production, and large enterprises abandoned an average of 2.3 AI initiatives in 2025, each carrying $7.2 million in sunk cost [4]. That is the price of discovering operational reality after you have already built for the wrong one.
The mechanism is consistent. POCs run on curated data, bypass legacy systems, and ignore the authentication, compliance, and workflow dependencies that govern real operations — so integration ends up costing 10x to 20x the estimate. The demo passes internal review because it was never asked to survive the environment it was built for. It is a stage set, and we keep mistaking it for the building.
Now look at what happens when someone closes the gap. John Deere already had AI capability — computer vision, data infrastructure, the works. The missing piece was operational: recommendations a farmer would trust under real soil variability and a closing planting window.
OpenAI’s FDE team embedded with Deere’s agronomists, reviewed hundreds of real planting examples, and built evaluation systems tuned to field conditions rather than benchmark accuracy. The eval criteria themselves were a discovery artifact — you cannot write them from a desk. Farmers then cut chemical usage by up to 70% across 5 million acres, saving 31 million gallons of herbicide mix in 2025. Not a smarter algorithm dropped onto the existing workflow — a workflow redesigned through embedded observation.
For AI products, the gap between demo and deployment is a context gap. And context does not travel over video.
What Embedding Looks Like, From the Minimum Move to the Full Model
Start with the irreducible version. If you do nothing else, send your best engineers to your customers’ offices and sit them with the people who will actually use the thing. That costs a fraction of what any single initiative in the failure pile cost to abandon, and it already beats remote discovery by a wide margin.
Ramp shows the floor scales upward on its own economics. By the company’s own account, the corporate finance platform formalized its FDE function in fall 2023 with two engineers accountable for customer outcomes rather than ticket counts — a discipline they called “always be scoping.” One feature gap estimated at three months of engineering was resolved in three days, through a workaround surfaced on a single customer call. The function grew roughly 10x as the case compounded: the core FDE model without the Palantir machine. Observe across customers, find what generalizes, build for all of them.
With a platform foundation underneath, it scales hard. Databricks embedded with Fox Corporation mid-deployment — search worked in staging and broke during live events — and doubled the search success rate with roughly 2x in-app engagement, one of 1,900-plus Databricks engagements that year [8]. The same shape holds at the top of the market: 98% adoption at Morgan Stanley, AI-native tools across 120,000 BBVA employees in 25 countries. Adoption, not just launch — because embedded discovery surfaces the workflow changes that make a system stick, not the demo criteria that make it ship.
There is a quieter payoff too. The people who do this work disproportionately become strong product leaders and founders, because they have stood inside the operational reality everyone else only describes secondhand. Adam Judelson’s arc — early Palantir FDE, now product coach — is exactly that. Embedding does not just build better products. It builds the people who know what “better” means.
Is This Just Consulting With a Better Logo?
The FDE literature also describes costs and failure modes that matter when deciding how much embedding a product can afford.
“It is too expensive to copy.” True, in its most expensive form. A Series A startup with eight engineers and 18 months of runway that embeds three of them with one customer for 90 days has an ending, not a strategy. And at mid-growth stage — 50 to 150 people running recurring embedded cycles across ten enterprise accounts — the opportunity cost of engineering hours in the field instead of on core product is real, and clever framing does not dissolve it.
But those attacks land on the full multi-month deployment, and the thesis only needs the minimum move. The question is not “how do we become Palantir?” It is “what minimum forward-deployment bridges the adoption gap for our category?” Set one flight against $7.2M in average sunk cost per abandoned initiative [4] and the cheap option picks itself. The genuine constraint shows up at scale-up size, where depth and throughput trade off — and that tradeoff is structural, not something you can out-hustle.
“It is just premium consulting.” This is the make-or-break objection, because it attacks the very model being recommended. Copy the embedded-engineer part without a product foundation and you get thousands of bespoke deployments requiring indefinite maintenance — services wearing a software costume. The trap is real. But the platform flywheel is the Palantir-specific amplifier, not the universal ingredient. The ingredient is “embed to discover, then build.” Keeping it from sliding into consulting takes a few nameable fixes: a defined end to the engagement, a reporting line into product and never into sales, and treating field work as R&D that feeds the roadmap [15].
“AI will automate the discovery away.” This is the honest frontier, and I do not want to wave it off. If the FDE’s value were purely informational, better models with long context and tool use could compress a lot of it. But the 95% failure rate is not an information problem. It is trust, change management, and institutional politics. An agent cannot navigate a hospital IT department’s turf wars, earn the candor of a reluctant operator, or read the customer who says the prototype is “fine” and means inadequate. The risk is believing the informational gap has closed while the organizational gap stays wide open. The boundary here is genuinely shifting — a frontier to revisit, not a law to carve in stone.
“These are all success stories.” Palantir, John Deere, Databricks, Ramp — exactly the cases a skeptic will name when reaching for survivorship bias, and they would be right to. But the core argument does not rest on the FDE case studies. The 95% failure rate and the $7.2M average sunk cost per abandoned initiative [4] come from enterprise AI programs broadly, not from a controlled FDE-versus-non-FDE comparison. That base rate stands on its own, whichever company you pick to illustrate the alternative. Survivorship bias is a good reason not to treat success cases as proof. It is not a reason to keep building on remote discovery when the base rate for remote discovery is 95% failure.
Embed, Discover, Prototype: What to Do This Week
Those concessions narrow the prescription. They do not dissolve it. You almost certainly have one customer in mind whose workflow you have never actually watched. Start there. The full arc — call it the Forward Deployment Cycle — is five steps.
Embed. Get into the workflow, not the conference room. Interviews give you stated preference; embedding gives you observed behavior. The gap between the two is where products die.
Discover. Map the operational reality, not the idealized process — the edge cases, the data quality, the manual workarounds. The customer’s own diagnosis usually sits one layer above the actual constraint.
Prototype. Build on real data, in the real environment. A single embedded engineer can demonstrate working code on the customer’s real data during the same site visit — which is what earns continued access and keeps the loop viable at startup scale. The new generation of AI prototyping tools, the predecessor in this series, compresses the build loop from sprints to hours. That is what makes the FDE model viable far below what Palantir ever required.
Generalize. Run the weekly “what generalizes?” review — the meeting where the team asks which field discoveries could become reusable platform features rather than one-off tickets, before delivery pressure converts each insight into bespoke backlog. This is the ritual that turns field work into product instead of inventory. It is also how the system becomes the product instead of a pile of one-off deliverables.
Handoff. Transfer ownership to trained internal owners, so the product outlives the relationship.
Skip the whole thing when the workflow is already standardized, or when no sponsor on the customer’s side can act on what you find.
The market is converging on this fast. FDE postings grew 729% year over year through April 2026, with OpenAI, Anthropic, Databricks, Salesforce, Stripe, and Intercom all running the function [6]. OpenAI’s “Deployment Company” raised $4B-plus at a $10B pre-money valuation and acquired roughly 150 FDE engineers in a single move. ServiceNow’s FDE-led POC drove a 13x entitlement expansion on renewal [9]. Whoever spans the two-sided knowledge gap first — clients know their workflows, AI labs know production model behavior, and shipping anything that works needs both — owns the deployment relationship. That is the race, whether or not your roadmap noticed.
So, three concrete moves. Book one week with your best engineer at your most important customer’s site before the next roadmap sprint. Audit which of your initiatives run on curated data without ever touching real workflow dependencies — those are queuing for the failure pile. And check whether your embedding function reports to product or to sales, because that single line decides whether field work becomes discovery or billable services.
The fastest path to a product that works does not run through your roadmap. It runs through the customer’s office.
References
- [1] FDE Academy. How Palantir Invented the Forward Deployed Engineer Model. fde.academy/blog/how-palantir-invented-the-forward-deployed-engineer-model
- [2] MarkTechPost. What is a Forward Deployed Engineer: The AI Role OpenAI, Anthropic, and Google Are Hiring in 2026. marktechpost.com (2026-05-20)
- [4] HST. Why AI Products Fail Without Operational Context: The 95% Problem. hst.ie/blog
- [6] a16z. The Palantirization of Everything. a16z.com/the-palantirization-of-everything
- [8] Databricks. Forward Deployed Engineering: Delivering Business Outcomes with AI. databricks.com/blog
- [9] Constellation Research. Forward Deployed Engineers: Promise and Peril in AI Deployments. constellationr.com/insights
- [11] Medium / Activated Thinker. A Comprehensive Analysis of Palantir’s Forward Deployed Engineering Model. medium.com/activated-thinker
- [13] MindStudio. Palantir’s Forward Deployed Engineer Model Drove 640% Returns — Now Anthropic and OpenAI Are Copying It. mindstudio.ai/blog
- [15] Perspective AI. The Forward Deployed Engineer Playbook: How to Structure, Run, and Scale an FDE Function in 2026. getperspective.ai/blog