The FDE Model: Silicon Valley's New Craze—Does It Fail to Take Root in China?

Learn

Events

Zones

Communities

Tools

Articles/Answers/Technical Experts

Publish

Cao Jiang

Published on 2026-01-16 11:46:30

Recently, whether in the industry or in my reader groups, everyone has been discussing the same thing: Palantir, OpenAI, and many Silicon Valley startups are hiring FDEs (Forward Deployed Engineers) on a large scale. The job title FDE is still unfamiliar to many people, but in Silicon Valley it has already become one of the hottest topics. According to YC's statistics, more than 100 YC startups are currently hiring for FDE-related roles, while three years ago that number was 0.

What does this change actually mean? Is the FDE model viable in China? In this article, drawing on my more than ten years of experience in the 2B software field, I'll share my thoughts on this topic.

PART01

What Is the FDE Model

01. What Does an FDE Actually Do

Simply put, an FDE is a technical person who is stationed at the customer's site to bridge the gap between product capabilities and customer needs.

This may sound no different from traditional on-site development, but it is fundamentally quite different. The core is the difference between passive and active. Traditional on-site work is often passive "customization on demand"—whatever the customer asks for is what gets built. The goal of an FDE, however, is to proactively deliver valuable outcomes for the customer, not just software or services.

Let me illustrate with Palantir's example. When Palantir was first founded, the company's focus was building software systems for intelligence agencies. The challenge was that they barely knew anyone working in intelligence, and even if they found such a person, that person couldn't possibly tell them the details of their work.

What to do? Palantir's approach was to first build a demo, then show it to potential customers and gather feedback. One of the founders, Stefan Cohen, did exactly this: he showed the demo to potential customers and asked, "What do you think?" They replied, "This product is terrible—it has nothing to do with what we do." Cohen kept asking, "Then how would you want it to be different?" and wrote down all the feedback, then went back to improve it.

This process was repeated over and over until the product could genuinely solve the customer's problems.

02. How the FDE Team Operates

At Palantir, the FDE team consists of two core roles:

The Echo team: They are embedded analysts who go to the customer's site, talk with users, deeply immerse themselves in the customer's business, and figure out what kind of demo or use case would be truly valuable for that scenario. At the same time, they also serve as account managers, responsible for managing customer relationships.

The Delta team: They are deployment engineers—essentially software engineers. These people are usually extremely good at writing code quickly; they are the ones who turn ideas into actually running products.

All of this is done within a very short time. The FDE team comes in with an idea for a project, sets a demo for leadership a few months later, and if the demo goes well, it gets truly deployed across the customer's entire organization.

03. FDE Is Not Consulting, but Product Exploration

Many people will say: "Isn't this just consulting?" But FDE and consulting are fundamentally different.

Shyam Sankar, an early member of Palantir, offered a key insight: rather than building a separate version for each customer, or adding a pile of features that only apply to specific customers, it's better to make the product a highly customizable platform.

The FDE approach is: come in with the existing product, fill the gap between product capabilities and actual needs, and first lay the route as a "gravel road." Then, the product and engineering teams at headquarters abstract and generalize these on-site practices, paving them into a "paved superhighway" that can serve the next 5 to 10 customers.

This is why FDE is not consulting, but a process of product exploration. FDE conducts product exploration from inside the enterprise, rather than talking with customers from the outside.

From a business model perspective, a key trend at Palantir is: when they go to a new customer to deploy a new project, they may be losing money at first, but over time, as the product becomes better suited to that customer's needs through continuous product exploration, delivery costs gradually decline, and the overall margin on that customer turns from negative to positive. This process may take a year, or it may take several years.

This is the essential difference between the FDE model and consulting: consulting is a one-off project, while FDE is product exploration that can scale.

04. Palantir Ontology: The Key to Moving from Customization to a Platform

One key to Palantir making the FDE model work is that they invented a series of methodologies, along with the platforms that correspond to those methodologies.

