# The FDE owns the "how", the PM owns the "what": splitting a customer blocker in two > OpenAI is hiring a Deployed PM for Codex, a product manager who works inside customer accounts. The role shows FDEs which problems they should fix themselves and which belong with the product team. Original: https://fdetimes.net/en/guides/fde-how-pm-what-customer-blockers/ Picture the third week of a deployment. The integration works and the data is flowing. Then the customer's technical lead asks: "Why can't your product do this?" You have two options. You can write a few hundred lines of code yourself to fill the gap, or you can say "I'll pass that to the product team". Either answer can be right, and either can be wrong. Knowing which to give means understanding where the FDE's job ends and the Product Manager's begins. OpenAI is a useful case: it is hiring for a role that sits right on that line, a Deployed Product Manager for Codex. ## Who answers the "why"? Scaler separates the two roles by how success is measured. An FDE is judged on whether the deployment works; a PM is judged on whether the team built the right thing. On that split, the PM decides what to build and why, and the FDE makes it work in the customer's reality. Mind the Product takes this split inside the customer. A Forward Deployed PM (FDPM) is hired by the vendor but works within the customer's organisation: employed by one company, embedded in another. Instead of owning a product, they own outcomes at an account. When the two work side by side, the FDPM owns the "what" and "why" for that account and the FDE handles the technical build. The FDPM also carries what they learn back to the core product team, so that other customers benefit. The technical lead's question above actually contains both parts. "How do we make it work" is your job. "Should we build it, and why" is a product decision. ## What OpenAI's job postings suggest about the gap OpenAI describes its Forward Deployed Engineering team as one that works with customers to turn research breakthroughs into production systems. The posting for the manager of that team also asks for what works to be packaged into tools, playbooks and roadmap inputs. In other words, FDEs there are already expected to bring customer lessons back to the product. The Deployed PM posting does not say why the role was created. Read alongside the FDE team's posting, though, one reasonable inference is that bringing lessons back takes real effort, and few engineers can debug a pipeline at midnight and also write a polished product analysis. That is an inference, not something OpenAI has said. What the posting does say is that the person acts as a product lead inside strategic customer accounts, helping customers adopt and expand their use of OpenAI's products. They work closely with Deployment Engineers and the GTM team, and turn customer needs and technical blockers into clear product feedback and execution direction for internal teams. **Key point:** The FDE makes the product work at the customer; the product side decides whether the product should change. ## One blocker, two questions Take a concrete case. You are deploying a coding agent at a company with hundreds of internal repos. Pull requests opened by the agent keep getting blocked by CI because the company has its own lint rules that the agent does not know about. The "how" question is yours. You can load the lint configuration into the agent's context, add an auto-format step before the PR is opened, then measure the share of PRs passing CI before and after the fix. By the end of the week the deployment works, which is exactly what an FDE is judged on. The "what/why" question is still unanswered. Is this one customer's quirk, or will every enterprise customer hit it? If you stop once the fix is in, the product team will never know the problem exists. PostHog points out why this gap opens on its own: FDEs do discovery and development one customer at a time, and generality comes second. Generalising the lesson for other customers is the core product team's job, and they can only do it if the lesson reaches them. ## How do you know a problem recurs? Agile Lab's FDE handbook describes a habit worth copying: whenever an engineer records a customer problem, they create a traceable work item stating the problem, the value to the customer and the expected outcome. Those items turn "does this recur?" into a search rather than a hunch. In practice, if your team uses Jira, Linear or any other tracker, tag each item with a problem type, such as `ci-policy` or `repo-conventions`, along with the account name. When you hit the lint blocker, filter by that tag and count how many different accounts already have a similar item. If the tracker has nothing, ask directly in the FDEs' shared chat channel: "Has anyone seen the agent blocked by CI because of a customer's own repo conventions?" Two or three "yes" replies are enough to turn your note from one customer's complaint into a hypothesis worth examining. Once you have a count, the note you send back should be short and structured: ```text Blocker: agent PRs blocked by CI because of internal lint rules Impact: [PRs blocked / total PRs in 1 week — real measurement] Temporary workaround: load lint config into context + format step before opening the PR Recurrence: [number of accounts with items tagged ci-policy] Proposal for product: allow repo conventions to be declared at organisation level ``` If the company has a Deployed PM, this note is exactly what they need to get started. If it doesn't, the note is the product work you are carrying yourself. ## Do it yourself: separate "how" from "what" in every meeting Start with a two-column note-taking habit. Each problem the customer raises goes into one of two columns: what needs doing to make the system work, and the question of whether the product should be different. Most problems have something in both. Resolve the "how" column fast and measure the result, because that is your yardstick. For the "what/why" column, create a tagged work item, look for items with the same tag before writing a proposal, then send the note to the Deployed PM if there is one, or to the PM who owns that area, with a date to review it. Agile Lab's handbook describes the purpose of the whole process as shortening the feedback loop between customer evidence and the product engineering team. ## Common mistakes The most common mistake is turning a workaround into a product of its own. FDEs who code well can easily build an entire layer of features that only works at one customer, and that layer becomes a maintenance burden nobody owns. The opposite mistake is pushing everything to product, including things you could fix yourself in an afternoon, which costs you the customer's trust. The third mistake is harder to spot: sending feedback of the "the customer wants feature X" kind. That sentence has no impact, no workaround and no count of accounts with the same problem. The product team can read it and still be unable to decide anything. ## Which role suits you? When reading job postings, look for phrases such as "partner closely with Deployment Engineers" or "product feedback". They tell you whether you will have a product counterpart or have to carry both columns yourself. In FDE postings, phrases such as "roadmap inputs" signal that the feedback loop to product is part of the work you will be judged on. Whichever path you take, the ability to write a note like the template above is valuable. On your CV, describe a time you turned a customer blocker into a product change, with before-and-after measurements and the number of customers who benefited. "Why can't the product do this?" will be asked again at every customer. The people who earn trust are the ones who know when to fix it themselves and when to take the problem back for the product team to decide. **Try this week:** - Take the most recent blocker you hit at a customer and rewrite it using the five-line template above, keeping the workaround separate from the proposal for product - Search your team's ticket tracker for items of the same type as that blocker and count how many customers it has appeared at - Add a line to your CV about a time you turned a customer problem into a product change ## Sources - [What is a Forward Deployed Product Manager, anyway?](https://www.mindtheproduct.com/what-is-a-forward-deployed-product-manager-anyway/) - [Deployed Product Manager, Codex @ OpenAI](https://jobs.khoslaventures.com/companies/openai/jobs/76966806-deployed-product-manager-codex) - [Manager, Forward Deployed Engineering - OpenAI](https://www.builtinnyc.com/job/manager-forward-deployed-engineering/9872042) - [Forward Deployed Engineer vs Product Manager: Where the Roles Split (and the Rise of the FDPM)](https://www.scaler.com/topics/forward-deployed-engineer-vs-product-manager/) - [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer) - [Forward-Deployed Engineering](https://handbook.agilelab.it/Witboost_ProductDevelopment_ForwardDeployedEngineering.html)