Ten years ago I found myself in a high street shop for a well-known travel retailer. As a Technical Product Manager, I was leading an incredible team of backend engineers helping this partner integrate our product API into their booking systems. The goal was a seamless experience for the travel advisors in each shop, so they could offer our products as part of the main holiday booking.
But we had hit teething problems that we couldn’t diagnose remotely, and they were costing us revenue. Our only hope of fixing them quickly was to watch what was happening in a real shop, so I took my lead engineer and we troubleshooted on the spot.
It worked, but only because we had run out of other options. For a growing number of product teams, doing this deliberately is now a job in its own right.
What is a Forward Deployed Product Manager?
A Forward Deployed Product Manager (FDPM) is a product manager employed by a vendor who works inside a customer's organisation, alongside the people using the product, to make it succeed there. They belong to one company but are embedded in another, and they are accountable for how well the product works in that customer's world. Depending on the company, an FDPM covers a single customer or a small portfolio of accounts.
The point of being embedded is proximity. Rather than relying on interviews, support tickets and screen-shares, the FDPM sees first-hand how a problem shows up and how people currently work around it. They experience the problem rather than being told about it.
The FDPM then does two things. First they work out what will make this customer successful, often by configuring the platform and prototyping working solutions with real users. Next they feed what they learn back to the team building the core product, so every other customer benefits. Most FDPMs work alongside a Forward Deployed Engineer (FDE), who owns the technical build, while the FDPM owns what the customer needs and why.
Where does the term ‘forward deployed’ come from?
It's borrowed from the military, where forward deployment means stationing forces close to where they may be needed rather than at home base. Palantir brought the idea to software around 2010 with the Forward Deployed Engineer, working in complex environments such as defence, intelligence, healthcare and aviation.
Until then, software companies tended to do one of two things: build standardised products (scalable, lower priced) or bespoke custom solutions (hard to scale, expensive). Palantir sat in between. It configured its standard platform for each customer, built custom features where needed, and folded what worked back into the platform for everyone. That loop of deploy, learn and generalise is what the FDPM has inherited.
Why are companies hiring Forward Deployed PMs now?
AI products aren't off the shelf, and 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 a customer's data, workflows, permissions, systems and people, and when those people trust it. That is hard to do from the outside, so the FDPM aims to shorten a painful feedback loop where the customer hits a problem, explains it to the vendor over a call, the vendor builds something, and the customer tries to implement it by themselves.
Big technology companies have started to embrace a forward deployed approach. OpenAI, Anthropic, AWS, Microsoft and SAP have all announced programs and are recruiting extensively in this space. The Bench, a jobs board covering European tech employers, counted 170 live roles 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 of these are engineering roles, and The Bench found many more under other names, so FDPM roles are a subset. Though they are a visible one: Scale AI, Salesforce and Adobe are among the companies advertising them.
New Forward Deployed roles posted per month, 2026. Source: The Bench.
If AI deployment is largely an engineering problem, why add a PM? Because deployment is only part of it. Every embedded engagement produces a stream of requests, and someone has to decide which reveals a pattern worth building into the product and which is particular to one customer. Some practitioners argue the harder problem is deciding what is worth building and whether it pays back. That judgement, and the trust of senior stakeholders on both sides, is where a PM earns their place next to the FDE.
What does a Forward Deployed PM do day to day?
Much of the work is observation and prototyping. An FDPM watches how users interact with the customer's systems and workflows, and picks up a lot in informal moments, like those kitchen tea breaks where people open up about what really isn't working and what they would do about it. Some FDPMs are even trained to operate the customer's systems, such as working as a call centre agent for a few days. It's the same principle: first-hand experience beats second-hand description.
From there, they design and test rapid prototypes and configurations with the people who will use them, iterating until something works, often using AI tools to move quickly. They document workflows, prototypes and outcomes, which feeds regular prioritisation and makes the trade-offs between solutions explicit. Successful solutions go back to the core platform team to consider for everyone.
To see how this works in practice, imagine the travel retailer integration mentioned earlier had an FDPM embedded from day one. In the first week they sit beside the travel advisors and watch real bookings, before any integration work starts. They notice two things. Advisors don't book in a straight line: they dip in and out of different parts of the process as the conversation unfolds with the holidaymaker. They also skip past the upsells page to get to checkout, so the opportunity is usually missed.
When the FDPM asks why, it surfaces an insight about buyer psychology: the booking is only one moment in the holidaymaker's journey, and the advisor is far more interested in learning about the experience the customer wants overall than in selling add-ons at the point of payment. So rather than cramming upsells into the booking flow, the FDPM works with the FDE to design a "hub and spoke" journey that lets advisors move freely between sections, and a workflow to send the upsell offers by email after booking, when they fit the experience the customer described. Then comes the product judgement: is this specific to this retailer, or do other customers book the same way? If it is common, the FDPM takes the evidence back to the core platform team and recommends changing the default for everyone.
Day to day, the FDPM works closely with the customer's team and a small group of their own. The product trio is typically the FDPM, a Forward Deployed Engineer and a core platform PM, who is the link back to the product. Stand-ups, prioritisation sessions and workshops keep everything aligned and moving together.
How is a Forward Deployed PM different from a traditional PM?
The main difference is what each role owns. A traditional PM owns a product, while an FDPM owns outcomes for a customer account.
The table below explores the main difference in more detail.
How is it different from a Forward Deployed Engineer, solutions architect or consultant?
Several neighbouring roles overlap with the FDPM, and the distinctions are mostly about what each role owns:
- Forward Deployed Engineer: the FDE owns the "how", writing and deploying the technical solution. The FDPM owns the "what" and "why" for the account.
- Solutions architect: designs the best implementation of the existing product for a given customer. The FDPM decides how the product itself should change based on what those implementations reveal.
- Consultant: tends to make recommendations and move on. An FDPM stays embedded until the product is delivering value for the customer, is accountable for the results, and has a duty to feed learning back to the product.
- AI product manager: builds AI features for a market of customers. An FDPM focuses on making the product work for specific customers.
A note of caution: some of this is relabelling. According to an article on a16z’s Substack by Ben Hollands, Palantir used the title to raise the status of customer-facing roles that were traditionally treated as replaceable help, a move the article calls ‘title arbitrage’. That means the title alone tells you little, so read the job description rather than the title to make your own judgement about the role.
What skills do you need to be a Forward Deployed PM?
Start with the PM fundamentals: solving problems creatively, prioritising by impact, owning discovery and delivery, and telling apart a customer's stated request, their actual problem and what the platform should do. Then add three things:
- Technical depth. Enough to debate architecture and feasibility with engineers and to read logs and data directly rather than waiting for a report. For AI products that means a working understanding of models, evals, guardrails, hallucinations and data structuring, plus hands-on prototyping with different models and agent workflows. You don't need to ship production code, but you do need to hold your own in the room.
- Commercial judgement, and the ability to say no. Deciding what stays custom and what goes to the core team is the heart of the role. One suggested discipline is to set the bar in advance, such as the same need appearing in several unrelated accounts, so the roadmap isn't captured by whoever shouts the loudest. Declining a paying customer's request while keeping the relationship intact is a core skill.
- Relationship skills. Communication, negotiation, persuasion and trust-building, with people at every level: comfortable presenting to executives and just as comfortable discussing detail with their engineers. A knack for navigating organisational bureaucracy such as procurement, security reviews and customer politics also helps.
What should you ask before taking a Forward Deployed PM role?
Because the role varies so much between companies, what you ask matters more than the title. Here are the key things you need to know before accepting:
- If I need a feature in the core platform, how do I get it onto the backlog?
- How much engineering capacity is reserved for the initiatives I refer back?
- How will my performance be measured?
- How empowered am I to build custom features and configurations?
- Do I have the authority to make core product commitments, and will feature teams honour them?
Also weigh the trade-offs honestly. The upside is exposure to a range of customer problems and settings, and fast learning, especially in AI. The downsides are that depth on one account can come at the expense of long-term product strategy, that you can be left delivering on promises made elsewhere in the company, and that being very close to one project can make it hard to see the wider product.
Looking back at that shop, our problem was never a lack of smart people, but rather the distance from the problem to be solved. The FDPM is the role designed to close that.