Take Ontology, which I introduced in my previous article (From Palantir Ontology to Sensors SDAF Closed Loop: Two Paths to Implementing Data-Driven Decision Loops), as an example:

Initially, when Palantir was working for the US government and intelligence agencies, the instinctive approach was: create one table for "people," another table for "funds"... But they quickly discovered that once they needed to deploy across different agencies and customers, they ran into the problem of lack of generality.

So they raised the level of abstraction, no longer presupposing specific object types, and instead let FDEs define things according to each customer's context. The underlying layer only provides generic concepts such as objects, properties, and links. Palantir Ontology was born out of this line of thinking.

The database schema itself is extremely generic, retaining only: objects, properties, media, and links between objects. As for the specific semantics in each customer's scenario, those are encoded by the Ontology.

This approach not only improved delivery efficiency, but also allowed Palantir's product to evolve from a customization tool into today's four core platforms: Gotham, Foundry, Apollo, and AIP. From Palantir's latest annual report, we can see that the gross margin for fiscal year 2024 was as high as 80%, which means its software business has achieved economies of scale.

PART02

Will It Struggle to Take Root in China

01. The Prevailing View in China

There is a prevailing view in the industry that FDE is nothing new—it's essentially the on-site staffing model commonly seen at Chinese custom development companies, except that the so-called FDE is supposed to understand the customer's business better, understand AI better, and understand the product better.

More importantly, many people believe this model is not sustainable in China. The main reasons are as follows:

First, insufficient profit margins. The profits of domestic 2B projects are not high enough to attract top talent to do on-site work, and cannot support the high salaries of excellent talent.

Palantir's new FDEs earn total compensation of $200,000–$250,000, and senior positions can reach $300,000–$450,000. Translated to China, that corresponds to a package of over 1 million RMB. But the deal sizes and profit margins of domestic 2B projects can hardly support that salary level.

Second, talent doesn't want to do on-site work. The top career choice for excellent engineers is definitely the big internet companies represented by ByteDance. And even if they choose the 2B software industry, they would surely prioritize product R&D, and only consider on-site development as a last resort. After all, on-site work is harder, more exhausting, and more stressful, and domestic client-side customers indeed don't show much respect for vendors' on-site staff.

Third, the promotion mechanism is flawed. In traditional 2B companies, doing well in on-site work often leads to promotion—from "charging" on the front line to "commanding" from a back-office position. As a result, the most experienced people end up leaving the front line, which is precisely contrary to the original intent of the FDE model.

Fourth, insufficient product abstraction capability. Palantir's success is largely due to methodologies and platforms like Ontology, which allow them to distill the lessons from each on-site engagement into reusable product capabilities. But many domestic companies lack this product abstraction capability and easily fall into the trap of "one-off custom development." Every customer requires starting from scratch, and the "gravel road" can never be upgraded into a "highway."

Fifth, mismatch between organizational culture and incentive mechanisms. FDEs need a high degree of autonomy—they need to make decisions quickly and iterate rapidly at customer sites. But domestic companies tend to have tight controls and long approval processes, making it hard to give FDEs sufficient authority. More importantly, there is a lack of a culture that treats FDEs as an entrepreneur training camp. Many of Palantir's FDEs went on to become successful entrepreneurs, which is itself a huge draw. But domestic companies often lack this long-term perspective.

Sixth, problems with the competitive market environment. Competition in the domestic 2B market is fierce, and low-price competition is common. Customers are easily attracted to solutions that "look about the same but are much cheaper." No matter how capable your FDE team is, it's hard to convince customers in bidding processes to accept a quote several times higher. This makes it difficult to maintain the high deal sizes and high margins that Palantir enjoys.

02. These problems do exist

As a practitioner who has worked in the 2B software field for over a decade, I must admit that these problems do exist, and they are serious.

In the early days of Sensors Data, we faced similar challenges. Customers wanted us to send people on-site to help them with data integration, analysis and modeling, and other work. But we quickly found that sending people on-site for every customer would be extremely costly and hard to scale.

From my observations, the margins of domestic 2B software are far below Palantir's 80%. With such thin margins, it is indeed hard to support a large-scale FDE team.

More importantly, the pricing mechanisms in the domestic 2B market differ greatly from those abroad. Domestic customers tend to value "buying outright" over "subscribing," and "features" over "outcomes." This makes it hard to price based on delivered outcomes the way Palantir does.

03. But we shouldn't generalize

Although there are many problems, I don't think we should generalize. These judgments come mostly from the experience of traditional 2B software, but viewed from another angle, the FDE model does have its feasibility in China:

First, project value determines the margin for profit. As mentioned earlier, domestic 2B project margins are said to be insufficient to support highly paid FDEs, but this judgment needs to be scenario-specific. In fields like financial risk control, energy dispatch, and intelligent manufacturing, a good AI system can create hundreds of millions of yuan in value. If pricing is based on "paying for outcomes" rather than "buying features," deal sizes can fully support FDE teams with million-yuan-level salaries. The problem is not that the profit margin doesn't exist, but whether we have the capability to serve such high-value scenarios.

Second, the essence of talent attraction is room for growth. Excellent engineers are reluctant to do on-site work, not essentially because of the "on-site" format itself, but because traditional on-site roles lack room for growth. But if, like Palantir, the FDE is positioned as a "product explorer deeply embedded in the business front line" and a "training camp for future entrepreneurs," given sufficient autonomy and decision-making power, the appeal of the role would be completely different. The key is to change the FDE's positioning from "executor" to "explorer."

Third, the promotion mechanism can be redesigned. The traditional promotion logic for on-site roles is "do well and get transferred back to headquarters," which is indeed problematic. But we can absolutely design new promotion paths: senior FDEs don't "leave the front line," but instead "lead teams to tackle harder customers" and "explore more cutting-edge scenarios." We could even let outstanding FDEs become internal entrepreneurs and incubate new product lines. What this requires is organizational innovation, not copying the traditional model.

Fourth, product abstraction capability can be cultivated. Domestic companies indeed generally lack product abstraction capability, but this is not immutable. Palantir's Ontology didn't exist from the start either—it was gradually abstracted from extensive project practice. The key is to establish a product development mechanism of "from gravel road to highway," so that the experience from every customer project can be distilled into reusable product capabilities. This requires close collaboration between the product team and the FDE team, not each fighting on their own.

Fifth, organizational culture is the result of a strategic choice. FDEs require a high degree of empowerment, but domestic companies have tight controls—that's a fact. But if we make the FDE model a core strategy, the organizational culture must adjust accordingly. Just as internet companies introducing agile development went through a process from "unfamiliar" to "new normal," the key is for top leadership to have the resolve to build the FDE model as a core competitive strength, rather than dabbling in it as a peripheral business.

Sixth, the competitive market environment is diverging. Low-price competition is indeed widespread, but the market is diverging. More and more leading customers are beginning to realize that the success of an AI project lies not in what software they bought, but in whether it can truly solve business problems. These customers are willing to pay for quality service and value long-term partnerships over one-off deliveries. The target customers of the FDE model are precisely this awakening segment of high-value customers, not the long-tail market still fighting price wars.

Seventh, the broader environment may be changing. Over the past decade, the theme of the domestic 2B market was "land grabbing"—competing on who signed more customers and who grew revenue faster. But now the market has entered a stage of competition over existing customers, making customer renewal rates and customer LTV (lifetime value) more important. This means that deeply serving one customer well is more valuable than signing ten customers who won't renew. This shift in the market environment happens to create fertile ground for the FDE model.

PART03

Changes the AI Era May Bring

01. The Special Nature of AI Projects

In the AI era, especially with the rise of AI agents, new opportunities may emerge for the FDE model. There are several reasons:

