Why AI Companies Are Betting Big on Forward Deployed Engineers

And what the critics get wrong about the role.

A fellow FDE told me something that stuck.

I asked him how it pays off for his company that he’s been working on a single customer for six months when their ARR is a third of his salary. The math doesn’t work. Everyone can see that.

His response: “In hindsight, if it wasn’t for this customer, we would have built a completely different product. By now we would have been lost.”

Then he said something that reframed everything for me.

“We would have done it for free just for the learning.”

That’s the part most people miss when they dismiss FDEs as “glorified consultants” or argue that the model doesn’t scale.

They’re right that it doesn’t scale. They’re wrong about what it is

The Criticism That Misses the Point

The FDE role has exploded. I wrote about the 800% growth a few months ago. And with that growth comes skepticism.

“It’s just consulting with a fancy title.”

“You can’t build a business on high-touch deployments.”

“It doesn’t scale.”

All true. And all beside the point.

FDE teams aren’t a business model. They’re an investment.

The companies hiring FDEs aren’t confused about the economics. They know an FDE costs more than they bring in through the customers they serve. That’s not a bug. That’s the deal.

What You’re Actually Buying

Here’s the problem AI companies face right now.

It’s easier than ever to build. The tools are incredible. You can ship features in days that would have taken months a few years ago.

But it’s harder than ever to figure out what needs to be built.

AI is general-purpose technology. That’s its power and its curse. An LLM can do a thousand things. But which thousand things does your customer actually need? Which ten things? Which one thing that will make them renew?

Traditional product discovery doesn’t work well here. Customer interviews tell you what people think they want, not what will actually transform their workflow. Shipping and seeing what sticks is expensive and slow. Guesswork is... guesswork.

FDEs are a different approach. You embed someone in the customer’s environment. They see the real workflows, the real constraints, the real edge cases. They discover what the product should be by building it with the customer, not for them.

You’re buying product insights with people instead of guesswork.

The Bubble Problem

There’s something else going on that’s easy to forget when you’re deep in this world.

We’re in a bubble.

My readers, my fellow FDEs, the founders I talk to - we think everyone understands AI. We assume businesses know what’s possible. We talk about agents and RAG pipelines and autonomous workflows like these are obvious concepts.

They’re not.

Step outside the bubble and you find companies that are still discovering ChatGPT. Smart people running real businesses who feel pressure to use AI but have no idea how. They don’t lack capability. They lack imagination. They can’t see the possibilities because they’ve never seen them applied to problems like theirs.

This is where FDEs come in.

We’re not just implementing solutions. We’re showing customers what’s possible. We’re translating between what AI can do and what their business actually needs. That translation doesn’t exist in documentation or demos. It happens in the messy reality of their operations.

From Feature Requests to Primitives

The real value isn’t the individual customer deployment. It’s what gets fed back into the product.

Every FDE engagement generates feature requests. Most of them are specific to that customer’s weird edge cases. But some of them reveal patterns.

When a bunch of little requests form a theme, you’re onto something. That theme can become a primitive: a powerful, robust feature that solves the underlying problem for future customers too.

The goal is that each deployment makes the next one faster. Each customer teaches you something that benefits everyone who comes after. With enough of these learnings, future customers won’t need as much hand-holding. The product gets robust enough to stand on its own.

I wrote before about the unknown unknowns problem - how we can’t fully automate because we can’t detect when AI is wrong. And about how AI projects never feel “done” because scope keeps revealing itself. Both of those are discovery problems. FDE work is how you solve them.

The Trap: Becoming a Master of None

There’s a risk to this approach.

When you’re embedded with customers, you see every problem. Every workflow. Every edge case. And you want to solve them all.

The temptation is to add everything to the product. This customer needs a custom approval flow. That customer needs a specific integration. Another one needs a reporting format nobody else uses.

Say yes to all of it and you end up with a bloated product that does everything and nothing well. A master of none.

The key to growth is saying yes. The key to scale is knowing when to say no.

Every feature request needs to pass a filter: will this bring future customers to value faster, or is it just covering this one customer’s edge case? The first type becomes a primitive. The second type stays a custom implementation or gets declined entirely.

This is hard. When you’re in the room with a customer and they’re telling you this one feature is crucial for them, saying no feels like losing. But you’re not building for one customer. You’re building for the next hundred.

When the Math Starts Working

Some companies do make FDE a scalable business model. Palantir. OpenAI. A few others.

What’s different about them?

ARR per customer.

Their products are complex enough and their customers large enough that million-dollar contracts are normal. At that scale, dedicating an FDE to a single account can make economic sense.

But they also had to build those products first. Their early FDE work wasn’t profitable either. It was investment. The product became robust enough over time that smaller customers could use it without hand-holding. FDEs could focus on the largest, most complex deployments where the math actually works.

That’s the trajectory. FDE as investment, then FDE as business model. But only after the product has absorbed enough learnings to stand on its own.

The Bottom Line

If you’re a founder considering an FDE team: know what you’re buying. You’re not buying revenue. You’re buying discovery. The ROI is measured in product insights, not customer ARR.

If you’re evaluating a company with FDEs: don’t dismiss them because the math doesn’t work per-customer. Ask what they’re learning. Ask how those learnings are changing the product. That’s where the value is.

If you’re an FDE: your job isn’t just to make your current customer successful. It’s to make every future customer more likely to succeed. The feature requests you bring back, the patterns you identify, the primitives you help create. That’s your real impact.

The critics are right that it doesn’t scale.

They’re wrong that it needs to.