NICE Moved Its FDEs Into Go-to-Market. The FDE Org Belongs Under the CPO.

NICE reported on Wednesday, and the forward deployed engineer is in the script. Scott Russell, in his prepared remarks on the call: "Since the end of Q2, we have fully staffed our FDE team, and engagements are ramping significantly." Asked about it later, he described "a pretty significant shift in our go-to-market around use of forward-deployed engineers."

Last Wednesday it was ServiceNow. Gina Mastantuono on the call: "With the help of our Forward Deployed Engineers, we have seen an accelerated time to value of 80% year-to-date." Bill McDermott named the unit: "Our Applied AI FDE team."

And Monday was Palantir, written up yesterday. Alex Karp: "we really cannot satiate demand."

Three public companies, eight days, the same seat in the earnings script. Now the numbers attached to it. Engagements ramping. Time to value. Demand. Every one is a sales number or a delivery number. Not one of the three reported what the field put into the product. That's a tell about where the org sits.

This is part 15 of The FDE Transition, and the first of a new arc about where the FDE org belongs. The answer in one line: it reports to the CPO.

The short version

The reporting line is the scorecard, and the scorecard decides what the field produces. Under sales, bookings. Under services, utilization. Under engineering, a clean harness. All three are things a company wants, and none is the reason to put an engineer inside a customer's building. The reason is that a deployment is the fastest signal a product has about what to build next, and the FDE's real output is a decision about the product: a workflow that should be a feature, an eval the roadmap should be held to, a customer's process that is the design spec. Only the function that owns the roadmap can act on that in hours instead of quarters. In the AI era that function sits under the CPO, with design, product marketing, and the field in one org, because a loop split across four reporting lines can't close fast enough. NICE just moved its FDEs into go-to-market. I think it'll move them again.

What the script measures is where the org reports

A team reports the number its reporting line asked for. That's the whole mechanism.

NICE's FDE line sits in a paragraph about go-to-market, and Beth Gaspich's remarks on the same call put deployment itself with the partners: "increasingly leveraging GSIs and other partners to deploy our platform." So the engineers are sales-side capacity, and their number is engagements. ServiceNow's team is called Applied AI and measured by time to value, a delivery number, and a good one. Palantir's is measured by the conversions Ryan Taylor walked through last week, pilots into deals.

Milos Mandic's survey found the same spread: 24 FDEs reporting into five different places. Antoine Buteau wrote the clearest piece on this in May, and his first line belongs on the wall: "Org design decides what forward deployment becomes." Under sales it becomes deal support. Under customer success, account rescue. Under services, a business of its own. He stops short of naming a winner, "there is no universally correct reporting line," and that's the point I'll disagree with, because the next two years decide it.

Everything a company can measure about an FDE team from the outside is a lagging number. The one leading number, the share of what came back from the field that shipped for every customer, the generalization rate, only shows up on a product scorecard. Anywhere else it has no owner, and a number with no owner is a number nobody reports on a call.

Why not sales, services, or engineering

Sales first, because sales asks first. An FDE closes deals, so the headcount request comes from sales and the engineer lands under a bookings number. Within two quarters the promise is whatever closed the deal and the handback is a liability nobody has time for. NICE's wording is honest about the intent: capacity so customers can "deploy and adopt in a much more faster, agile, and not resource-constrained way." A fine goal for a sales org. Not a product loop.

Services next. A utilization scorecard keeps the engineer on the account, because the account pays. At a hundred FDEs that's the support desk with a field title from part 14, and the economics chapter has what it costs. Lyra Technology Group announced its FDE program on Wednesday, 16 engineers across eight managed service providers, more than 50 by the end of 2027, and made the placement explicit: each engineer belongs to a single MSP, not a centralized shared-services team. Dakota Ferguson's diagnosis is right, "The hardest part of AI isn't the technology. It's the last mile," and Deniz Sagnaklar says the goal is a managed AI practice "that stays in place." For an MSP holding company that's reasonable. It's a services design: the practice stays, the engineer stays, and there's no product on the other end to absorb anything.

Engineering is the harder case, and the org design chapter allowed it. Engineering owns the harness, the codebase contract says what it owes the field, and an engineering leader will hold the bar on what an FDE ships. But engineering's scoreboard is the system: reliability, the cost of a change, whether the rows pass. Right things to count, wrong things to hold the field to, because the field's output isn't a system. It's a decision about what the system should become for everyone. An FDE who reports to engineering brings a finding back to a function whose job is to build what product decided. The finding waits for a roadmap it doesn't own.

Compare Legora. In Basil Chatha's interview on Monday, Jacob Lauritzen describes the company's forward deployed engineers as the people who build the integrations and feed learnings back to the core product, next to about a hundred legal engineers who ship no code. I wrote about the split on Tuesday. The FDE's named output is what goes back into the product. That's a product placement whatever box it's drawn in.

