PM and FDE: who owns what
Draw the line between a PM and a forward-deployed engineer on a named project, and decide which of one customer's asks belong in the product.
On this page
A PM owns the problem across many customers over quarters; a forward-deployed engineer owns one customer's working deployment over weeks. Every disagreement between the two roles comes back to that difference in horizon, and so does the one argument worth having: which of this customer's asks belongs in the roadmap. The table below is shared with the FDE course word for word, so that both roles are reading the same definitions.
The two columns
| PM | FDE | |
|---|---|---|
| Owns | the problem, the outcome metric, the priority, the spec, the launch | one customer's working deployment: integration, data, prompts, customer evals |
| Horizon | many customers, quarters | one customer, weeks |
| Unit of work | a decision and the document that records it | a system running in the customer's environment |
| Success | the outcome metric moves across customers | the customer is live, using it, and renews |
| Code | reads it and asks the right question | writes it, often on site |
| Customer time | 3–5 interviews a week | embedded, days at a time |
| Writes | PRD, one-pager, decision doc | integration code, runbook, field notes |
The full table has four more columns — solutions engineer, sales engineer, consultant, product engineer — and the FDE course reads those. This lesson reads two.
Reading the rows
Owns. The PM's list is five nouns and none of them is a system. The FDE's is one system with four parts. A PM who starts owning the prompts for one customer has stopped owning the priority for twelve thousand seats; an FDE who starts owning the outcome metric across customers is doing a different job.
Horizon. Quarters against weeks. This is the row that generates the argument. A customer's ask that takes the FDE a week to ship in that deployment can take the product team a quarter to ship for everyone, and the FDE sees a live customer waiting while the PM sees the other 39 of the 40 tenants, who did not ask.
Unit of work. The PM's unit is a decision and the document that records it. The FDE's is a system running in the customer's environment, which is why their week looks the way it does: two days on site, one building, one on the eval, half a day writing.
Success. The FDE's is binary and dated — live, in use, renewed. The PM's is a metric moving across customers, which no single deployment can prove. One customer's renewal is evidence for the PM; it is the finish line for the FDE.
Code. The PM reads it and asks the right question, which is usually where the latency is or what fails when the model refuses. That takes the ability to follow one request through a system, and no more than that. The FDE writes it, often at a desk the customer lent them.
Customer time. 3–5 interviews a week against days embedded. Both are discovery. The PM's 40 interviews a quarter are wide and shallow by design — enough customers to see a pattern. The FDE's embedding is narrow and deep — enough time with one customer to see what the pattern leaves out.
Writes. Each role writes for the other: the PM's PRD is what the FDE builds against, and the FDE's field notes are what the next PRD is built from.
Where they overlap
Four places, which work well when named and badly when not.
Discovery at the customer: both interview, and the mistake is to run two uncoordinated streams of questions at the same support lead. The fix is one interview guide and a shared set of snapshots.
The eval set: the FDE writes the customer's cases, the PM writes the product's. A customer's 200 cases are about their tickets, their policies, their tone; the product's 200 are stratified across tenants. They share a rubric and a grading method, and a case that fails in one is a candidate for the other.
Prototypes: the FDE builds, the PM specifies. A one-day prototype with no spec tests whatever the builder found interesting; a spec with no builder tests nothing.
The roadmap: the one argument, next.
The negotiation: what generalises
A tenant with 1,200 agents — 10% of the 12,000 seats across all customers — asks for every draft to cite the help article it drew on. The FDE can ship it in that deployment in a week, because retrieval already returns the article and the change is a line in the prompt and a line in the UI. The question is whether it goes into the product.
The weak version of the argument is about who is right: the FDE says the customer is waiting, the PM says it is one customer. Both are true and neither is a decision.
The strong version puts it on the same sheet as everything else. Reach: this tenant is 1,200 seats, and of this quarter's 40 interviews, 3 asked for the source and 17 raised trust in drafts without naming a fix: 20 of 40, half, so call it half the 12,000 seats, 6,000, who would use it. Impact 1 on the 0.25–3 scale, because the draft is already acceptable 92% of the time and the citation helps on the 8%. Confidence 50%: the reach is extrapolated from interviews and the impact is a judgement. Effort 2 person-months for a version that works for tenants whose retrieval is not yet wired. RICE: 6,000 × 1 × 0.5 ÷ 2 = 1,500, against the quarter's existing candidates at 2,133, 6,000 and 2,000. It does not make the quarter.
So the decision is both: the FDE ships it in the tenant's deployment this week, because that is what the FDE owns, and the product carries a RICE row at 1,500 that the next five field notes can move. If three more tenants ask unprompted, confidence goes to 80% and the score to 2,400, ahead of the bulk-close candidate. What would change the PM's mind is written on the row, and the FDE knows what evidence to send. The RICE lesson covers why confidence, not impact, is the column that moves.
The two failure modes are symmetric. A PM who takes every field note as a roadmap item ships a product made of one customer's preferences. A PM who takes none of them has a field channel that goes quiet within a month, because an FDE who sends ten notes and gets no row on the sheet stops writing them. The sheet is the reply.
In an interview
The question is "a customer asks for X and the FDE says they can build it this week — what do you do", and the interviewer is testing whether you know what each role owns. The scored answer says the FDE ships it in the deployment because that is their job, then puts the general version on the sheet with numbers, then names the evidence that would move it. Saying the trade-off out loud — "one tenant this week, the product when three more ask" — is what the interviewer writes down.
The mistake that loses points: claiming ownership of the wrong column. A candidate who says "I'd tell the FDE not to build it" has reached into the deployment the FDE owns; one who says "I'd put it straight on the roadmap because the customer needs it" has given away the priority the PM owns. Either answer says the first week on the job will be a turf argument.
Check yourself
1. The FDE's field note says the tenant's agents edit 14% of drafts before sending and the most common edit adds a refund deadline. Is that a customer-specific fix or a product change, and what decides it?
Start as customer-specific: the FDE adds the tenant's refund policy to the context this week. Whether it generalises is a reach question. Pull the edit-before-send rate per tenant; if three or more tenants show the same edit class, it is a product row with confidence 80% and the FDE's fix is the prototype for it. One tenant's 14% is a signal; the same class across tenants is a decision.
2. The FDE has shipped three customer-specific prompt changes in a month and the tenant's eval set is now 60 cases ahead of the product's. Who owns the gap, and what do you do this week?
The PM owns the product set, so the gap is the PM's. This week: take the 60 cases, strip the tenant-specific policy text, and decide for each whether it belongs in the product's stratified set — likely a third do. The rest stay the tenant's; the FDE owns those. Then watch the product set's pass rate: a set that gains 20 harder cases and stays at 92% is better evidence than the old 92% was.
3. A tenant with 300 seats, 2.5% of the base, asks for a feature the FDE estimates at three days. Where does it go?
Into the deployment, this week, if the FDE has the three days — that is their call, not the PM's. On the product sheet it gets a row with reach of 300 unless interviews say otherwise. The product version is not the FDE's three days; at even one person-month, the best case, 300 × 3 × 1.0 ÷ 1 = 900, sits below every existing candidate. Write the row anyway; it is what makes the field note worth sending, and a 300-seat ask that five more tenants of its size repeat is an 1,800-seat one.