What Has to Change in the Product Before FDEs Can Work

There is a version of the forward deployed model that is just a consulting firm with a software company's cost structure. The company hires excellent engineers, sends them into customers, and each one builds something clever and bespoke. Two years later the company maintains forty custom systems, the product has learned nothing from any of them, and gross margin looks like Accenture's.

The difference between that and Palantir is not the quality of the engineers. It is that Palantir had a product underneath the engineers that was built to absorb what they made. Kevin Bai, who did the role at Palantir and now works on it at Anthropic, calls this the platform prerequisite. I would put it more bluntly. If you send FDEs into customers before changing the product, you have not adopted a deployment model. You have started a services business by accident.

The short version

Five things have to be true in the product before the first FDE lands. There must be a configuration boundary, a deliberate line between what an FDE can change per customer without code and what needs the product team, and most customer-specific work has to land on the configuration side. There must be a per-customer sandbox with guardrails, so the FDE builds outcomes instead of environments. There must be an eval harness, because the executable definition of the outcome is the contract the FDE works to and the thing outcome pricing bills against. There must be an observation record per customer, because an FDE who cannot explain why the number moved cannot own it. And there must be a feedback path from deployment to roadmap that has an owner, or the loop that made Palantir's model compound never closes. All five are product work. None of them are the FDE's job to build.

One: the configuration boundary

Every deployment has customer-specific logic. The approval that routes differently in one region. The field that means something else in this customer's CRM. The prompt that needs their vocabulary. The question is where that logic lives.

If it lives in code, the FDE forks the product for each customer, and the product team inherits forty forks. If it lives in configuration, the FDE changes a setting, the product stays one product, and the setting itself becomes data the product team can read across customers.

The boundary has to be drawn on purpose. It is the same argument this handbook makes in substrate-first engineering: engineering invests in the thing that lets everyone else ship safely, not in features. For a forward deployed model, the substrate is the configuration surface. The test is simple. Take the last three things an FDE did for a customer. If any of them required a pull request to the core product, the boundary is in the wrong place, and the fix is a product change, not a better FDE.

Sierra's move of workflow building into a no-code studio is this boundary being pushed outward. Every workflow that used to need an agent engineer's code is now a configuration the customer or the FDE can change. That is the last mile being productized from the inside, and it is the whole answer to the objection that forward deployment does not scale.

Two: the sandbox

An FDE's first month at a customer is either spent on the outcome or spent building an environment. Which one depends entirely on what the product provides.

The sandbox needs to mirror the customer's data shapes and integrations closely enough that what works there works in production. It needs guardrails that make it impossible to write to the customer's live system by accident or to run up a model bill nobody approved. It needs isolated deploys, so a mistake affects one customer's sandbox and nothing else.

This is the same substrate a Product Builder needs to prototype safely, applied per customer. If your product team has already built it for internal builders, the FDE version is an extension. If not, the FDE will build it themselves, badly, for one customer, and the next FDE will build it again.

Three: the eval harness

The most important sentence in this chapter is that the eval is the contract.

Before an FDE builds anything, they and the customer agree on what the outcome looks like as an executable test on the customer's real data. Resolution rate above a threshold on a held-out sample of last month's tickets. Correct routing on a hundred real approvals. Whatever the outcome is, written as something that passes or fails. The deployment ships when it passes.

This does three things at once. It stops the definition of done from being negotiated by feel, which is where deployments stall. It gives outcome pricing something to bill against, because the metric on the invoice is the metric in the test. And it makes the FDE's work legible to the product team, because a test that passed on customer A's data is a test the product team can run on customer B's.

I wrote the general case in the eval is the spec. For forward deployment, the eval is also the statement of work.

Four: the observation record

An FDE is accountable for an outcome. To be accountable for a number you have to be able to explain why it moved. That requires a record, per customer, of what the system did: which actions ran, which a human reversed and how fast, which got escalated, which rule fired, and how each outcome closed against the decision that produced it.

Without that record the FDE is guessing. The resolution rate dropped, and the answer to why is a week of log-diving in the customer's systems. With it, the answer is a query.

The record also matters for the product. Forty customers' observation records, read together, show which per-customer configurations are the same pattern with different names. That is what the product team generalizes. The deployment-to-product loop does not work without it, and I would argue it is the most underbuilt of the five, because it is invisible in a demo.

In Heidi every act carries a receipt and every outcome gets labeled against the decision that triggered it. I built that for the guard layer, so an agent's autonomy could be gated on evidence. It turns out to be exactly what a person accountable for a tenant's outcome needs as well, and I did not see that coming.

Five: the feedback path with an owner

Palantir's loop worked because product development engineers had an explicit job: take what the FDEs built and generalize it. That job had owners. It was not a suggestion box.

The equivalent in your company is a person on the product team whose scorecard includes how many per-customer configurations became product features this quarter, and a cadence where FDEs bring what they built. Without that owner, the observations pile up and nothing generalizes, and you are back to forty forks. With it, each deployment makes the next one cheaper, which is the only reason the economics of the model work.

The order matters

Do the configuration boundary first, because it determines whether anything else compounds. Then the sandbox and the eval harness, which are the same investment as making your own product team faster and can be built together. Then the observation record. Then name the owner of the feedback path.

Then hire the first FDE. Not before. An FDE who lands on a product without these five will produce a heroic deployment for one customer and a maintenance burden for everyone else, and it will look like the model failed when the product did.

This wave is part of the running argument on AI Product Management: the role is defined by what one person can own once building is cheap, and what one person can own depends on what the product lets them.

Start this week

Take the last thing an FDE, an implementation engineer, or a solutions person built for a single customer. Ask one question about it: did it require a change to the core product's code?

If yes, that is the configuration boundary in the wrong place, and moving it is the highest-return product work available to you this quarter.

Sources: Kevin Bai, FDE 101 and the platform prerequisite, AI Engineer 2026 (via the Sierra talk series summary) · Nabeel Qureshi, Reflections on Palantir · Falk Gottlob, The Sierra Playbook