The Deployment-to-Product Loop: How FDE Work Becomes Roadmap

Palantir's data ingestion tool started as something a forward deployed engineer built on site because one customer's data would not load. Its visualization layer started the same way. Its app builder started the same way. Nabeel Qureshi lists them as examples of a single pattern: an FDE hacks together what one customer needs, a product development engineer takes it back and generalizes it, and it ships to everyone as a Foundry component.

That loop is the entire economic case for forward deployment. Without it, each engagement is a services contract with the margin of one. With it, the customer pays for the first version and every later customer gets it cheaper, which is the only thing that separates the model from consulting. Most companies adopting the FDE title in 2026 have the first half of the loop and not the second, and they are about to find out what that costs.

The short version

The deployment-to-product loop has two halves with two different owners. FDEs build the fast, overfit version for one customer and are measured on that customer's outcome. A product team with the explicit job of generalizing takes what was built, reads the observation records across customers, and turns the third occurrence of the same pattern into a feature or a configuration. The kill discipline is the same as for prototypes: one customer's workaround dies, three customers' identical workaround gets productized. The PM sits at the junction as editor, deciding what earns generalization and writing the eval the generalized version has to pass. When both halves have owners, each deployment makes the next one cheaper. When only the first half does, the company is a consulting firm with a software company's burn.

Half one: build fast, overfit on purpose

The FDE's half is the easy one to staff and the hard one to keep honest.

Qureshi's line for it was that your job was to solve the problem and not worry about overfitting. That is a real instruction, not a shrug. An FDE who tries to build the general solution on site produces something that serves the customer in front of them badly and everyone else not at all. The overfit version ships this week and produces the outcome. Generalizing it is somebody else's job.

What keeps this half honest is the configuration boundary. If the overfit version lives in configuration, it is data the product team can read. If it lives in a fork of the codebase, it is a maintenance obligation nobody will read. The FDE should overfit in configuration and prompts, and reach for code only when the boundary cannot be moved.

Half two: generalize, with an owner

The second half is where the model lives or dies, and it fails for a reason that has nothing to do with skill. Nobody owns it.

FDEs are measured on their customer. Generalizing what they built helps a customer they will never meet and costs time the customer in front of them needs. Product engineers are measured on the roadmap. A deployment learning arrives as an interruption to the thing they committed to this quarter. Both incentives are correct for the people who hold them, and between them the loop starves.

Palantir's answer was to make generalization a job. Product development engineers had it as their explicit charter. Sierra's answer, per Meurer, is to blur the line on purpose: one hiring bar, overlapping teams, shared accountability, so the same person who overfit on site is in the room when it gets generalized. Decagon's answer is that FDE simply is product engineering with the same reporting line.

Pick one. The wrong choice is any structure where generalizing is a nice-to-have.

The kill discipline

Not everything an FDE builds should become product. Most of it should not. One customer's workaround is a workaround. It reflects their legacy system, their politics, their one unreasonable stakeholder. Productizing it puts one customer's accident into everyone's product.

The rule I use is the same one this handbook applies to prototypes: one is an anecdote, two is a coincidence, three is a pattern. When the observation records from three customers show the same configuration solving the same problem with different names, that is the signal to generalize. Below three, the answer is no, and the product team has to be comfortable saying it to an FDE who is proud of what they built.

This is the kill discipline applied to a different input. The backlog of FDE learnings is as dangerous as any other backlog. It grows, nobody reads it, and the act of writing something down substitutes for deciding about it. Read the records, decide, kill or generalize, and do not keep a list.

The PM as editor

Somebody has to sit at the junction. In this handbook I call that person the PM as editor, and the framing was built for reviewing agent output. It applies without modification to deployment output.

The editor does not build. The editor reads what the FDEs built and what the observation records say happened, decides which patterns have earned generalization, and writes the eval the generalized version has to pass. That last part matters. The FDE's eval was written for one customer's data. The product version has to pass on three customers' data, and the PM writes that test before the product engineer starts.

This is the highest-leverage product judgment work available in a forward deployed company, and it is almost never staffed. Most companies have a roadmap process that treats deployment learnings as feature requests, which puts them in a queue behind whatever the sales team promised. The editor role short-circuits the queue: it is a standing decision, made weekly, by someone whose scorecard is what got generalized.

What changes when the building is cheap

The loop was designed when the FDE's artifact was hand-written code. Generalizing meant reverse-engineering what one engineer did under pressure, which is why product development at Palantir was a large and separate team.

When the FDE built with a coding agent, the artifact is different. There is a spec, a prompt, a configuration, and a test that passed. Generalizing means comparing specs across customers, not reading code. Three specs that ask for the same thing in different vocabulary are a pattern you can see in an afternoon.

This is the part of the model that is new in 2026 and it is the reason I think the loop will close faster than it did at Palantir. The observation record and the eval make each deployment legible. Legible deployments are easy to compare. Easy comparison is what the editor needs. The whole loop gets shorter.

It is also, for what it is worth, the loop I am running inside Heidi between what the agents do in one tenant and what changes in the product for all of them, with the difference that the thing being generalized is an agent's behavior rather than a person's build. Same junction. Same editor.

The next chapter takes up the economics, which is where the loop either pays for itself or does not. And the argument underneath, on AI Product Management, is that once building is cheap the scarce work is deciding what gets built for everyone.

Start this week

List the last ten things your deployment or implementation people built for individual customers. For each one, write down how many other customers have the same problem.

Anything at three or more is a feature you have already paid to discover and have not shipped. Anything at one is a workaround, and the honest move is to leave it there. If you cannot answer the question, you do not have an observation record, and that is the thing to build first.

Sources: Nabeel Qureshi, Reflections on Palantir · Natalie Meurer, The Dirty Secret of Forward Deployed Engineering, AI Engineer 2026 · Falk Gottlob, The Sierra Playbook