What is a "Forward Deployed" Product Manager and why are AI companies hiring them?

The article, written by Caroline Clark in Mind the Product (October 19, 2026), explains what the Forward Deployed Product Manager (FDPM) is, a role gaining prominence with the arrival of AI products. The definition is as follows: a PM employed by a vendor who works inside the customer's organization, alongside the people who use the product, to make it work in that context. They belong to one company but are embedded in another, and are accountable for how the product works in that customer's world. Depending on the company, they may cover a single customer or a small portfolio of accounts.

The author opens with a personal anecdote from ten years ago. As a Technical Product Manager, she led a team of backend engineers integrating her product's API into a travel retailer's booking systems. Problems arose that they couldn't diagnose remotely and that were costing them revenue. She went to a store with her lead engineer and they solved them by watching what happened live. It worked, but only because they had no other options left. Today, the text argues, doing this deliberately is a job in its own right.

The key to the role is proximity. Instead of relying on interviews, support tickets or screen-sharing video calls, the FDPM sees first-hand how a problem shows up and how users work around it. They then do two things. First, they determine what will make that customer successful, often by configuring the platform and prototyping working solutions with real users. Second, they feed what they learn back to the team building the core product, so that other customers benefit. They typically work alongside a Forward Deployed Engineer (FDE), who handles the technical build, while the FDPM focuses on what the customer needs and why.

The term comes from the military, where forward deployment means positioning forces close to where they may be needed. According to the article, Palantir brought it to software around 2010 with the Forward Deployed Engineer role, in complex environments such as defense, intelligence, healthcare and aviation. Until then, software companies built either standardized products (scalable and cheaper) or custom solutions (hard to scale and expensive). Palantir positioned itself in between: it configured its standard platform for each customer, built custom features when needed and folded what worked back into the platform for everyone. That cycle of deploy, learn and generalize is what the FDPM inherits.

Why now? The text argues that AI products are not off-the-shelf and that the gap between a capable model and a working deployment has become the bottleneck. A model only delivers real value when it is connected to the customer's data, workflows, permissions, systems and people, and when those people trust it. Doing that from the outside is hard, so the FDPM aims to shorten a painful feedback loop: the customer hits a problem, explains it to the vendor over the phone, the vendor builds something and the customer tries to implement it on their own.

The article states that OpenAI, Anthropic, AWS, Microsoft and SAP have announced programs of this kind and are hiring aggressively. It cites The Bench, a job board covering European tech companies, which counted 170 active listings with "Forward Deployed" in the title across 98 companies at the end of July 2026. New postings rose from one in January to 62 in July. Most are engineering roles, with FDPM positions a visible subset; companies advertising them include Scale AI, Salesforce and Adobe.

If AI deployment is mainly an engineering problem, why a PM? Because every embedded project generates a stream of requests, and someone has to decide which ones reveal a pattern worth building into the product and which are specific to one customer. Some practitioners, the text notes, argue that the hard part is deciding what is worth building and whether it pays off. That judgment, along with the trust of executives on both sides, is what justifies having a PM alongside the FDE.

Day-to-day work combines observation and prototyping. The FDPM watches how users interact with the customer's systems and workflows, and learns a lot in informal moments, such as tea breaks in the kitchen. Some even train to operate the customer's systems, for example by working a few days as a call center agent: first-hand experience beats second-hand description. They then design and test quick prototypes and configurations with future users, often with the help of AI tools, and document workflows, prototypes and results to inform prioritization and make the trade-offs between solutions explicit. Successful solutions go back to the core platform team to assess rolling them out to everyone.

To illustrate, the author imagines that her travel retailer case had had an FDPM from day one. In the first week, they would sit with the advisers and observe real bookings before any integration work. They would notice two things: advisers don't book in a straight line but jump between parts of the process as the conversation with the customer evolves, and they skip the upsell page to get to payment, so the opportunity is usually lost. Asking why would surface an aspect of buyer psychology: the booking is just one moment in the customer's journey, and the adviser cares more about understanding the experience the customer wants than selling extras at checkout. The solution, together with the FDE, would be a "hub and spoke" flow allowing free movement between sections and a workflow that emails add-on offers after booking. Then comes the product judgment: is this specific to this retailer, or do other customers book this way? If it's common, the FDPM takes the evidence to the core team and recommends changing the default behavior for everyone. The typical "product trio" is the FDPM, an FDE and a core platform PM who acts as liaison.

The main difference from a traditional PM is what each owns: the traditional PM is responsible for a product, the FDPM for the outcomes of a customer account. Compared with neighboring roles, the text draws distinctions: the FDE handles the "how" (writing and deploying the technical solution), while the FDPM handles the "what" and the "why"; the solutions architect designs the best implementation of the existing product for a customer, while the FDPM decides how the product itself should change based on what those implementations reveal; the consultant tends to recommend and leave, while the FDPM stays until the product delivers value, is accountable for outcomes and has a duty to feed learning back into the product; and the AI PM builds AI features for a market of customers, while the FDPM seeks to make the product work for specific customers.

The article adds a caveat: some of this is relabeling. Citing a piece by Ben Hollands on a16z's Substack, it notes that Palantir used the title to raise the status of customer-facing roles that had previously been treated as expendable, a move the text calls "title arbitrage." That is why it's worth reading the job description rather than relying on the name alone.

In terms of skills, the starting point is PM fundamentals: creative problem-solving, prioritizing by impact, owning discovery and delivery, and distinguishing between what the customer asks for, their real problem and what the platform should do. Three things are added to that. First, technical depth: enough to debate architecture and feasibility with engineers and read logs and data directly; for AI products, understanding models, evaluations, guardrails, hallucinations and data structuring, as well as prototyping with different models and agent workflows, without needing to ship production code. Second, commercial judgment and the ability to say no: deciding what stays custom and what goes to the core team is the heart of the role, and one suggested discipline is to set the threshold in advance (for example, the same need across several unrelated accounts) so the roadmap isn't captured by whoever shouts loudest. Third, relationship skills: communication, negotiation, persuasion and building trust at every level, plus knowing how to navigate organizational bureaucracy such as procurement, security reviews and customer politics.

Before accepting such a role, the article recommends asking how a needed feature makes it into the core product's backlog, how much engineering capacity is reserved for the initiatives you feed back, how performance will be measured, how much autonomy there is to create custom features and configurations, and whether you have the authority to make commitments about the core product and whether feature teams will honor them. It's also worth honestly weighing the pros and cons. Among the advantages: exposure to a variety of problems and customer environments and fast learning, especially in AI. Among the drawbacks: depth in one account can come at the expense of long-term product strategy, you may end up delivering on promises made elsewhere in the company, and being very close to one project makes it harder to see the product as a whole.

The conclusion returns to the opening anecdote: the problem was never a lack of smart people, but the distance between those building and the problem to be solved. The FDPM is the role designed to close that distance.