Cagan Lists Three Product Roles. The Fourth Is the One Hiring Fastest.

Marty Cagan sorts the product role into three definitions and gives each a future. The fastest-growing product role of 2026 is in none of them. This is a Rewrite: his claim, the row his table cannot hold, and the definition that holds it.

The short version

Cagan's November 6 post says the operating model drives the role: the project model produces the feature team product manager and the product owner, the product model produces the empowered team product manager. Under AI, the product owner "is already being phased out," the feature team product manager's future "is least clear," and the empowered team product manager is in high demand and "necessarily at the center of the eval process for a probabilistic product." His footnote concedes that many, if not most, companies will never move to the product model. The forward deployed engineer, a vendor's engineer inside one customer, accountable for the outcome there, building to earn against a problem the customer named, is the feature team product manager's job with an eval bolted on, and per Chris Taylor in TechCrunch there are about 17,000 in the US, demand is up 2,100%, and about 2,000 can deliver real ROI. The project model did not die; its companies became the customers and the role moved to the vendor's side of the contract. The eval sits with whoever can see the customer's cases, which is how Colin Jarvis's team had 60 percent at scoping, not with a PM at headquarters. The rewrite: the operating model does not drive the seat, the loop does, and the Product OS defines five seats by what each owns in one loop from customer problem to adoption, with the FDE owning the customer edge.

What Cagan published

The post is the narrative form of his keynote for the 2026 Product Leader Summit, and the argument is tidy. The reason the product role has so many definitions is that there are different operating models for creating products, and the operating model drives what roles and skills are needed.

In the project model, the roadmap holds prioritized features and projects, each a hoped-for solution to a usually unstated problem, and success is shipping it. That model produces two roles. The feature team product manager marshals and coordinates the resources to get the solution designed, built, tested, and shipped, which Cagan calls essentially a project management role, build to earn. The agile product owner manages the delivery backlog and coordinates with engineers around sprints.

In the product model, product leaders assign problems to solve with a desired outcome, and success is achieving the outcome. That produces the empowered team product manager, whose primary responsibility is discovering a solution that will achieve it, bringing deep knowledge of the market, domain, and customer, and broad knowledge of business viability. Build to learn.

Then the futures. Companies are racing to use agentic AI to automate delivery into a software factory, so there is less need for feature team product managers, and "it is less clear how many may still be needed." The product owner role "is already being phased out" and "will resolve itself." The empowered team product manager is in especially high demand, because the bottleneck is no longer delivery but determining what to build, and because for probabilistic products the viability risks of unit economics, liability, safety, and compliance make that person "necessarily at the center of the eval process."

The footnote is the sentence I keep returning to. As much as Cagan would love to believe companies will abandon the project model, "I know that for many, if not most, companies, it will likely never happen," primarily out of a desire for predictability.

He closes with Shreyas Doshi: product managers who viewed their main job as executing are finding it harder to get hired at top companies than those who viewed it as making the product successful.

The row the table cannot hold

Take the feature team product manager's job description as Cagan writes it and change one word. A solution the customer prescribed, with a date, success defined by shipping it, the role marshalling whatever is needed to get it live, including writing the docs and committing the code. Now make the employer the vendor rather than the customer, and add that the person is accountable for the outcome at that customer rather than for the ship.

That is a forward deployed engineer. The handbook chapter The Forward Deployed Engineer Is a Product Builder in Disguise traces the role from Palantir's four vintages, and the thread that survived every vintage is customer accountability. It is build to earn, at one customer, against a problem the customer named, which is exactly the project-model work Cagan says is being automated away.

The market disagrees with the forecast. 2,000 of 17,000: The FDE Shortage Is a Product Problem carries Chris Taylor's numbers from TechCrunch: about 17,000 forward deployed engineers in the US, demand up 2,100%, and roughly 2,000 who can build a flagship AI feature rather than roll a tool out. The role whose future Cagan calls least clear is the one every AI vendor is hiring for, under a title his taxonomy does not contain.

The footnote explains why. The companies that will never move to the product model, the ones that want predictability, did not stop buying software. They became the customers of the companies that build it, and they buy it the way the project model always bought: a named outcome, a date, and someone accountable for landing it. The project model did not die when the product model arrived. It moved to the vendor's side of the contract, and the person running it got a new badge.

Where the eval sits

The second claim is narrower and I think it is wrong in a way that matters for org design.

Cagan puts the empowered team product manager at the center of the eval process for probabilistic products, because the PM carries the viability risks. The eval I have watched work is not written at headquarters. The FDE Writes the Eval: Almost Right Has a Number makes the case: the eval is the deployment artifact, one versioned set of the customer's real cases with agreed-correct answers, written by the forward deployed engineer before the build, with the customer's experts supplying the labels. That is how Colin Jarvis's team could say 60 percent at scoping rather than discover it at go-live.

The eval sits with whoever can see the customer's cases. For a probabilistic product sold into an enterprise, that is the engineer in the room, and the PM at headquarters sees the rows only when they travel back. Put the PM at the center and you have the eval written by the person with the least access to the data it needs.

The rewrite

Cagan's premise is that the operating model drives the role. My rewrite: the loop drives the seat.

The Product OS on falkster.com runs one loop, from the customer problem to adoption, and the Product Leadership thesis is that one loop needs one owner. The CPO owns the whole outcome, and four seats run the loop together, each defined by what it owns in it. Product owns the spec and the build. Design owns behavior and the quality bar. Product marketing owns the story and adoption. Forward deployed engineering owns the customer edge: deployments that land, and field signal back into the product in hours, not quarters.

None of those definitions mentions an operating model. They say what the seat owns. Define the role by the model and you get three names and a disappearing act, with the growth role missing. Define it by what it owns in the loop and the fourth seat is obvious, and so is why it is hiring: when building is cheap, the scarce person is the one who guarantees the result where the customer lives.

I argued in Cagan Built the Church. I Argue We Don't Need One. that the product operating model was built to ration a build capacity that AI erased. This post is the other half. The project model it was built to replace survived the same shift, on the vendor's payroll, and it is where the eval gets written.

Doshi's line holds either way. Execution was never the job; the outcome was. The forward deployed engineer is the execution role that got handed the outcome.

This week, if you are writing the 2027 org plan: count the people in your company who are accountable for an outcome at a named customer and are not in the product org chart. That is the fourth row. Give it a seat before Cagan's table gives it a future.

Related answer: Does Marty Cagan's three-role model of the product job have a place for the forward deployed engineer?

Sources: Marty Cagan, "AI and the Future of the Product Role," SVPG, November 6, 2026, read in full; every quoted phrase, the three role definitions, the footnote, and the Shreyas Doshi quotation are as Cagan published them. Falk Gottlob, "2,000 of 17,000: The FDE Shortage Is a Product Problem" (the 17,000, 2,000, and 2,100%, per Chris Taylor in TechCrunch as reported there), "The FDE Writes the Eval: Almost Right Has a Number" (Colin Jarvis's 60 percent at scoping, as reported there), "Cagan Built the Church. I Argue We Don't Need One.," and the handbook chapter "The Forward Deployed Engineer Is a Product Builder in Disguise." The five seats are as defined in the Product OS on falkster.com.