The FDE Role That Both OpenAI and Anthropic Are Hiring For — What Exactly Is It? – Everyone Is a Product Manager

The FDE that both OpenAI and Anthropic are hiring—what exactly is this role?

AI entering enterprises is no longer about simply embedding a chat box; it requires "front-line combat" deep in business scenarios. The FDE (Forward Deployed Engineer), an emerging role, is becoming a key driver of model deployment—they need to untangle messy business workflows, design solutions for stitching together data and permissions, and even rebuild entire workflows. This article will reveal why the more powerful models become, the more enterprises need this group of "product scouts," and how they use engineering thinking to solve the last-mile problem of AI deployment.

A few years ago, the most common move for a company wanting to adopt AI was to build a chat box.

Find a model vendor, apply for API access, set up a knowledge base, and add a bot icon in the bottom-right corner of the website. When executives came to try it, it could answer a few common questions; by the time of the project review, the PPT finally had a page on "AI applications."

Three months later, hardly anyone was actually using it.

Customer service was still copy-pasting, sales was still switching back and forth between dozens of systems, operations was still manually organizing spreadsheets, and R&D was still discussing in meetings how "the model is sometimes unstable."

Where did the problem lie?

It wasn't that the model wasn't smart enough.

Rather, the problem enterprises truly need to solve was never "can we hook up a model," but:

Can we fit the model into a complex, messy, constantly changing work environment and have it reliably help people complete tasks every day.

That is far harder than building a demo.

A real enterprise system typically involves multiple data sources, different levels of permissions, legacy systems, business rules no one can fully explain, and a group of frontline employees with no time to study prompts. The model needs to know when it can handle things automatically and when a human must confirm; when an answer is wrong, it needs to know where to trace back; and after a model update, everything has to be retested.

As more and more companies run into these problems, a role that used to appear mainly at enterprise services companies like Palantir has re-entered the industry's field of view:

FDE, Forward Deployed Engineer.

In May 2026, OpenAI announced the establishment of the OpenAI Deployment Company, dedicated to helping enterprises apply AI in their daily business. The official announcement explicitly stated that this company would send FDEs into organizations to work with business leaders, technical teams, and frontline employees to identify problems, redo processes, develop systems, and complete launches. OpenAI also announced plans to acquire Tomoro, an applied AI consulting and engineering company, bringing in about 150 experienced FDEs and deployment experts. [Source 1]

Anthropic is also hiring Forward Deployed Engineers. Its public job description states it plainly: FDEs will go into key customers' systems, use Claude models to develop production-grade applications, deliver technical components such as MCP Servers, sub-agents, and Agent Skills that can go directly into workflows, and organize repeatable methodologies to feed back to the product and engineering teams. [Source 2]

Databricks has also built an AI FDE team to help customers develop and launch new types of generative AI applications. Its careers page lists work including RAG, multi-agent systems, Text2SQL, model fine-tuning, evals, and performance optimization. [Source 3]

This is not an ordinary hiring trend.

It signals a more important industry shift:

As model capabilities become increasingly easy to obtain, what is truly expensive is shifting from "owning a model" to "putting a model to use."

For professionals in China's mobile internet industry, the FDE deserves attention not just because it may become a new career direction.

More importantly, it is redefining the division of labor among product managers, engineers, Solutions Architects, and implementation teams.

Figure 1: The core of the FDE is not building a chat box, but bringing AI into real work environments.

I. First, Let's Clear Up the Misconception: An FDE Is Not a Front-End Engineer

When people first see FDE, many interpret it as "Front-End Deployment Engineer."

That's understandable.

China's internet industry has long used FE to mean Front-End Engineer, typically translated into Chinese as "front-end engineer." With one extra letter, FDE is easily mistaken for a technical role related to front-end development and operations deployment.

But the F in FDE does not stand for Front-End—it stands for Forward.

The full name is: Forward Deployed Engineer.

