Absorb Pain, Excrete Product: The FDE Handback

Palantir signed Fujitsu on September 10 as what the release calls a Global FDE Partner. Read that phrase twice. The company that invented forward deployment, and until 2016 employed more FDEs than product engineers, is now paying a Japanese IT company with roughly 100,000 employees to do the deploying. Kevin Kawasaki, Palantir's global head of business development, framed it as bringing Palantir's sovereign AI architecture to Fujitsu's customers across Japan. Trefis's read four days later was blunter: the limiting factor in turning AI into value is the rate of AIP deployment, and putting a partner's engineers into deployment widens the channel that turns a signed contract into revenue.

Fine. Now ask the question this series exists to ask. When a Fujitsu engineer builds the overfit version for a Japanese manufacturer, the supply chain system across 3,000 suppliers and 18 factories that the release says saved over $10 million in a year, what does Palantir's product team get back?

Not the revenue. The learning. That was always the thing that made the FDE model a software business rather than a services business.

Akshay Krishnaswamy, Palantir's chief architect, gave Spencer Dorn at Forbes the best one-line job description I've seen for the role: "The FDE's job is to absorb pain and excrete product." That works when the FDE and the product live in the same company. When a partner absorbs the pain, the excretion needs a pipe. And most companies adopting FDEs this year, partner or not, haven't built one.

This is part 3 of The FDE Transition. Part 2 argued the FDE shortage is a product problem and listed four prerequisites. This part is about the third one, the handback: what an FDE hands to product, when, in what form, and what product owes back.

The short version

The handback is a packet, not a vibe. Four things: the delta between the shipped product and what the customer actually runs, written in configuration terms; the customer's eval rows, the cases that failed on arrival and pass now; the reversals, what the customer turned off or overrode and why; and the count, how many other customers have the same problem. It's delivered at three moments, not at a quarterly retro: two weeks in, at go-live, and at day 60. Product owes back a written decision within two weeks, generalize, keep as configuration, or kill, from a named person, plus the eval the generalized version has to pass. Jeffrey Liu, co-CEO of Assort Health, said it to Dorn without hedging: "Forward-deployed engineering has to make the core product smarter over time." If it only grows headcount and perpetuates customizations, in his telling, it isn't working. The packet and the decision are how you'd know which one you're running.

Why the packet has to be written down now

I've run the product side of this. Deployment people come back from a customer with a story. The story is good. It's told in a meeting, it lands in a Slack channel, somebody says "we should look at that," and then the roadmap sales already promised eats the quarter. The learning was real and it evaporated.

Perspective AI's survey of 1,500 FDEs this spring has the sad version in numbers. Sixty-four percent of respondents describe their dominant work as deploying an existing product into a new customer environment with significant customization. That customization is the delta, and it's the most valuable thing the company learned this month. The same survey found FDEs typing up customer notes into Notion, then into a deal review, then into a research write-up that fed the product team. Three times, by hand, into three formats, none of which is the one a product person can act on. (It's the firm's own survey, so hold the figures loosely. The shape is right.)

The Fujitsu deal makes this worse in an instructive way. A partner's engineer has every incentive to keep the customization inside the partner. That's their margin and their moat. If Palantir wants the learning, the handback has to be a contract term with a format and a date, not a cultural expectation. And I'd argue the same is true inside one company, because an FDE measured on their customer's outcome has the same incentive a partner does. The handback happens when it's specified. Otherwise it doesn't.

Dorn's piece puts FDE job postings up more than 700 percent in a year. Every one of those hires is about to absorb pain. Where it goes is the question.

What goes in the packet

Four things. I'd hold it to one page, and I'd refuse anything that arrives as a narrative.

The delta. What the customer runs that the product didn't ship, in configuration terms: which prompts changed, which rules were added, which tools were wired, which thresholds moved. If the product has the configuration boundary from what has to change in the product before FDEs can work, this is a diff, and the FDE can generate it. If the delta lives in a fork, the packet is a confession that the boundary is in the wrong place. That's useful too.

The eval rows. The customer's cases that failed on day one and pass now, as rows the product team can run. Not "accuracy improved." The rows. This is the part of the packet that survives the FDE leaving, and it's the part that lets a product engineer generalize without re-interviewing the customer. Jina Yoon's PostHog explainer has the example of it working: OpenAI's FDEs built evals with a call center customer, took them back to the research team, and the Realtime API got better for everyone who never met that customer.

