Part Three · Action
Chapter 9
What Really Changes Is the Delivery Contract
The change of the FDE is not just a new job description, but a delivery contract that shifts from functional acceptance to production adoption and business outcomes — along with the team responsibilities that come with it.
Software projects have a highly ceremonial moment: go-live.
Celebrations in the group chat, group photos of the project team, executives thanking both sides. The people who have been busy for months can finally breathe a sigh of relief.
Go-live certainly matters. Until something is in production, everything before it is just preparation.
But from the perspective of customer value, go-live is only the moment the system first becomes eligible to be tested.
Will users actually use it? Will processes change? Can the model still work when it encounters real data? Who picks up the pieces when something goes wrong? None of these reveal their true face until after go-live.
Traditional projects treat go-live as the endpoint, and there are contractual and organizational reasons for that. If the FDE merely pushes the endpoint back a few weeks without changing how success is measured, it's just a longer delivery.
The new contract has to answer: what exactly has to happen for the project to be considered complete?
From "It Runs" to "People Use It"
The easiest thing for a prototype to prove is that it runs.
Give it a set of sample data, and the model identifies the fields; type in a question, and the system generates an answer; click a button, and the workflow completes. The client gets excited, because an abstract capability finally has a picture.
The problem is that every step of the demo is being watched over by someone.
The data was cleaned in advance, anomalies don't appear at the same time, permissions have already been granted, and if the model answers wrong, you can just try again. In production, users don't live by the demo script.
The first gate is not accuracy — it's adoption.
Is the operator willing to hand their work over to the system? Do they still need to maintain the old process alongside it? Will a ten-second delay make them give up? When an error occurs, do they know who to turn to?
OpenAI's FDE job description writes "production adoption" and "measurable workflow impact" directly into its success criteria. Rather than how many models were deployed, it cares more about whether the workflow has actually changed.
A system that gets opened a hundred times a day, but only lets users copy results back into Excel, may still be a case of fake adoption. Usage only proves that someone clicked; on its own, it doesn't prove value.
The Minimum Viable Deployment, Not a Prettier POC
A proof of concept answers "is this technically possible."
A minimum viable deployment answers "in the real environment, is this worth continuing."
Both can look small; the difference lies in the constraints.
A minimum viable deployment must at least touch real — or close enough to real — data, enter an actual workflow, have clearly defined users, and agree in advance on an outcome metric. It doesn't have to carry full production traffic, but it can't just be a performance in a conference room.
Palantir once summarized its AIP Bootcamp as going from zero to a use case in five days or less. The speed is appealing, but "five days" isn't magic. The value of a short cycle is that it forces both sides to pick just one sufficiently concrete problem and test it on the spot with real data and workflows, leaving no room for a grand platform project to stretch on indefinitely.
Speed isn't about writing less code — it's about getting objections earlier.
The user says this step would never be done that way; the security team says this permission can't be granted; the moment the data is connected, three systems turn out to contradict each other. The earlier these "bad news" items surface, the more money the project saves.
Agree on the Referee Before the Game Starts
Enterprise AI projects most easily fall into vague goals:
Improve efficiency, enhance experience, empower decision-making, increase intelligence levels.
These phrases are fine for project proposals, but useless for value acceptance.
A concrete project must at least separate three types of metrics.
The first type is system metrics: accuracy, latency, stability, cost per call.
The second type is work metrics: processing time, proportion of manual review, backlog size, first-pass rate.
The third type is business outcomes: how much loss avoided, how much revenue gained, how much risk reduced, whether the customer renews.
None of the three can substitute for the others.
Higher model accuracy doesn't guarantee shorter work time; shorter work time doesn't guarantee the company saves money. If a role saves two hours a day but the person still has to be on standby the whole time, the financial savings may not materialize immediately.
So before the project starts, agree on the referee: which numbers to look at, what the baseline is, how long the evaluation period is, and who confirms the results.
A pilot without a referee is the most likely to stay forever in the state of "just optimize a bit more and it'll be valuable."
Daring to Say "It's Not Worth Doing"
Traditional vendors find it hard to refuse a request that comes with a budget.
If the client is willing to pay, the project generates revenue. Whether the benefits exceed the costs is usually left to the client's own business judgment.
If the FDE claims to be accountable for outcomes, it can't hide entirely behind that boundary.
Some processes happen only a few dozen times a year, and the cost of building the automation will never be recovered; some tasks are time-consuming but require humans to carry relationships and judgment, and forcing AI into them only adds review work; some problems are rooted in broken institutional design, and the model can only make the wrong system execute faster.
In these cases, the most valuable deliverable may be a single sentence: "It's not worth doing."
Saying this isn't romantic. It may shrink the contract, or even end the project. But if the FDE is only responsible for proving that AI can do everything, we're back to selling features.
Judging whether something is worth doing requires putting the technical ledger and the business ledger side by side:
How much does it cost to build, how much to run, how large is the cost of errors, whether the savings will actually show up in the financial statements, whether the growth is actually attributable to the system.
Technology is the entry ticket; the math decides whether there's a next round.
Accountability for Outcomes Doesn't Mean Promising Every Outcome
"Pay for performance" sounds most aligned with the FDE spirit.
The system recovers an extra million yuan, and the vendor takes a share; charge per customer session resolved. Price is tied directly to value, and the two sides' goals seem perfectly aligned.
In reality, outcomes are usually determined by many factors together.
Sales growth may come from market conditions; falling bad debt may be due to a changed customer mix; customer service satisfaction is also affected by logistics and product quality. If the vendor cannot control the key variables but promises the final outcome, the contract becomes an argument over attribution.
So accountability for outcomes doesn't mean taking over all of the enterprise's business risk.
A more workable approach is layered commitments.
Take clear responsibility for the system and workflow metrics you can control; set joint goals and track attribution for business outcomes; and when conditions are mature, tie a portion of the fees to results.
Chinese enterprises' procurement habits, budget categories, and acceptance processes also mean not every client can jump straight to pure outcome-based pricing. Staged acceptance and value metrics can coexist; there's no need to reject project management just to appear advanced.
When the Delivery Ends, Three Things Should Remain
When an FDE project ends, at least three types of results should remain.
On the client side, work has changed in observable ways. Users have genuinely adopted it, the risk boundaries are clear, and business metrics have before-and-after comparisons.
On the product side, field experience has been distilled into reusable capabilities. Connectors, eval sets, business objects, control rules, or delivery playbooks — things that can be used next time.
On the relationship side, both sides know whether to expand, maintain, or stop next. Not based on "the client feels good about it," but supported by data and shared experience.
If only code remains, the project is still fragile.
If only the client relationship remains, the service depends on individuals.
If there's only a set of pretty metrics but no reusable capability, the team starts from scratch at the next client.
The FDE delivery contract is heavier than a traditional project's precisely because it touches all three of these sides at once.
At this point in Part Three, the answer can be stated more clearly.
What's new about AI is not just that it can generate content, but that it has begun to participate in action; what's new about the FDE is not just the blending of capabilities, but that responsibility no longer stops easily at go-live; what's new about delivery is not just a shorter cycle, but that value must be proven through production adoption, workflow impact, and reusable feedback.
But once you're ready to do this, how much can past experience in data modeling and governance still help?
In the next part, we take out the old tools again and see which ones are still sharp, and which are no longer enough.
References for This Chapter
- OpenAI: Forward Deployed Engineer job description
- Palantir 2023 Q3 Business Update: AIP Bootcamp
- Fan Bing: Forward Deployed Engineers: The Secret to Delivering Customer Value in the Age of AI
Scenario note: The go-live, adoption, and metrics design scenarios in this chapter are composite situations drawn from enterprise software delivery.
This page is synced with the chapter Markdown on GitHub. Corrections are welcome.