The loop only closes under one roof

This is the argument that runs across all four of these series, and the FDE's piece of it is the simplest. The product outcome in the AI era is a loop: customer, spec, build, story, adoption, back to the customer. Building got cheap. The loop didn't. What decides the outcome now is how fast a thing learned at one customer becomes a spec, a build, a claim, and an adopted workflow at every customer.

The forward deployed engineer sits at both ends of that loop at once, the customer end and the build end. That's why the seat exists, and why part 1 called the FDE the Product Builder arriving from the services side. Design turns the customer's workflow into the spec, the subject of The Design Transition. Product marketing turns deployment proof into the story, and that series made the case that the story is a product surface now. The CPO decides what gets built for everyone. Four functions, one loop.

Put the four under four executives and each reports its own number, and the loop closes in quarters, through planning cycles, if at all. Put them under the CPO and there's one scorecard, and the field finding that arrives on Tuesday is a roadmap decision by Thursday, because the person who reads the handback owns the roadmap. The CPO Transition makes the case from the top. From the field it's just this: the FDE produces the product's fastest input, and the input belongs to whoever owns the output.

I've sat in the CPO seat. The thing you can't buy is a true signal from inside a customer's building the same week. An FDE team that reports to you is that signal with a budget. One that reports to sales is a rumor in the pipeline review.

Three predictions, labeled as mine

First: by the end of 2027, at least one public software company reports a field-to-product number on an earnings call, the share of roadmap items that started in a deployment, or product changes that generalized from field work. The company that does it first will have moved its FDE org under product before it had the number, because the number doesn't exist anywhere else.

Second: the labs' Applied AI teams and the enterprise vendors' FDE teams converge on product leadership within two years. The reason is the next part of this arc. As agents take over the on-site build, the human FDE's remaining output is judgment: what's worth automating, what the customer's process should become, what the product should absorb. Judgment about what to build is a product decision, and the more the build moves to agents, the less the reporting line can stay with the function that measured the build.

Third: the FDE orgs that stay under go-to-market keep reporting engagements and time to value, and they'll be the ones whose FDE headcount per dollar of AI revenue rises instead of falls. NICE reported AI ARR of $392 million, up 46 percent. The number I'd watch over four quarters is how many FDEs that takes.

The decision this quarter

If you're the exec: move the FDE org's reporting line to the CPO before the next planning cycle, and change the scorecard in the same memo. Generalization rate per pod. Roadmap items that started in a deployment, with dates. Days from a field finding to a roadmap decision. Dotted lines to sales for the promise and to engineering for the harness. Perspective AI's playbook from June said "product or engineering, with a dotted line to sales, never the reverse," with a day-90 productization gate. I'd narrow it to product and keep the gate.

If you're the CPO: the org only belongs to you if you read it. Name the product manager who reads every handback packet, and staff the editor's desk before you take the headcount. A field team under a product org that doesn't read the field is a different box on the same chart.

If you're the FDE: find out whose number you're on. If it's bookings, your best finding this year dies in a pipeline review. Write the productization case anyway and send it to the PM who'd own it, by name. Reporting lines change. The habit is yours now.

One thing to try this week: the last three product changes that started in a deployment, with the date the field found it and the date the roadmap decided. Three rows, two columns. Fill it in and you have a product loop, and the chart should say so. If you can't, the FDE org reports to the wrong place, whatever the chart says.

Sources: NICE, Q3 2026 earnings call, with Scott Russell and Beth Gaspich, transcript via Investing.com (November 4, 2026) · ServiceNow, Q3 2026 earnings call, with Bill McDermott and Gina Mastantuono, transcript via Investing.com (October 28, 2026) · Palantir Technologies, Q3 2026 earnings call, with Alex Karp and Ryan Taylor, transcript via Investing.com (November 2, 2026) · Evergreen's Lyra Technology Group, "Evergreen's Lyra Technology Group Invests in AI Talent Across Its MSP Portfolio, Launching Its Forward-Deployed Engineer Program," Business Wire via Yahoo Finance (November 4, 2026), a company release with Dakota Ferguson and Deniz Sagnaklar quoted · Basil Chatha, "Building AI for Lawyers: Jacob Lauritzen, CTO of Legora," Latent Space (November 2, 2026) · Milos Mandic, "State of FDE 2026: The Survey Results," FDE Hub (October 27, 2026) · Antoine Buteau, "Forward-Deployed Company Series #8: Where Forward Deployment Reports" (May 9, 2026) · Perspective AI, "The Forward Deployed Engineer Playbook: How to Structure, Run, and Scale an FDE Function in 2026" (June 12, 2026), a vendor's guide, author unnamed

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 field is where that decision gets its fastest evidence, which is why the field reports to whoever makes it.

Related answer: Should forward deployed engineers report to the CPO?