More accurate Chinese translations could be "前线部署工程师" (front-line deployed engineer), "前置部署工程师" (forward-positioned engineer), or "前沿部署工程师" (Forward Deployed Engineer).

Its core is neither writing front-end code nor deploying servers.

"Forward Deployed" is closer to a military concept: instead of staying in the rear waiting for others to clarify requirements, you go to the place closest to the problem, assess the situation on-site, and solve it there.

OpenAI's job description for the FDE is very clear.

An FDE works with key customers to deploy frontier models in production, responsible for requirements discovery, technical scoping, system design, development, and formal launch. Success is measured not just by whether features are completed, but by whether the system is actually used, whether workflows have changed in quantifiable ways, and whether on-site feedback can drive continued improvement of products and models. [Source 4]

To put it in more accessible terms:

An FDE is not the person responsible for telling customers what AI can do, but the person responsible for making AI actually start working inside the customer's company.

This means they may have to do many different kinds of things:

• Listen to complaint recordings together with the customer service manager to find the issues that consume the most labor time;
• Discuss with the sales team which information can be generated automatically and which must be confirmed by business staff;
• Read the customer's database schema to confirm which fields the model can access;
• Write interfaces to connect the model to the enterprise's existing systems;
• Build test sets to determine in which scenarios the model is prone to errors;
• Design human review mechanisms to prevent wrong answers from entering production workflows directly;
• After launch, review logs to find out why employees are unwilling to use the system;
• Organize recurring problems into product requirements and feed them back to the core R&D team.

This may include front-end pages, or it may not.

The FDE's focus is not the tech stack, but the outcome.

II. Why Do Enterprises Need People More, the Stronger Models Become?

When many people first hear about the FDE, a question arises:

AI can already write code, do analysis, and generate reports—why would enterprises pay high salaries to hire a group of engineers to go on-site at customers?

The answer lies precisely in this: the stronger model capabilities become, the easier it is for enterprises to underestimate the difficulty of real deployment.

Figure 2: The real difficulty for enterprises lies in connecting models, data, permissions, and workflows.

1. What Enterprises Buy Is Capability, Not Ready-to-Use Answers

Suppose a chain retail enterprise wants to use AI to analyze store operations.

A model can indeed read sales reports, summarize problems, and generate recommendations.

But as soon as real work begins, a series of concrete questions quickly arise:

• What if different stores' data formats are inconsistent?
• Where do you get information on promotions, weather, and holidays?
• Which data can store managers see, and which can regional managers see?
• On what basis were the AI's recommendations generated?
• If the model misjudges an anomaly at a store, who reviews it?
• Is the data updated once a day, or in real time?
• Should the results appear in a chat box, or go directly into the store management system?
• Are employees willing to change their existing work habits?

Of these questions, only some are model problems.

More of them come from product design, data management, permission configuration, business processes, and organizational collaboration.

APIs can be purchased.

Ways of working cannot be purchased with one click.

2. AI products cannot rely solely on traditional acceptance testing

Traditional software is more like a vending machine.

You click a button, and the system returns a result according to fixed rules.

Testers can write it clearly: input A, expect B; input C, expect D.

Large models are different.

The same question phrased differently may yield different answers. On the same passage, it may correctly identify nine pieces of information yet miss the tenth. It can complete complex tasks, but it can also say something wrong with great confidence.

Therefore, acceptance testing for AI projects cannot only ask: Does the feature work?

It also needs to ask:

• Which types of problems are most error-prone?
• What is the probability of errors occurring?
• How severe are the consequences of an error?
• Which answers must include citations from the source text?
• Which scenarios must be confirmed by a human?
• After a model upgrade, is retesting required?
• Are the system's speed and API call costs acceptable?

The FDE needs to turn these questions into concrete test samples, review rules, and launch criteria.

3. What enterprises really need is a redesign of how work gets done

Many AI projects fail not because the model isn't good enough, but because the product merely adds a new entry point on top of the existing work.

Employees already had to open five systems; now there's one more chat box.

Naturally, sustained usage is hard to achieve.

Truly effective AI applications usually need to be embedded into existing workflows.

For example, a salesperson shouldn't have to proactively ask the AI every day: Please help me sort out the customers most worth following up with today.

A more sensible approach: the system automatically reads customer communication records, order status, and recent behavior, and when the salesperson opens the CRM each day, it directly displays the customers most worth attention, the reasoning behind it, and suggested next actions.

Likewise, customer service agents shouldn't have to copy a passage of text into a chatbot while answering user questions.

A more sensible approach: the agent workspace automatically recognizes user intent, retrieves the relevant rules, generates suggested replies, and prompts for human confirmation in low-confidence scenarios.

This is not adding a new feature.

This is rearranging who completes part of the work, when it gets done, and who is responsible when something goes wrong.

In the official introduction of the Deployment Company, OpenAI describes the FDE's work quite concretely: first diagnose the scenarios where AI is most worth deploying, select a small number of priority workflows, then connect the model to the customer's data, tools, controls, and business processes, completing design, development, testing, and launch. [Source 1]

That is why the FDE exists.

III. The FDE is not a profession that appeared out of nowhere

The FDE's recent attention is tied to the development of generative AI.

But this role was not invented by OpenAI.

One of the earlier companies to establish a similar mechanism was Palantir.

Palantir's customers often come from complex domains such as government, manufacturing, and finance. Their problems are usually not "add a button" or "build a page," but how to connect scattered data, complex processes, and decision-making across different departments.

Palantir draws a clear distinction between two types of engineers.

The first is the Software Engineer, internally called a Dev.

Devs mainly develop general-purpose products, such as storage, interaction, or infrastructure capabilities within the platform. These capabilities must serve many customers, so the focus is on architecture, stability, and reusability.

The second is the Forward Deployed Software Engineer, internally called a Delta.

Deltas work directly with customers, using Palantir's platform, open-source tools, and their own engineering skills to solve the customer's specific problems.

Palantir summarized the difference in one sentence in an official article:

A Dev focuses on "one capability serving many customers"; a Delta focuses on "one customer drawing on many capabilities." [Source 5]

This sentence is well worth product managers remembering.

Because it reveals two completely different product mindsets.

One mindset starts from product capabilities:

We already have these modules—how do we get more users to use them?

The other mindset starts from problems in the field:

What problem does this customer really need to solve? How should existing capabilities be combined? What's still missing?

Both mindsets matter.

But in the stage when a new technology has just entered an industry and standard answers have not yet formed, the second mindset often matters more.

The AI industry is at exactly such a stage right now.

IV. Why is the FDE heating up noticeably in 2026?

In a February 2026 report, Reuters called the FDE one of the hottest roles in the AI industry at the time. Citing LinkedIn data, the report said that from 2023 to 2025, demand for FDEs and similar roles grew 42-fold, with roughly 9,000 new positions worldwide. [Source 6]

9,000 positions is not a huge job market.

But it is still worth attention.

Because it points to the hardest problems in the commercialization of AI.

1. Models are becoming a baseline capability

Early competition among large models focused on parameter scale, reasoning ability, context length, and benchmark scores.

These still matter.

But for enterprise customers, the gap between models is no longer the only issue.

More and more companies are starting to ask:

• Which scenario can cut costs first?
• Which department is best suited to pilot first?
• How do we connect the model to existing systems?
• How do we ensure the output is trustworthy?
• How do we get employees to actually use it?
• After a successful pilot, how do we scale it up?

The more widespread model capabilities become, the more important these questions are.

2. Standardized software cannot cover every scenario

Over the past decade or so, the mobile internet and SaaS industries have both pursued standardization.

Build one product to serve as many users as possible.

Standardization lowers marginal costs and makes scaling easier.

But AI projects face a practical problem:

The differences between enterprises are often hidden in their workflows.

Take contract processing:

