The Rise of the Forward Deployed Engineer
May 23, 2026
Why the next generation of B2B product companies will be built by engineers deployed directly inside customer workflows.
A few weeks ago, I started seeing the same job title everywhere: Forward Deployed Engineer. At first, I thought it was just another Silicon Valley label, one more way to rebrand something that already existed, maybe a more prestigious name for a solutions engineer, a technical consultant, or an implementation specialist. But the more I looked into it, the more I realized that something deeper was happening. Forward Deployed Engineers are not just becoming more visible; they are becoming one of the most important roles in modern B2B technology.
Business Insider recently reported that job postings for Forward Deployed Engineers increased by 729% year over year, from 643 openings in April 2025 to 5,330 in April 2026. Companies like OpenAI, Anthropic, Palantir, Stripe, and Google Cloud are actively hiring for these roles. This is not a small hiring trend. It is a signal that the way enterprise software gets built, sold, and deployed is changing. (Business Insider)
The obvious question is: why now? Why are the most ambitious product companies suddenly hiring engineers who are expected to code, talk to customers, understand business problems, deploy production systems, and feed product insights back into the core roadmap? The answer, I think, is simple. B2B customers no longer want software. They want outcomes. And outcomes do not happen inside a roadmap. They happen inside messy, specific, real world workflows.
Part One: What a Forward Deployed Engineer Actually Is
A Forward Deployed Engineer is a software engineer who works directly with strategic customers to turn complex business problems into production systems. That sounds simple, but the role is hard to categorize because it sits between several worlds. It is partly engineering: the FDE writes code, builds integrations, designs technical architectures, debugs edge cases, and ships production software. It is partly product: the FDE understands what the customer is actually trying to do, separates the real need from the expressed request, and identifies which parts of the solution should become reusable product. It is partly consulting: the FDE works with people, processes, constraints, politics, existing tools, internal systems, and unclear ownership. It is partly sales, not because the FDE is there to close deals, but because the FDE often makes the difference between a customer who likes a product and a customer who actually adopts it.
The simplest way to define the role is this: a Forward Deployed Engineer is an engineer whose product spec is reality. Traditional software engineers often build one capability that many customers can use. Palantir describes the Forward Deployed Software Engineer differently: someone who embeds directly with customers to configure Palantir platforms around their hardest problems, focusing on enabling many capabilities for a single customer. (Palantir Blog) That distinction matters. The FDE does not start with a clean Jira ticket. The FDE starts with a customer saying something vague like "our team is losing too much time on this workflow", "our data is spread everywhere", "our AI pilots are not reaching production", or "our internal process is too specific for standard software." Then the FDE has to translate that mess into a working system.
Part Two: Why This Role Is Exploding Now
The role is not new. Palantir has been known for this model for years. But it is becoming mainstream now because enterprise software itself is changing. For the last 15 years, the dominant B2B software model was SaaS: you built a product, hosted it in the cloud, sold licenses, onboarded users, and hoped the customer could adapt their workflows to your interface. That worked well for many categories, CRM, HR, finance, project management, marketing automation, analytics, customer support. But AI is breaking that model. AI products are not just dashboards. They are supposed to act inside workflows. They need context, access to internal tools, permissions, evaluation, domain knowledge. They need to understand how a company actually operates. A chatbot demo can be generic. A production AI system cannot.
OpenAI's own description of its Forward Deployed Engineering team is a good example. The team partners with customers to turn research breakthroughs into production systems and operates at the intersection of customer delivery and core platform development. Its Paris FDE role includes embedding deeply with strategic customers, understanding business and technical requirements, designing full stack solutions, preparing project plans, and driving both prototypes and production deployments. (OpenAI) Anthropic describes the same shift from another angle: its Forward Deployed Engineers embed with strategic customers, build production applications with Claude, deliver technical artifacts like MCP servers, sub agents, and agent skills, and identify repeatable deployment patterns to feed back into Product and Engineering. (Greenhouse) Stripe is moving in the same direction. Its Forward Deployed Engineering roles involve designing and deploying production applications that combine customer business logic, Stripe best practices, and user facing interfaces, while bridging technical teams and executives. (Stripe)
This is the pattern. The most advanced B2B product companies are realizing that the hard part is no longer just building the product. The hard part is making the product work inside the customer's organization.
Part Three: The Deployment Gap
Most companies do not fail at AI because the model is not smart enough. They fail because the model is not deployed correctly. The data is not clean, the workflow is unclear, the tools are fragmented, the people do not trust the system, the evaluation is missing, the integration is half done. The pilot works in a demo, but nobody uses it every day.
McKinsey's 2025 State of AI report says that almost all surveyed organizations use AI, and many have started using AI agents, but most are still early in scaling AI and capturing enterprise level value. The companies that perform best are the ones where leaders are actively involved in adoption and workflow transformation. (McKinsey & Company) BCG makes a similar point with its 10-20-70 rule for AI at scale: 10% algorithms, 20% technology and data, and 70% people and processes. In other words, the model is not the whole transformation. The organizational deployment is the transformation. (BCG Global)
This is exactly where the Forward Deployed Engineer becomes important. The FDE is not there to prove that the technology works in theory. The FDE is there to make the technology work in the customer's reality. It starts with understanding the system before touching the code: who owns the process, where the data comes from, who validates the output, what happens when the AI is wrong, which existing tool is the source of truth, which part of the workflow is actually painful, what needs to be automated and what should remain human, what needs to be custom and what should become product. These are not purely technical questions. But they are also not purely business questions. They live in the middle. That is why the role is so rare. A good FDE needs to be technical enough to build, product minded enough to abstract, and customer facing enough to understand the real problem.
Part Four: The Old Version of This Job
The closest historical version of the FDE was probably the ecosystem around enterprise platforms like Salesforce. Salesforce sold the platform. Then implementation partners, CRM consultants, freelance experts, and system integrators did the work of adapting it to each company. They configured objects, built workflows, integrated tools, migrated data, created dashboards, trained teams, and maintained custom logic. In many ways, these people were already solving the same type of problem: take a generic product and make it fit a specific business. But there was one major difference: they were usually outside the product company. The integration layer was outsourced because it was seen as services. It was useful, but not strategic. The product company could focus on the platform, while partners handled the messy reality of each customer.
The Forward Deployed Engineer changes that. The new integration layer is being brought back inside product companies because it is where the product learns. This is the key difference. A traditional integrator implements what already exists. A Forward Deployed Engineer implements, but also discovers what should exist next. Every painful deployment teaches something. Every custom workflow reveals a missing abstraction. Every enterprise constraint shows where the product is not mature enough. Every repeated request points toward a future feature. If this learning happens only inside external consulting firms, the product company loses the most valuable feedback loop. That is why the FDE is not just a delivery role. It is a product intelligence role.
Part Five: Why AI Makes This Inevitable
AI makes this role much more important because AI products are not static tools. They are systems that need to be adapted, evaluated, and trusted inside specific workflows. A CRM can fail slowly. An AI agent can fail instantly. If an AI agent sends the wrong email, updates the wrong record, summarizes the wrong meeting, or recommends the wrong candidate, the customer does not care that the model is impressive. They care that the workflow broke.
This is why AI deployment requires much more than API access. It requires data access, permissions, security, observability, evaluation, workflow design, user training, fallback logic, integration with existing tools, and alignment with internal processes. Gartner predicts that up to 40% of enterprise applications will include integrated task specific agents by 2026, up from less than 5% in 2025. If that happens, AI will stop being a separate tool and become part of the application layer itself. (Gartner)
That shift creates a huge deployment problem. Every company has different data, different processes, different tools, different risk tolerance, different vocabulary, different politics, different definitions of success. You cannot solve that only with documentation. You need engineers in the field.
Part Six: The Return of Service Inside Product Companies
For years, software companies tried to avoid services. Services were seen as low margin, hard to scale, and dangerous for product focus. The best software businesses were supposed to be pure product companies: high gross margin, standardized onboarding, repeatable sales, minimal custom work. That logic still matters. But it is becoming incomplete. In complex B2B markets, especially with AI, service is no longer just service. It can be the fastest path to product market fit. The mistake is not doing services. The mistake is doing services without learning.
A bad Forward Deployed Engineering function becomes a custom development agency inside the company. Every customer gets a different solution, the codebase becomes fragmented, the roadmap becomes reactive, engineers spend their time maintaining one off projects, margins collapse. A good Forward Deployed Engineering function does the opposite: it uses customer specific work to discover reusable patterns. The goal is not to say yes to every customer. The goal is to find the repeatable product hidden inside the customer's mess.
This is the entire discipline: build something specific enough to solve the customer's problem, abstract it enough to help the next customer, feed it back into the product, repeat. That is why I think FDEs will become central to the next generation of B2B product companies. Not because every company should become a consulting firm, but because every company needs a stronger bridge between field reality and product strategy.
Part Seven: Why Founders Are Naturally Trained For This
The more I read about Forward Deployed Engineers, the more I realized that the role feels familiar. In many ways, every early technical founder is forward deployed before they know the title exists. When you build an early B2B startup, you cannot hide behind a roadmap. You are in front of the customer. You hear the problem directly. You do the demo, you write the code, you fix the bug, you answer the support message, you negotiate the contract, you rebuild the feature, you explain the limitation, you deploy again.
At Clustor, I learned this directly. We were building an AI product for consulting and staffing firms. That meant dealing with real business workflows: CRM data, candidate profiles, client needs, matching logic, Microsoft 365, meetings, emails, Boond, document generation, internal processes, and sales pressure. The difficult part was rarely just building the feature. The difficult part was understanding what the client actually meant.
A customer would ask for a better matching system, but the real problem was not "matching": it was that recruiters had no time to search across fragmented data, interpret client needs, identify available profiles, prepare the right documents, and answer fast enough. A customer would ask for meeting transcription, but the real problem was not "transcription": it was that important information from client calls disappeared after the meeting and never came back cleanly into the CRM. A customer would ask for a custom document template, but the real problem was not "template generation": it was that every consulting firm had its own way of presenting talent, and the product had to respect that without becoming impossible to maintain.
This is exactly the FDE problem. The customer expresses a feature. The real need is a workflow. The engineer has to discover the system behind the request. That is why technical founders can be very strong FDEs: they have already lived the full loop of customer, product, code, deployment, support, sales, and iteration. They are used to ambiguity, to incomplete specs, to building under pressure. They know that the best product insights rarely come from a clean brainstorming session. They come from a customer who is blocked, a deal that might be lost, or a workflow that breaks in production.
Part Eight: Why Every B2B Product Company Will Need This Layer
I do not think Forward Deployed Engineering will remain a niche role for Palantir, OpenAI, Anthropic, or Stripe. I think almost every serious B2B product company will need some version of it.
Startups will need it because founders cannot remain the only people capable of handling strategic customers. In the early days, founder led delivery is useful: it creates learning, builds trust, helps close deals. But at some point, it becomes a bottleneck. The founder is pulled into every complex customer request, every integration discussion, every custom workflow, every proof of concept, every support escalation. That does not scale. A startup needs someone who can take a strategic customer from vague need to production deployment without requiring the founder to be in every meeting. That person is a Forward Deployed Engineer.
Scale ups will need it because their product becomes more powerful, but also more complex. As they move upmarket, customers ask for deeper integrations, stronger security, more customization, and clearer business impact. A standard customer success team is often not technical enough. A standard engineering team is often too far from the customer. A standard sales engineer is often too focused on pre sales. The FDE fills the gap.
Large companies will need it for a different reason. They already have sales, customer success, solutions architects, product managers, professional services, support, and engineering teams. But the problem is often fragmentation: everyone owns a part of the customer journey, but nobody owns the full path from business problem to working system. The FDE can become the connective tissue. They sit between executives, users, engineering, product, security, and operations. They make sure that what was sold becomes what is deployed, and that what is deployed teaches the product team what to build next. The FDE is the missing layer between sales promises, product roadmaps, and production reality.
Part Nine: Why Freelance FDEs Might Be the Best First Step
Not every company should immediately build a full Forward Deployed Engineering team. For many startups and scale ups, the best first step is probably to work with freelance FDE profiles. The reason is simple: the function is still new, and most companies do not yet know exactly how to structure it. A freelance FDE can help test the model on one or two strategic accounts.
For a startup, this can be extremely valuable. The founder may already be spending too much time on complex customer delivery. A freelance FDE can absorb part of that work, structure the deployment process, document recurring patterns, and help convert custom needs into reusable product decisions. For a scale up, the value is different: a freelance FDE can unblock a large enterprise customer, accelerate a stalled integration, audit the gap between product and customer reality, or build the missing layer that makes the product usable in a specific environment. For a larger company, a freelance FDE can act as a strike team for strategic accounts where the normal organization is too slow. This is especially useful when the company has a great product, but the customer needs more than a login and a help center.
The first few FDE missions should not be measured only by delivery. They should be measured by what they teach. Did the customer go live faster? Did the founder save time? Did the sales team unlock a larger deal? Did the product team discover a repeated pattern? Did the company create a reusable playbook? Did the implementation become easier for the next customer? That is the real value. A freelance FDE is not just extra engineering capacity. It is a way to prototype a new operating model.
Part Ten: The Risk
There is a dangerous version of this trend. If every B2B product company starts hiring FDEs without discipline, many of them will simply recreate consulting firms inside their product teams. That would be a mistake. The role only works if there is a clear boundary between custom delivery and product learning. A bad FDE says yes to the customer and creates one off complexity; a good FDE understands the customer, solves the problem, and extracts the reusable abstraction. A bad FDE creates hidden maintenance; a good FDE creates product leverage. A bad FDE makes the company more dependent on services; a good FDE makes the product more deployable.
This distinction is important because the economic model of software still matters. If every customer requires a unique engineering project forever, the business becomes hard to scale. The goal is not to abandon product discipline. The goal is to bring product discipline closer to the field. The best Forward Deployed Engineers will not be the ones who build the most custom code. They will be the ones who can look at a custom request and understand what part of it should become product.
Part Eleven: Why I Think This Role Fits Me
This is also why I think the role fits me unusually well. I am a former technical founder in B2B AI. I have built product from customer needs, sold it, deployed it, supported it, and iterated on it in production. I am comfortable going from a business conversation to architecture, from a customer demo to a backend integration, from a vague workflow problem to a shipped feature. I have worked on AI agents, CRM integrations, document generation, meeting transcription, matching systems, Microsoft 365 workflows, and enterprise onboarding problems. But more importantly, I have worked directly with customers who did not care about the technical beauty of the system. They cared about whether it solved their problem.
That changes how you build. You stop thinking only in features and start thinking in workflows. You stop asking what the user clicked and start asking what the user was trying to accomplish. You stop treating customer specific requests as noise and start looking for the pattern behind them. That is the mindset I want to keep working with.
I am not looking for a role where engineering is isolated from the customer. I am looking for the opposite: a role where the customer is the fastest path to building the right product. That can be inside a startup that needs help with its first strategic customers, inside a scale up that needs to turn complex enterprise deals into successful deployments, or inside a larger company that has strong technology but needs a bridge between product, engineering, and customer reality. The title might be Forward Deployed Engineer, Technical Product Engineer, Founding Engineer for enterprise deployments, or AI Solutions Engineer. The title matters less than the operating model. The work is clear: understand the customer, build the system, deploy it, learn from it, and turn the learning into product.
Conclusion: The Future of B2B Product Is in the Field
For years, the dream of software was to remove humans from deployment: build once, sell many times, standardize everything, let customers onboard themselves. That model is not disappearing. But it is no longer enough for the most valuable B2B products. The future of enterprise software, especially AI software, will be more deeply embedded in customer workflows. It will touch internal data, tools, permissions, processes, and decisions. It will not be enough to provide access. Companies will need to make sure the product actually works in production.
That is why the Forward Deployed Engineer is rising. Not because companies suddenly want more services, not because engineering is becoming consulting, not because product discipline is dead. The FDE is rising because the distance between product and customer reality became too expensive. The best products will not be built only from roadmaps. They will be built from the field, inside the messy, specific, high value workflows where customers actually live. That is why the Forward Deployed Engineer is not just a new job title. It is the next operating model for B2B product companies.