The reversals. What the customer turned off, overrode, or quietly stopped using, and the FDE's best guess why. Reversals are where the product's assumptions meet the customer's actual workflow, and they're the thing nobody volunteers. I want them more than I want the wins.

The count. How many other customers, by name, have the same problem this delta solves. The FDE usually knows. One is a workaround. Three is a feature the company has already paid to discover. The count is what turns the packet from a feature request into a decision, and it's the input the deployment-to-product loop runs on.

That's it. No deck, no retro, no section called learnings.

When it's due

Three moments, because the learning has a different shape at each one.

Two weeks in: the landing note. What the sales promise didn't cover, what the customer expected that the product doesn't do, and what the FDE is going to build to close the gap. This one goes to sales as much as to product, and it's the raw material for a later part of this series on who owns the promise.

Go-live: the full packet. Delta, rows, reversals, count. This is the one that carries the most, and it's due the week the customer starts running on the thing. Not a month later, when the FDE is already at the next site and the details have blurred.

Day 60: the reversal update. What held and what the customer undid once the FDE stopped watching. This is the one that tells product whether the delta was real or whether the FDE's presence was holding the workflow together. It's also the handoff to customer success, which gets its own part.

If your FDEs are on site three or four days a week the way Nabeel Qureshi describes the Palantir version, three one-page deliveries over two months is not a burden. It's less writing than they're already doing into Notion.

What product owes back

This is the half everyone skips, and it's the half that decides whether the packets keep coming.

A name. One product person owns the handback for a given product area, reads every packet, and is measured on what got generalized. The handbook calls this the PM as editor, and it applies here without modification. If the packet goes to a team alias, it went nowhere.

A decision, in writing, within two weeks. Three options: generalize, keep as configuration, or kill. "We'll consider it" is not one of the options. The FDE who sent the packet gets the decision and the reason, because an FDE who sends three packets into silence sends the fourth into Slack and the fifth nowhere.

The eval the generalized version has to pass. When the decision is generalize, the editor writes the test before the product engineer starts, and it has to pass on the rows from every customer in the count, not just the one who sent the packet. That's the difference between shipping one customer's accident to everyone and shipping a feature.

And for partner FDEs, one more thing. The same packet, the same channel, the same decision window, written into the partner agreement, with the customer's eval rows and configuration belonging to the customer and portable. Otherwise the vendor is paying a partner to learn things about its own product that the partner will keep. I'd want that clause if I were Palantir. I'd want it more if I were the Japanese manufacturer, for the reasons in the economics chapter.

What this means in the seat

If you're the FDE, the packet is your leverage. It's how your work at one customer becomes a line in the product that carries your name, which is the whole career case for the role and the subject of a later part. Send it whether or not anyone asked. Then count how many decisions come back. Zero after three packets tells you what kind of company you're in.

If you're the product leader, the handback is the cheapest research program you'll ever run, and you're probably paying for it already and throwing the results away. Name the editor this week.

One thing to try this week: take the last deployment that went live. Write the delta on one page in configuration terms, count the other customers with the same problem, and send it to a named product person with a decision date two weeks out. If you can't name the person, you've found the hole. If you can, you've started the loop.

Sources: Palantir Technologies and Fujitsu, "Palantir and Fujitsu Deepen Partnership to Advance Enterprise AI Transformation, with Fujitsu Strengthening as a Global FDE Partner," Business Wire via Yahoo Finance (September 10, 2026), with Kevin Kawasaki quoted · Spencer Dorn, "Why Forward-Deployed Engineers Are Spreading Into Healthcare," Forbes (September 2, 2026, updated September 8), with Akshay Krishnaswamy and Jeffrey Liu quoted · Trefis Team, "Can Palantir Deploy Fast Enough To Move Its Stock Higher?", Trefis (September 14, 2026) · Perspective AI, "State of Forward Deployed Engineering 2026: Survey of 1,500 FDEs" (May 18, 2026) · Jina Yoon, "WTF is a forward deployed engineer? (and why everyone is hiring them)," PostHog (February 11, 2026) · Nabeel Qureshi, Reflections on Palantir

Part of the running argument on AI Product Management: once building is cheap, the scarce work is deciding what gets built for everyone, and the handback is where that decision gets its inputs.

Related answer: What does a forward deployed engineer hand back to product?