Over the past two years I have watched the "agile delivery" layer of the org chart quietly thin out. Scrum Masters, agile coaches, delivery leads, and in some places standalone program managers are being cut or folded into other roles. This started before the current AI surge, but AI has accelerated it. When a model can draft the status update, summarize the standup, and flag the at-risk ticket, the pure coordination job gets harder to justify as a job.
What I find more interesting than the cuts is what is growing in their place. And one of the fastest-growing roles in tech right now is not a product role at all. It is an engineering one. I think there is a product-side version of it emerging, and most companies have not named it yet.
How organizations are handling the flattening
There is no single playbook, but three patterns show up over and over.
The most common is to absorb the work into engineering. In early 2023, Capital One eliminated roughly 1,100 roles in its "agile" job family, with the reasoning that a mature organization should "integrate agile delivery directly into core engineering practices." The coordination did not disappear. It moved into engineering and product manager roles (Source: Banking Dive).
The second is to centralize. Companies like Google and Apple run a central Technical Program Management office, pulling TPMs out of individual squads into a shared function that reports into senior engineering leadership and owns release management, cross-team coordination, and shared process. Large organizations usually land on a hybrid: central standards, embedded execution (Source: Functionly).
The third, and the one I am watching most closely, is to collapse the roles into a hybrid builder. LinkedIn is ending its long-running Associate Product Manager program and replacing it with an Associate Product Builder track, training people to code, design, and manage a product end to end, working in small cross-trained pods. The bet is explicit: the entry-level coordination and admin work that junior PMs and program managers used to do does not survive AI (Source: AOL).
The roles the AI age is actually creating
Underneath all three patterns, a handful of new roles are forming. On the product side I see two.
The Product Builder fuses PM, design, and engineering into one person who takes an idea to a shipped prototype. That can mean building it directly in tools like Cursor or Claude Code, or coordinating with other teams for the data, APIs, and services a prototype needs, then working with engineering to get it to production. It is a net-new-product role, not a maintenance one.
The AI Product Manager builds models and agents into products. This person knows where models succeed and fail, designs the guardrails, and exercises judgment about model behavior. It is a specialist skill, and it usually needs delivery support around it.
On the engineering side, the role that is exploding is the Forward Deployed Engineer. Job postings for it grew roughly 729% year over year, from about 640 to more than 5,300 in a single year, making it one of the fastest-growing titles in tech (Source: AOL). The title was popularized by Palantir. An FDE is part engineer, part solutions architect. They sit close to the customer and turn AI demos into governed production systems. They are on the engineering team, not the product team.
Which raises the question I keep coming back to. If the FDE is the engineer who turns a rough AI demo into something real in front of a customer, who is the product person standing next to them?
The Forward Deployed Product Manager
I think that person is the product-side counterpart to the Forward Deployed Engineer, and I would call the role a Forward Deployed Product Manager.
An FDPM has the Product Builder skill set, meaning they can build a working prototype themselves, but they point it outward. They sit with the customer or the internal team that will use the thing, they translate a real problem into an AI prototype fast, and then they own that prototype's path into governed production alongside the FDE. The FDE owns the technical outcome. The FDPM owns the problem, the definition of "good," and the judgment about whether the AI behaves well enough to ship.
That is what separates it from the FDE. The FDE is accountable for the system working. The FDPM is accountable for it being the right system, behaving acceptably, for the right user. You need both, and they are different jobs.
It also separates it from the PM roles around it. A traditional PM writes the requirements and hands them off. A Product Builder builds the prototype but is oriented toward net-new products, not the field. An AI PM goes deep on model behavior. The FDPM is the one who is deployed: close to the user, able to build, and responsible for taking something from demo to production without a long relay of handoffs.
What background to look for
I would not look for a classic PM resume. I would look for three things. First, enough technical fluency to build a prototype and to reason about where a model breaks, not just to spec it. Second, real comfort in front of customers or internal users, because this role lives in the field, not in the backlog. Third, judgment about AI behavior: someone who can look at a model's output and decide whether it is good enough to put in front of a real person.
The people who tend to have this mix are engineers who moved into product, solutions or forward-deployed engineers who like the problem-definition side, and technical PMs who have started building with AI tools instead of only writing tickets.
How today's PMs can prepare
If you are a PM now, the coordination work is not vanishing, it is relocating. Someone still has to manage cross-team dependencies, remove risk, hold priorities, and keep the team pointed in one direction. In a flatter org, that lands on the PM or the engineering manager, or it gets dropped and hurts. The skill to build is orchestration on top of building, not instead of it.
So I would start in two places. Learn to build. Get fluent enough with AI tooling that you can produce a working prototype yourself, even a rough one. And get closer to the user, so you are defining problems in the field rather than receiving them secondhand.
There is a real identity shift buried in all of this. For a lot of PMs, the job was defining and deciding, and letting others build. The roles the AI age rewards ask you to do both. That is uncomfortable, and I think it is worth leaning into rather than waiting out.
The titles are still settling. But the shape of the work is already clear: build, deploy, and own the outcome, close to the person who has the problem. Whatever we end up calling it, that is the role I would be preparing for.