First, delivering AI projects is harder than delivering traditional software projects. AI agents cannot yet achieve scaled expansion based on standardized products the way SaaS did before. Every enterprise's business processes, data structures, and application scenarios are different, requiring a great deal of customization. This fits the characteristics of the FDE model perfectly.

Second, AI amplifies the impact of outstanding individuals. In traditional software development, the productivity gap between an excellent programmer and an average one might be 3-5x. But in the AI era, with AI tools, an excellent programmer's productivity could be 10x or more that of an average one. This means that even if FDE salaries are high, the cost per unit of output may actually be lower.

Third, AI can provide greater profit margins. If AI agents can truly replace human labor on certain tasks, the value they deliver is not "improving efficiency" but "reducing costs." For example, if a customer service AI agent can replace 10 customer service staff, its value is the annual labor cost saved. That kind of value is enough to support higher pricing.

02. The Core Question: Can Customers Change Their Mindset

However, whether the FDE model can succeed in China in the AI era—the core question is not technology, but whether customers can change their mindset.

Specifically, customers need to answer two questions:

First, are you willing to pay for "outcomes" rather than just for "features"? If you still follow the traditional "buyout" model, requiring the vendor to deliver a "turnkey" system, then the FDE model will be very hard to operate. That's because the core of the FDE model is product exploration, which requires continuous iteration in practice—a process that is difficult to clearly define at contract signing.

Second, are you willing to pay for top talent? Palantir's FDE salaries are far higher than those of ordinary programmers, which is reflected in contract prices—meaning high deal sizes. If the client still hopes to buy "good enough" services at the lowest price, it will be impossible to attract excellent vendors and excellent FDEs.

From my experience, some clients are indeed gradually changing their mindset. Especially in industries with urgent AI needs, such as finance, manufacturing, and retail, they are beginning to realize that the success of an AI project cannot be solved simply by buying software; it requires deep business understanding and continuous optimization. But this shift will take time. Clients need to go through enough failed projects before they truly understand the principle that "cheap things aren't good."

03. A Possible Path

If the FDE model is to be promoted in China, I believe a possible path is:

Step one: start with high-value customers. Don't try to serve all customers; instead, focus on those who have real pain points and are willing to pay for outcomes. Just as Palantir initially served only the CIA, first serve one customer well and build a benchmark case.

Step two: build product leverage. While serving customers, continuously accumulate general-purpose product capabilities. Don't do "one-off" custom development; instead, think about how to turn this experience into reusable modules for next time. This requires very strong product abstraction skills.

Step three: cultivate FDE talent. Make the FDE role an attractive career path, not just "on-site outsourcing." You can follow Palantir's approach and make the FDE role a training camp for entrepreneurs, giving them enough autonomy and room to grow.

Step four: change the pricing model. Shift from "pricing by features" to "pricing by results." This requires exploring new cooperation models with customers, such as "money-back if no results" or "revenue sharing based on cost savings."

PART04

Conclusion

Whether the FDE model is viable in China cannot, in my view, be answered with a blanket statement.

In the short term, the FDE model does face many challenges in China, including profit margins, talent attraction, and customers' willingness to pay. But in the long term, the AI era may bring new opportunities for the FDE model.

The key lies in whether you can find customers willing to pay for outcomes, build scalable product leverage, and cultivate excellent FDE talent.

For startups, my advice is: don't blindly follow the trend; judge based on your own actual situation. If your product requires a lot of product exploration, if your customers are willing to pay for outcomes, and if you can attract excellent talent, then the FDE model is worth trying.

But if you're just treating FDE as a nicer-sounding name for "on-site outsourcing," then don't waste your time.

All the views above represent only my personal opinion, and I hope they are helpful to everyone. Errors and omissions are inevitable, and I ask for your understanding.

This article is part of the Tencent Cloud Self-Media Sync Exposure Program, shared from a WeChat official account.

Originally published: 2025-11-17. For copyright issues, please contact cloudcommunity@tencent.com for removal.