• Internet platforms care about supplier terms;
• banks care about compliance risk;
• manufacturers care about procurement cycles;
• healthcare institutions care about privacy and liability boundaries.

Take customer service:

• e-commerce cares about returns, exchanges, and logistics;
• game companies care about accounts, top-ups, and community issues;
• financial institutions care about identity verification and risk disclosures;
• airlines care about flight changes and passenger arrangements.

The underlying model can be the same.

But the data sources, permission design, risk levels, and human review methods are completely different.

The value of an FDE lies in finding workable solutions between standard capabilities and specific field conditions.

3. AI companies are starting to treat delivery experience as raw material for products

The FDE is not just a customer-facing role.

It also serves another important purpose:

Helping model companies discover the next capability that should become a standard product.

OpenAI's FDE Platform team job description mentions that the team needs to turn problems encountered in the field into repeatable methods and long-term product capabilities, rather than leaving them as one-off fixes. [Source 7]

Anthropic's FDE job page makes a similar requirement: identify and organize repeatable deployment patterns, then feed that information back to the product and engineering teams. [Source 2]

This means the FDE is not an after-sales person standing outside the product team.

He is more like a product scout closest to real problems.

While helping customers solve problems, he also judges which problems are worth turning into platform capabilities.

5. How does a real FDE project actually proceed?

To understand this role, let's look at an example closer to real work.

Suppose a large insurance company wants to use AI to improve the efficiency of processing claims materials.

Every day, employees need to read large amounts of accident descriptions, medical records, invoices, contract terms, and historical records, then judge whether the materials are complete, whether the case needs additional information, and which situations should be handed over to more experienced staff.

Management proposes a seemingly reasonable requirement:

Build an AI claims assistant.

But this is still not a requirement that can be developed directly.

The FDE needs to break it down into a series of concrete questions.

Figure 3: An FDE project usually starts with observing the field, then moves into development, testing, and launch.

Step 1: First go see how people actually work

Don't rush to open the model console.

First sit next to the business staff and observe how they handle cases every day.

You need to figure out:

• Where does a document enter the system?
• How many cases does an employee handle per day?
• Which step is the most time-consuming?
• Which information is most easily missed?
• Which types of cases are most prone to misjudgment?
• Which rules are written in documents, and which exist only in the experience of veteran employees?
• What are the consequences of an error?
• Which cases must never be handled automatically by AI?

This stage is not a "requirements meeting."

It is about understanding real work.

A common mistake product managers make is interviewing users in a meeting room and then writing the solutions users describe verbatim into the requirements document.

The FDE focuses more on behavior.

Employees may say what they need most is automated report generation, but what actually takes the most time might be finding three key fields in dozens of pages of materials.

Step 2: Pick only one problem worth solving first

The insurance company may want AI to do many things:

• Automatically extract information from materials;
• Check whether materials are complete;
• Identify anomalies;
• Generate case summaries;
• Recommend handling approaches;
• Automatically contact users for supplementary materials;
• Predict claim amounts;
• Determine whether risks exist.

If the first phase tries to do everything, the project will most likely spiral out of control.

The FDE needs to judge which problem meets three conditions:

• High frequency of occurrence;
• Clearly saves time;
• Errors can still be controlled through human review.

For example, the first phase only does:

Extract key fields from materials, generate case summaries, and mark their locations in the original text.

This feature may not seem that "intelligent."

But it is easier to accept, and easier to get frontline employees willing to use it.

Step 3: Build a minimum viable version

Only now does development begin.

The system needs to at least accomplish:

• Receiving files;
• Recognizing text;
• Determining file types;
• Extracting key fields;
• Generating summaries;
• Marking the basis in the original text;
• Recording employee edits;
• Saving operation logs;
• Flagging low-confidence results.

Note that the most important thing here is not just generating results.

It also needs to allow employees to check and modify them.

Because in high-risk business, AI should not pretend to be an always-correct expert.

