Site index. Esc or click to close BriefThe role, the thesis, the positions Field notesWriting from inside live deployments PracticeRole definition and craft Request deploymentTwo slots per quarter
[ ← ] Field notes
EntryNo. 01
Filed
Read6 min
TagJudgment

FDE ships the model. FDPM ships the outcome.

FDE gets AI running in the field. FDPM owns whether that system becomes a defendable business outcome.

The industry learned to put strong engineers next to the customer. That was necessary. It is not sufficient.

A Forward Deployed Engineer can get a system running in a hostile environment. A Forward Deployed PM owns whether that system becomes an outcome. A decision that sticks, a workflow that changes, a metric that moves for a reason you can defend.

This essay is the working thesis for forwarddeployedpm.dev.

The failure mode everyone recognizes

You know the pattern:

  1. Exciting pilot
  2. Model “in production”
  3. Demo day
  4. Usage flatlines
  5. No progress on outcomes; Real dollars spent
  6. Retro blames change management, data, or “the business”

Often the missing owner was never the model. It was problem framing and adoption under real constraints. Incentives, process, political capital, and what “done” meant.

Split the work without splitting accountability

  FDE strength FDPM strength
Environment Make it run where the customer lives Decide what is worth running
Scope Implement under constraints Cut and sequence under constraints
Success Reliable system Changed behavior / outcome
Risk Over-building the wrong thing beautifully Pretty strategy with no field truth

The partnership fails when the PM becomes a note-taker, or the engineer becomes the only product brain by default.

A minimum FDPM operating loop

  1. Frame. Written problem, non-goals, who feels pain
  2. Decide. Options, kill criteria, what you refuse
  3. Ship. Smallest thing that can be adopted, not only demoed
  4. Adopt. Owner, workflow, metric, review cadence
  5. Productize or park. What becomes platform vs. stays bespoke

Artifacts that beat vibes

  • Decision memo (one page is enough)
  • Kill criteria dated before the build
  • Adoption metric that is not “number of prompts”
  • Explicit “not doing” list

What this is not

  • Not “PM who likes customers”
  • Not SE with a new title
  • Not anti-engineering. The opposite: protect engineering time for outcomes that matter

Closing

If your AI practice only rewards models shipped, you will get models shipped. If you want impact, someone has to own the loop after the demo. That someone is the Forward Deployed PM, by title or by necessity.

Next: What is a Forward Deployed PM? · About

All field notes [ ← ]