Before You Build an FDE Function

The Forward Deployed Engineer role is showing up everywhere right now. I'm hearing a lot of SaaS CROs ask for the function, and if you're a Solutions leader, there's a real chance someone on your executive team is already asking whether your company needs one.

Most companies will build it before answering the one question that decides whether it works.

Maybe the CRO saw newer AI companies having success with FDEs. Maybe the CEO feels like the company isn't "in the game" without them. Maybe Product wants stronger signal and faster feedback from the field. Maybe Services wants more technical depth in key account deployments. All of that may be valid.

The part that gets skipped is alignment. If you're being asked to add an FDE function, make sure your executive team agrees on how each role in the GTM function will operate with FDEs.

Get executive alignment and clear rules of engagement before you build the function.

The FDE role is not new, but the urgency is

The FDE role was originally created by Palantir two decades ago. At the time, they were doing something new that required someone onsite at secure government locations. The role made sense because the work demanded deep technical skill, customer proximity, and the ability to solve specific problems inside the customer's environment.

Today, AI has created a similar requirement. It still involves building something custom to solve a particular business problem. Customers want to see AI work with their data, in their own environment. And now the pressure is coming from tool consolidation and the need to prove value faster.

That pressure is real, and the data backs it up. According to the LogicMonitor 2026 Observability & AI Outlook for IT Leaders Research Report, 84% of organizations are pursuing or considering tool consolidation, and 41% are actively consolidating. Another 43% are evaluating their tech stack, and 63% have an AI initiative that is a top strategic focus.

That puts a tremendous amount of pressure on traditional SaaS companies — especially the ones that added AI as a feature or bolt-on to an existing product.

There's another reason demand is spiking: pilots are stalling. Too many enterprise AI pilots never reach production. They stall out in vague scope, shifting success criteria, and no single person accountable for getting from demo to deployed. This is where the FDE becomes an operating wedge. Embedded in the customer's environment, they turn a fuzzy pilot into a measurable, in-production outcome — which is exactly what an executive staring at a stuck initiative wants to see.

Here's the upside. If you have a high-value individual onsite or dedicated to a customer, ensuring their success and outcomes are met, that can be a huge competitive advantage. This, in my opinion, is why so many SaaS CROs are asking for the function.

I'm a huge fan of the FDE function. I've led pre- and post-sales Solutions teams where we owned the end-to-end customer journey, excluding customer support. I've developed and deployed new services based on customer needs. So I completely love seeing FDE functions done well.

Two main types of FDEs

Part of the confusion is that companies are using the same title for different work. I see two main types of FDEs in the field today.

1. The AI-savvy engineer. The first type is an AI-savvy engineer who is an expert in frontier models, extensibility, and moving across systems. These are adaptable, elite builders who bridge the gap between the power of AI and the realities of messy enterprise systems.

They usually have experience as software engineers using Python or other production-grade code, and they're important to making sure an AI deployment at an enterprise account is successful. They work closely with AI product and engineering teams so customer use cases get communicated back internally. But they also build whatever is needed for that specific customer on the fly. They're a blend of software engineer, systems architect, and customer consultant.

These FDEs often sit in AI Product or AI Engineering. I've also seen them sit in GTM under a Solutions or Services executive.

2. The technical customer generalist. The second type is more of a generalist. They're stronger on the customer consulting side than the AI engineering side, but they're still technical. They understand frontier AI models, extensibility, solutions architecture, systems architecture, workflow design, and how what they're implementing affects the entire company.

Most of all, they're resourceful. It doesn't matter what they run into — they'll pull in the right resources to make sure the customer's AI deployment is successful. These FDEs are more likely to sit under the CRO or Solutions executive in GTM.

Both types need defined success criteria so the customer's desired outcome is well documented and success is measurable. That part cannot be skipped.

What are we trying to accomplish with this role?

This is the first question I encourage Solutions executives to ask. A CRO or other executive may say, "We need an FDE team." But before you design the function, ask for the real story. What's their true why?

Are we trying to improve AI deployment success? Win more strategic accounts? Protect renewals and prevent being thrown out during a customer's tool consolidation and AI transformation effort? Compete with newer AI companies? Create stronger product feedback because we're launching an AI product and need use cases, success in the field, and a faster feedback loop to AI engineering? Give Sales more technical support? Create seamless experiences so customers have one technical deployment consultant from value creation to value realization?

Or are we reacting to a title that's getting attention in the market and simply want the same competitive edge?

In some cases, the current Solutions team is already doing nearly all of what the executive wants. Not always, but sometimes it's just a matter of renaming the SE function to FDE because they're already handling the deployment and the executive doesn't have visibility into that. I've been surprised how often that comes up in traditional SaaS over the past six months.

Do not build an FDE function without rules of engagement

The FDE role is highly cross-functional. That's what makes it so powerful — and it's also what makes it messy for companies adding the function to a traditional structure with siloed Solutions, Services, and Customer Success teams.

If you don't define desired touchpoints with your customer across your internal team, and get executive buy-in to operate that way, the FDE role can quickly become a catch-all. Before you build the team, get clear on the reason why and define role-specific expectations that can be clearly communicated.

• When does an FDE get involved
• What does the SE/SC own
• What does Services own
• What does Product own
• What does Customer Success (if present) own
• How will success be measured
• How will customer outcomes be documented
• What becomes product feedback
• What becomes paid services
• What work the company will not do for free

This is where executive alignment matters. If Sales, Solutions, Services, Product, and Engineering all have different expectations, the FDE will get pulled in every direction. The customer will feel that confusion. So will your team.

Final thought

The FDE function can be a real competitive advantage. I don't think there's ever been a better time to be a Solutions professional or FDE — if you can adapt, take on new challenges, and solve problems.

If you're being asked to build this function, don't skip the hard questions:

• What is the real reason we want this function?
• What type of FDE do we need?
• Where should the role sit?
• How will it work with the rest of GTM?
• What outcomes are we accountable for?
• What are the rules of engagement?

Get those answers first, and you'll build a stronger bridge between AI, customer outcomes, and the realities of enterprise execution.