It is better suited as a very fast junior assistant: doing most of the organizing work first, then clearly marking the uncertain parts.

Step 4: Build a test set instead of accepting by feel

Once the system is developed, you can't have a few executives try it for ten minutes and declare it ready for launch.

You need to collect a batch of real samples, categorized by business type, material length, file quality, and risk level.

Then check item by item:

• Field extraction accuracy;
• Whether summaries miss key information;
• Whether citations from the original text are correct;
• Whether low-confidence scenarios are successfully flagged;
• Whether processing speed is acceptable;
• What the API call cost per case is;
• What content employees modified;
• Which types of files fail most often.

If the system performs well on regular materials but frequently fails on blurry scans and messy formats, you need to clearly limit its scope.

You can't pretend it works for all situations.

Step 5: Integrate into the existing workspace

After testing proves effective, there is still an often-underestimated problem to solve:

Where will employees use it?

If employees have to additionally log into a new system, upload files, wait for results, and then copy them back to their original workspace, adoption will usually be low.

A more sensible approach is to put the AI results directly into the employee's existing operating page.

When an employee opens a case, they can see the summary, fields, and locations in the original text.

If they find an error, they edit it directly.

For uncertain results, the system automatically flags them for focused human review.

Only then does AI truly enter daily work.

Step 6: Keep observing after launch

Launch is not the end.

You still need to keep checking:

• Are employees actually using it?
• Which results are frequently modified?
• Which features does nobody click?
• Which types of cases are still processed slowly?
• Has the system introduced new risks?
• Have results changed after model upgrades?
• Which methods can be replicated to other business lines?

This is the complete process of an AI project.

The FDE's job is to make these things actually happen.

6. How exactly does the FDE differ from other roles?

The FDE sparks discussion because it looks like a combination of multiple roles.

It resembles an engineer, and also a product manager; a Solutions Architect, and also an implementation consultant; sometimes it also takes on customer success and project manager work.

But it is not simply piling all that work onto one person.

The key to understanding the difference is looking at what each role is primarily responsible for.

1. FDE vs. traditional software engineer

A traditional software engineer is usually responsible for product capabilities.

He considers:

• Is the architecture stable?
• Is the code easy to maintain?
• Can the feature support more users?
• Can the performance handle greater traffic?
• Can duplicate development be reduced?

The FDE is first and foremost accountable for results at the customer site.

He cares more about:

• Which problem is most worth solving first?
• Which existing capabilities can be used directly?
• Which parts must be built ad hoc?
• How to prove effectiveness in a short time?
• Which ad hoc solutions should later be consolidated into general capabilities?

Traditional engineers lean toward "doing one type of capability well."

FDEs lean toward "combining multiple capabilities to solve a real problem."

2. FDE vs. Sales Engineer

Sales Engineers usually come in before a contract is signed.

They need to understand customer needs, design solutions, demo the product, and help the customer decide whether to buy.

The FDE's work often goes deeper.

He needs to get into the customer's systems, write code, handle data, set up testing approaches, and drive the system to launch.

A Sales Engineer can prove "it's theoretically feasible."

An FDE must prove "it's genuinely usable every day."

3. FDE vs. Implementation Consultant

Implementation Consultants typically complete configuration, training, and delivery around mature products.

For example, setting up an existing ERP, CRM, or collaboration system according to the customer's organizational structure.

The problems FDEs face are usually much fuzzier.

Often, there is no ready-made template.

The customer only knows they want to improve efficiency, but doesn't know which process to change, or how far AI can go.

An FDE doesn't just execute the solution—they also need to co-define it.

4. FDE vs. Solutions Architect

Solutions Architects focus on technical direction and system design.

They need to judge how different technologies combine and how to meet performance, security, and cost requirements.

FDEs usually need this ability too.

The difference is that FDEs often also have to personally go through development, testing, and launch.

The solution is not the end goal.

The system being used is the end goal.

5. FDE vs. Product Manager

