Hello everyone,
As July 2026 comes to an end, I’m launching a new series about one of the most important operating models emerging in AI: Forward Deployment.
Over the next few editions, I’ll explore the different types of forward-deployed roles and teams, including Forward-Deployed Engineers, Deployment Strategists, and Forward-Deployed Product Managers.
We’ll look at:
why forward deployment is becoming so important,
when companies should use this model,
when they should avoid it,
how to structure and operate a forward-deployed squad,
the playbooks different types of companies can follow,
the skills required for each role,
real examples from the field,
how we use this model inside Iris Labx,
and the latest job opportunities emerging in this new category.
The goal of this series is not only to explain a new set of job titles.
It is to understand a broader shift in how AI products are discovered, built, deployed, adopted, and transformed into scalable platforms.
Today, I want to begin with the role that I believe will become essential alongside every strong Forward-Deployed Engineer:
The Forward-Deployed Product Manager
OpenAI is hiring a Deployed Product Manager for Codex in San Francisco, with a base salary between $220,000 and $330,000 + Equity.
The title matters, but the job description matters even more.
OpenAI describes this person as the product counterpart to Deployment Engineers: someone who works inside strategic customer accounts, identifies expansion opportunities, builds trust with technical and executive stakeholders, removes deployment blockers, and translates field insights into clear product opportunities.
This is not a traditional Product Manager sitting at headquarters and managing a backlog.
It is a PM operating at the intersection of:
product, technical deployment, customer strategy, and execution.
The role is expected to work directly with engineers, integrations, MCPs, tooling, executives, and customer workflows. It combines technical fluency, product judgment, commercial awareness, and hands-on problem-solving.
To me, this is a strong signal.
As AI products become more powerful, the bottleneck is shifting away from simply building features. The new bottleneck is helping customers integrate these capabilities into real workflows, achieve measurable outcomes, and expand adoption across their organizations.
Forward-Deployed Engineers cannot and should not own that entire responsibility alone.
They need a product counterpart.
That counterpart is the Forward-Deployed Product Manager.
And this is exactly why I am starting this series now.
Because we should not leave Forward-Deployed Engineers alone to identify the right business problem, redesign the customer workflow, align stakeholders, drive adoption, measure value, and decide what should become part of the core product.
For years, product managers have been taught to work from the center of the organization.
They collect feedback, prioritize features, write PRDs, align stakeholders, and help engineering ship product. That model made sense when the hardest part of building software was building the software itself.
But AI is changing that.
Why this role exists now, specifically
The bottleneck in AI stopped being model access a while ago. It’s deployment.
Nobody needs another demo. What they need is a system that survives contact with their actual workflow their approval chains, their exceptions, their one employee who does everything from a spreadsheet nobody else has opened in three years.
And here’s the part that makes this a product problem, not just an integration problem: most customers can’t tell you in advance what the right AI workflow looks like. They can describe the pain. They cannot spec the fix. Which means the product can’t be designed at headquarters and shipped in it has to be discovered on-site, in the gap between what the model can do and what this specific team will actually trust.
That discovery work is the FDPM’s entire job.
What a Forward-Deployed Product Manager actually does
A lot of people hear “forward-deployed” and think mostly about engineering.
But if you leave the product work undefined, the engineer is forced to do too much:
discover the business problem,
align stakeholders,
decide what matters,
define success,
drive adoption,
and figure out what should become reusable.
That is not sustainable.
The FDPM exists to own that layer.
At a high level, the FDPM owns three things:
1. Problem and opportunity
The FDPM identifies the workflow worth solving.
Not the easiest problem.
Not the loudest request.
The highest-value workflow tied to a real business priority.
That means asking:
What is the company trying to improve?
Where is time being lost?
Where is revenue being blocked?
Where is quality weak?
Where are teams overloaded?
Where can AI actually change the operating model?
A strong FDPM does not start with “Where can we put AI?”
They start with:
“What outcome is valuable enough to justify deployment friction?”
2. Product and workflow
Once the opportunity is clear, the FDPM maps the current workflow and designs the future one.
This includes:
observing how work is really done,
understanding systems, approvals, and exceptions,
deciding where the model should assist vs act,
defining success criteria,
setting scope,
designing human-in-the-loop behavior,
and writing the deployment brief.
This is not traditional feature PM work.
It is workflow design.
The FDPM is not just specifying a screen.
They are specifying how work changes.
3. Deployment and leverage
The job does not end when the first version works.
The FDPM helps drive:
pilot sequencing,
user adoption,
trust,
training,
rollout,
measurement,
and productization.
That last part matters a lot.
A great FDPM is not only asking:
“Did this customer deployment succeed?”
They are also asking:
“What is the reusable version of what we just learned?”
That is how an AI company avoids becoming a services business disguised as a product company.
The distinction that actually matters: judgment, not coordination
There’s a weak version of this role and it’s easy to slide into. The weak version tracks tasks, relays feedback between the customer and engineering, and schedules the syncs. That’s a project manager with better branding.
The real version makes calls: which workflow matters, what belongs in the first version, when to cut scope, when to walk away, what goes back into the roadmap and what stays exactly where it is. An FDPM who isn’t making unpopular decisions on a regular basis probably isn’t doing the job.
Which is also why the obvious hire a strong PM from a good SaaS company often isn’t the right one. Ask a great SaaS PM to look at one customer’s workflow and describe the version that would work for the next ten, and most of them will hand you a better version of the one workflow in front of them. That’s not a skills gap. It’s what their instincts are trained to reach for. The people who are actually good at this job reach for the structure underneath the request, almost by reflex.
What makes a great FDPM
This role is hard because it sits in the middle of several worlds at once.
A strong FDPM needs to be able to operate with:
- Product judgment
They must know how to identify the real need, define the right scope, and avoid overbuilding.
- Workflow intelligence
They must understand how real work happens, including edge cases, handoffs, exceptions, and approvals.
- Technical fluency
They do not need to be the primary builder, but they need enough technical depth to work directly with engineers on:
APIs,
tools,
data flows,
agent behavior,
evaluations,
permissions,
and deployment constraints.
- Business orientation
They must connect the work to actual economic value: cost, speed, revenue, risk, capacity, quality.
- Adoption instinct
A deployment is only real if people trust it, use it, and integrate it into daily work.
- Generalization ability
This is maybe the most important one.
The FDPM has to see beyond the one customer request in front of them and identify the deeper abstraction underneath it.
That is what turns field work into product.
The metric that keeps everyone honest
Revenue and adoption can both be climbing while the business is still in trouble, if every deployment still starts from a blank page. The one number worth watching closely is whether bespoke effort is falling as the number of deployments rises. If it isn’t, no amount of contract growth changes what kind of company you’re actually running.
Where this is heading
The old PM job optimized for prioritization: pick the right thing from a list of things you could build. The new version optimizes for something closer to orchestration customer context, workflow design, model behavior, approval logic, adoption, and the discipline to turn field learning into leverage instead of just closing the ticket.
That’s a bigger job than the one “product manager” used to describe. It’s also a lot closer to where the value is actually getting created right now.
We’re early on this role. Most companies hiring for it don’t yet have a clean job description, a clear success metric, or a good sense of what a bad hire looks like until eighteen months in. That’s exactly why it’s worth understanding now, before the title gets diluted into meaning whatever a given company needs it to mean this quarter.
The real operating model of an FDPM
A simple way to think about the role is through six phases.
1. Select
oose a high-value workflow tied to an executive or operational priority.
The output is not a list of ideas.
It is an outcome thesis.
For example:
We believe that helping support agents investigate billing disputes with an AI-assisted workflow will reduce handling time by 35% while maintaining quality and compliance.
2. Discover
Observe users and map the current state.
What tools do they open?
What decisions do they make?
Where do they wait?
Where do errors happen?
Where do they rely on tribal knowledge?
3. Define
Turn the workflow into a deployment brief.
This includes scope, success criteria, autonomy level, exceptions, evaluation logic, and rollout assumptions.
4. Pilot
Launch the smallest useful deployment.
The goal is not a polished platform.
The goal is a narrow, working workflow that proves value.
5. Adopt
Drive usage and workflow change.
The FDPM tracks trust, feedback, completion, overrides, and real usage behavior.
6. Productize
dentify what should become reusable.
Move from:
We solved this for one customer.
To:
We created a capability that will make the next five deployments easier.
How to know if your FDPM model is working
Because this role sits close to deployments, it is easy to confuse activity with progress.
A serious FDPM organization should track at least four things:
1. Customer value
Did the deployment improve revenue, cost, speed, quality, or risk?
2. Adoption
Are users actually using it?
Are workflows being completed?
Is trust increasing?
3. System quality
Is the workflow reliable?
Are escalations correct?
Is performance stable enough for production use?
4. Product leverage
Is each deployment making the next deployment easier?
This last metric is critical.
If customer value is rising but bespoke work never falls, you are still consulting.
That is the trap.
The FDPM is one of the people most responsible for preventing it.
The most common failure modes
There are a few recurring mistakes I expect many companies to make.
1. Solving the easy problem instead of the valuable one
The customer gives the team a convenient problem, not the strategic one.
2. Turning the FDPM into a project manager
The person coordinates work but does not own the outcome.
3. Generalizing too late
Each deployment stays custom, and the company keeps rebuilding the same thing.
4. Celebrating the demo
The team confuses presentation quality with product value.
5. Measuring only model quality
The model can perform well while the workflow still creates little business value.
The FDPM exists to keep the company honest on all of these.
The future product manager in AI will not just manage features.
They will manage outcomes.
They will work closer to customers, closer to workflows, and closer to the boundary between the field and the platform.
They will not be judged only by what ships.
They will be judged by what gets adopted, what creates value, and what compounds into product leverage.
That is the Forward-Deployed Product Manager.
And I think we are only at the beginning of this role.
Some jobs opening now :
OpenAI — Deployed Product Manager, Codex, San Francisco. The position pays $220,000–$330,000 in base salary, plus equity, and operates as the product counterpart to Deployment Engineers.
Scale AI — Forward Deployed Product Manager, Enterprise, New York. The FDPM owns production outcomes across strategic enterprise accounts and translates field reality into product signal for the platform team.
Scale AI — Forward Deployed Product Manager, Public Sector, New York or Washington, DC, working on military planning and operational AI deployments.
Scale AI — Forward Deployed Product Manager, Enterprise, London, building AI applications with major companies and converting successful solutions into repeatable software.
Abridge — Forward Deployed Product Manager, San Francisco, with compensation of $260,000–$290,000 plus equity. The role leads deployment pods inside major health systems.
Fireworks AI — Forward Deployed Product Manager, San Mateo, helping customers turn technical requirements into successful deployments on Fireworks’ generative-AI infrastructure.
Cresta — Forward Deployed Product Manager, AI Agent, remote in the United States, with listed OTE of $170,000–$280,000 plus equity.
Cresta — Associate Forward Deployed Product Manager, remote in the United States, with listed OTE of $130,000–$170,000 plus equity—one of the clearest entry points into the profession.
Gauss Labs — Forward Deployed Product Manager, Seoul, leading AI deployments in semiconductor manufacturing and managing collaboration between customers, FDEs, data scientists, and AI researchers.
Gradial — Forward Deployed Product Manager, remote in the United States, helping enterprise marketing teams deploy AI across complex technology stacks and workflows.
Causal Labs — Forward Deployed Product Manager, leading cross-functional deployment teams and owning outcomes for strategic customers in physical-world AI.
Ode with Anthropic
Ode is hiring Forward Deployed Product Managers across several locations: