Forward Deployed PM
A product decision-maker embedded in someone else's team, on the hook for a shipped outcome.
01It's not
02about AI.
03It's about the impact
04you create with it.
Most companies do not have an AI problem. They have a product judgment problem. Nobody inside the building is close enough to the work to decide what is worth shipping. Decks do not fix that.
So I deploy forward. Inside the codebase, inside the roadmap, on the hook for a shipped outcome. I am also assembling the community of practice around the role.
The model is commoditized. The judgment is not.
Every company now reaches the same frontier models. Advantage no longer comes from access. It comes from how fast a team turns capability into something a customer will pay for, and how well they choose what to build.
That is a product discipline, not an engineering one. It cannot be outsourced to a slide deck, because the decisions that matter get made in the thirty conversations a week no consultant is in the room for.
So you deploy the judgment. Forward. Into the team.
Sits inside the work
Standups, support queue, sales calls, the repo. Not a discovery phase. A deployment. The map comes from sitting in the work, not from interviews alone.
Ships the first thing
A real feature in front of real users, built with the team. Prototypes are the argument. Strategy earned by shipping, not presented.
Rewires how calls get made
Evals instead of opinions. Weekly bets instead of quarterly roadmaps. Those habits stay after the engagement ends.
Leaves the capability behind
Success is your PMs working this way without me. A deployment that creates dependency is a failed deployment.
Is
- Accountable to a shipped outcome
- Hands in the product, not above it
- On the team's calendar, not the client's
- Temporary by design
Is not
- A strategy deck with a readout
- Staff-aug taking tickets
- An AI tooling workshop
- A permanent seat in your org chart
- 01
Strategy that isn't shipped is a hypothesis with a budget.
A roadmap nobody has built against has been tested against nothing. The only credible strategy document is a thing in production and what happened next.
- 02
Proximity beats seniority.
The best call comes from whoever is closest to the customer, the code, and the constraint at once. Most orgs systematically promote people away from all three.
- 03
AI didn't create a new job. It raised the cost of bad judgment.
When building is cheap, choosing is the whole job. Teams that shipped three wrong things a year now ship thirty. Velocity without taste is faster waste.
- 04
A PM who can't prototype is negotiating from memory.
You don't need to be an engineer. You need to put a working version of your argument on the table before the meeting ends.
- 05
Evals are the new spec.
The moment your product contains a model, done becomes a distribution rather than a checkbox. If you can't define good at scale, you haven't defined the feature.
- 06
Consultants are structurally prevented from being right.
The incentive is the renewal and the access ends at the readout. Forward deployment inverts both. You sit inside the team, on the hook, and leave once the capability transfers.
- 07
The role needs a practice, not a guru.
One person's engagements are anecdotes. A group comparing notes across dozens of deployments is a discipline. That is the thing worth building.
One person cannot define a role. A practice can.
Forward deployed engineering got a name, a playbook, and a hiring loop. The product equivalent is being invented right now, in scattered engagements, by people who have not met each other.
This is where the definition gets written in public, and where the people doing the work find each other.
Field notes
Essays from inside live deployments. What worked, what I got wrong, what I'd charge for next time.
What is a Forward Deployed PM?
The canonical role definition, deployment loop, and how FDPM differs from FDE, classic PM, and staff-aug.
What is a Forward Deployed PM?
A forward deployed PM is a product decision-maker embedded in someone else's team, on the hook for a shipped outcome. They own the loop from problem framing through scope, shipping, and adoption—not demos or models alone.
How is a Forward Deployed PM different from a forward deployed engineer?
A forward deployed engineer solves integration—making the product work in a customer's environment. A forward deployed PM solves judgment—deciding what is worth building now that building is cheap, and answering for whether the metric moved.
How is this different from a consultant, staff augmentation, or fractional CPO?
Not a consultant—their access ends at the readout. Not staff-aug—this role decides which tickets should exist, not just takes the queue. Not a fractional CPO—deployment works one altitude lower, in the repo and on one bet at a time.
What does a deployment look like?
Days 0–10 inside the work (standups, support, sales, the repo). Weeks 2–4 ship the first real thing with the team. Ongoing, the operating rhythm shifts to evals and weekly bets. Exit when your PMs can run the loop without me.
Who is this for?
Leaders building AI delivery practices who need a hireable definition; PMs pulled into the field who want a craft, not chaos; and teams where the model shipped but the outcome did not.
Is this site hiring advice or a paid deployment offer?
Both, clearly separated. The definition pages and field notes are public practice material—free to read and reuse. Paid work is embedded deployment: two slots per quarter, outcome-bound, temporary by design. Request deployment if you need an operator.
Tell me what isn't shipping.
Thirty minutes, no deck. Bring the thing your team keeps re-deciding. You leave with a first bet either way.