FDEs and Product Managers have a lot in common.

Both need to understand user problems, break down requirements, control scope, coordinate resources, and judge priorities.

But there is still one clear difference between the two:

A Product Manager can mostly drive delivery through the team, while an FDE usually needs to get hands-on with the technical implementation themselves.

This doesn't mean Product Managers must transform into full-stack engineers.

But it is a reminder to Product Managers: in the AI era, only knowing how to draw prototypes, schedule requirements, and run review meetings will become increasingly limited in value.

At a minimum, you should be able to judge:

• What problems are models suited to solve?
• Where does the data come from?
• Which outputs can be executed automatically?
• Which results must be confirmed by humans?
• How to design a test set?
• After launch, how do you judge whether the system is truly useful?

7. FDE Is Not a Universal Answer—It Can Also Become Expensive Outsourcing

Whenever a new role enters hot discussion, it easily gets packaged as "the scarcest profession of the future."

But looking at it calmly, FDEs also carry clear risks.

1. Customer customization demands can spiral out of control

One customer needs a field changed.

Another customer needs an approval step added.

A third customer needs integration with an internal system built ten years ago.

If the team keeps doing ad hoc development around a single customer, a large amount of hard-to-maintain code will quickly pile up.

In the short term, the customer is satisfied.

In the long term, every project becomes an isolated island.

2. Engineers may be stuck in firefighting mode for the long run

• Real customer sites rarely go exactly according to plan.
• Interfaces change without warning.
• Data suddenly goes wrong.
• Business staff raise new requirements.
• Leadership demands an early demo.

If boundaries aren't managed well, an FDE can easily become a high-cost firefighting crew.

Busy every day, but leaving behind little that can be reused.

3. Service revenue and product revenue can pull against each other

Enterprise service companies often face an old problem:

Keep satisfying the special needs of big customers, or keep building standard products that more customers can use?

The former brings revenue quickly.

The latter is more likely to achieve scale.

An FDE team must constantly make judgments:

• Which requirements serve only one customer?
• Which requirements will recur across multiple customers?
• Which methods are worth consolidating into components?
• Which features should go into the official product?
• Which requirements should be clearly declined?

OpenAI's FDE Platform team specifically emphasizes organizing problems that arise at customer sites into reusable platform capabilities, rather than stopping at one-off fixes. [Source 7]

This shows that even for model companies, this is a problem that must be carefully controlled.

4. Not every company needs to build its own FDE team

A smaller company with simple business processes may not need a dedicated team.

If the goal is just to use mature tools for meeting notes, content organization, or simple customer service Q&A, buying an off-the-shelf product is more suitable.

Only when the problem has the following characteristics is the FDE model more valuable:

• High business value;
• Complex processes;
• Requires integration with multiple internal systems;
• High requirements for accuracy, security, or permissions;
• Standard products cannot directly meet the need;
• Success can potentially be replicated to more scenarios.

Don't add complex organization for simple problems just because the job title is new.

8. Why Should China Mobile Internet Practitioners Care About This?

Many Chinese internet practitioners may think:

FDE is a role at overseas AI companies—what does it have to do with me?

In fact, it is highly relevant to how product, engineering, and operations teams in China will work going forward.

1. A decade of product experience cannot be directly copied into AI projects

In the mobile internet era, Product Managers have grown used to a relatively mature methodology:

• Analyze user needs;
• Design page flows;
• Produce prototypes;
• Schedule versions;
• Follow up on development;
• Review data;
• Iterate continuously.

This methodology is still useful.

But AI products add new problems:

• Model outputs are not fixed;
• Errors cannot be fully eliminated;
• Evals require long-term maintenance;
• Data quality directly affects results;
• Many requirements need to be confirmed through experiments first;

How business staff actually use it matters more than page features.

An AI project is not about adding an "intelligence button."

It requires the team to re-understand the work itself.

2. Chinese companies are more prone to complex system splicing problems

Many companies in China have accumulated a large number of internal systems:

• CRM;
• ERP;
• OA;
• Ticketing platforms;
• Data dashboards;
• WeCom;
• Feishu;
• DingTalk;
• In-house backend systems;
• Legacy business systems left over from years ago.

Truly effective AI applications often need to enter these systems.

This means that in the future, companies won't just need people who can write prompts.

They will also need people who understand the business, connect systems, design review mechanisms, and drive frontline staff to change the way they work.

3. A product manager's value will shift from "writing requirements" to "defining verifiable problems"

AI can help generate prototypes, organize documents, and write some code.

Therefore, simply completing these tasks is increasingly hard to make a product manager's core competitive advantage.

The more important capabilities are:

• Finding problems worth solving;
• Judging whether a problem is suitable for AI;
• Designing a minimal test scope;
• Defining observable outcomes;
• Controlling risks;
• Driving real business adoption;
• Turning field experience into replicable methods.

This is actually the part of FDE thinking that product managers can most benefit from.

IX. How can ordinary practitioners get started? A directly usable method

Not everyone needs to become an FDE.

But almost everyone who wants to participate in AI projects can borrow from the FDE way of working.

Below is a method that can be applied directly to real projects.

I summarize it in seven steps:

Find the field, pick the problem, calculate the value, build a small version, set the guardrails, watch usage, then replicate.

Step 1: Find the field — don't start with "what AI feature to build"

The wrong way to ask is:

• Can we build an AI assistant?
• Can we add a smart search?
• Can we build an agent?

The right way to ask is:

• Which group of people spends every day repeatedly processing large amounts of information?
• Which step is the most time-consuming?
• Which step is the most error-prone?
• Which step requires repeated rework after completion?

Observe the work first, then decide whether to use AI.

For example:

• Customer service staff spend a lot of time every day searching through rules;
• Salespeople manually organize customer communication records every day;
• Operations staff repeatedly compile data every week;
• Legal teams need to find high-risk clauses in long contracts;
• R&D teams need to understand legacy code and documentation;
• Recruiting teams need to read large numbers of resumes.

These are the problems worth analyzing further.

Step 2: Pick the problem — solve only one thing in the first phase

Don't start by building an all-purpose assistant.

Choose a problem with the following characteristics:

• It occurs frequently;
• The input is relatively well-defined;
• The output can be checked manually;
• Errors won't immediately cause major losses;
• The time saved is easy to observe.

For example, rather than building "automatically handle all customer service issues," start with:

Automatically identify the type of user question, recommend the relevant rules and a draft reply, and send it after the customer service agent confirms.

Rather than building "automatically complete contract review," start with:

Extract payment, breach, and renewal clauses, and mark their locations in the original text.

Step 3: Calculate the value — first decide how to determine whether it's useful

Before the project starts, write down three numbers:

• How much time does each processing task currently take?
• How many times does it happen per week?
• After the system goes live, how much time or how many errors do you hope to reduce?

For example:

• Customer service agents currently take an average of 4 minutes to search for rules;
• This happens 3,000 times a day;
• The goal is to reduce the average search time to under 1 minute.

This is far more useful than "improve customer service efficiency."

Because the team finally knows what success means.

Step 4: Build a small version — only get the most critical part of the workflow running

Don't aim for feature completeness in the first phase.

You only need to answer:

Can AI actually provide stable help at this step?

For example, the first phase of a sales follow-up assistant could do only the following:

• Read recent communication records;
• Generate brief summaries;
• Remind about unanswered questions;
• List suggested next steps;
• Allow salespeople to make edits.
• First verify whether salespeople are willing to use it.

Don't rush to build complex dashboards, automated outreach, or multi-system integrations.

Step 5: Set the guardrails — clarify what AI must not do

Every AI project should have a "list of prohibited automated actions."

For example:

• No automatically sending high-risk content externally;
• No modifying customer information without human confirmation;
• No reading data beyond the user's permissions;
• No giving definitive conclusions without supporting evidence from the original text;
• No treating model-generated content as final legal, medical, or financial advice;

Low-confidence results must be escalated to a human.

Don't just discuss what AI can do — first determine what it absolutely must not do.

Step 6: Watch usage — observe real behavior after launch

Don't just look at model accuracy.

Also look at:

• How many people use it every day?
• Which page has the longest dwell time?
• Which results are frequently modified?
• Which suggestions are never adopted?
• At which step do employees give up on using it?
• Is the system actually saving time?
• Does the new process add extra steps?

If employees don't use it, the product hasn't entered their work.

If results are frequently edited, the model or rules still have problems.

If suggestions are never adopted, the feature may just be the team patting itself on the back.

Step 7: Replicate — identify reusable parts from one scenario

Once the first scenario is stable, then assess:

• Which components can be reused?
• Which data processing approaches can be reused?
• Which test samples can be extended?
• Which review rules apply to other business areas?
• Which features are worth turning into platform capabilities?

Don't pursue "big and comprehensive" from the start.

Do one real scenario well first, then distill methods from it.

X. How can individuals judge whether they're suited to the FDE path?

If you're thinking about your career development, you can do a self-assessment with the following questions.

Are you willing to deal with both people and systems?

An FDE doesn't write code behind closed doors.

You need to communicate with business people, understand requirements they can't articulate clearly, and also dive into systems to handle concrete problems.

Can you accept frequently changing requirements?

Field problems rarely proceed exactly according to the requirements document.

Sometimes, the real problem only surfaces after the system starts being used.

Are you willing to be accountable for outcomes, not just deliverables?

Finishing the documents, launching the feature, and completing the report don't mean the project succeeded.

You also need to see whether users actually use it, whether time is truly saved, and whether errors are reduced.

Do you have sufficient technical understanding?

You don't necessarily need to master every technology.

But you should at least be able to understand:

• APIs;
• Databases;
• Permissions;
• Logs;
• Model calls;
• Prompts;
• RAG;
• Agents;
• evals;
• human review;
• cost and latency.

Are you good at finding the key point amid chaos?

The most important capability of an FDE is not how many tools you have mastered.

It is the ability to judge, amid a flood of requirements, constraints, and opinions:

Which one thing should be solved first right now?

If these questions excite you rather than exhaust you, FDE may be a direction worth paying attention to.

Conclusion: In the AI era, what is truly scarce are people who can turn technology into results

Figure 4: What is scarce in the AI era are people who can turn technical capability into business results.

Over the past few years, industry discussions about AI have often revolved around models:

• Who has more parameters?
• Who has stronger reasoning?
• Who has a longer context window?
• Who is better at coding?
• Who has more complex agents?

These questions matter.

But for the vast majority of enterprises, the model is not the end goal.

What is truly difficult is:

• how to find problems worth solving;
• how to connect data into the system;
• how to reorganize workflows;
• how to control errors;
• how to get employees willing to use it;
• how to prove the results are effective;
• and how to turn a single success into a repeatable method.

The emergence of the FDE reminds us of something very simple:

Technical capability does not automatically become business results.

No matter how powerful the model is, someone still needs to go into the field.

• Someone needs to look at the real processes.
• Someone needs to decide what to do first and what to leave for later.
• Someone needs to deal with the dirty data, legacy systems, and permission issues that can't be written into a slide deck.
• Someone needs to take responsibility when the system fails.

And someone needs to distill field experience, time after time, into part of the next-generation product.

This is what makes the FDE most worth paying attention to.

It is not some mysterious new buzzword, nor just a trendy role packaged by AI companies.

It represents a way of working that is becoming increasingly important:

Closer to real problems, closer to frontline employees, and closer to the final results.

This article was originally published on Everyone Is a Product Manager by @N维AI. Reproduction without the author's permission is prohibited.

Cover image from Unsplash, under the CC0 license.