Product Management Isn't Dead. It Escaped the Product Team.

Aaron Levie recently described a role emerging in enterprises. Someone who maps workflows, designs the future state, and orchestrates AI agents across a function. He called it the "agent operator."

I agree with the observation. The name is half right.

This isn't a new role. It's product management. It just doesn't live in R&D anymore. And the cleaner title for what it becomes is a Product Builder who is also an Agent Operator. Product Builder because they ship working systems, not specs. Agent Operator because the system they ship is now mostly agents. Drop either word and you're describing a different, weaker role.

The short version

Product management spent twenty years confined to R&D because that was the only place building happened. Agents removed the constraint. Every function deploying AI workflows is now structurally a product team. Finance, legal, HR, sales ops, support, RevOps, procurement, all of them are designing systems where humans and agents share the work. Aaron Levie named the person doing this an "agent operator." I'd name them a Product Builder who is also an Agent Operator, because the job is shipping working systems where humans and agents share the work, not just running the agents. The collaboration model changed too. PRDs made sense when cycle times were weeks. Agents collapsed the loop to minutes, and the most productive pattern I'm seeing is a Product Builder and a developer building synchronously, no spec in between. Underneath all of it sits an unfinished layer most companies haven't thought about: the shared context substrate of persistent data and business logic that determines whether your agents are smart or stupid. The companies that compound through this transition are the ones treating context as an architectural problem, not a per-team problem.

If you want the present-tense rebuild this rests on, see The CPO Mandate 2026, Service-as-Software CPO Field Guide, and The New Org Chart for AI. For the role definition this assumes, see the PM Standard.

R&D figured this out first

For two decades, product management was the discipline of mapping problems, defining workflows, deciding where human judgment mattered, and iterating with engineers to ship something better than what existed. That work was confined to product teams because that was where the building happened.

That constraint is gone.

Every function deploying AI workflows is now, structurally, a product team. Finance is shipping agents. Legal is shipping agents. HR, sales ops, support, RevOps, procurement, all of them are designing systems where humans and agents share the work, where the workflow is the product, and where iteration speed determines who wins.

The pattern that R&D evolved into over the last two years is now repeating across the entire P&L. Same problem shape. Same skill requirements. Different org chart.

Name the role properly: Product Builder + Agent Operator

Aaron Levie called the person doing this work an "agent operator." That's half the role.

The cleaner title is Product Builder who is also an Agent Operator, because the job is not "run agents." The job is ship working systems where humans and agents share the work, in production, with measurable outcomes. Both halves of the title carry weight.

Product Builder is the half that ships. They prototype, they own evals, they reason about cost and latency, they take a real outcome to production. This is the role I've written about as the successor to the classic PM in the PM Standard and 200 PM Job Descriptions Reviewed. It's the part of the role that makes sure something actually works for a real user.

Agent Operator is the half that operates the substrate. They map the workflow end-to-end, they design which steps are deterministic versus agentic, they tune the prompts and the routing, they own quality when the system is mostly software acting on its own. This is the new half that Levie is naming, and that finance and legal and HR are racing to staff.

Drop either word and the role gets weaker:

• A pure Agent Operator without product taste ships brittle workflows nobody adopts. They optimize for the agent running cleanly. They don't optimize for the customer or the cost or the next iteration.
• A pure Product Builder without agent fluency ships SaaS in 2026. They write good PRDs about agentic features. They hand them off. Three quarters later their product gets disrupted by someone who built the same thing as a workflow.

The role that compounds is both. That's the title I'd write on the JD. That's the title I'd hire for. That's the title I'd promote into.

The collaboration model changed

Here is where the conversation gets interesting, and where most companies are about to get this wrong.

The PRD made sense when cycle times were weeks. You wrote a spec, handed it off, and waited. Async was the only option, because building took long enough that synchronous collaboration would have wasted everyone's time.

Agents collapsed that loop. The cycle time isn't weeks anymore. It's minutes. You prototype a workflow, the agent runs it, you watch it fail in a specific way, you adjust the prompt or the data or the routing, and you try again. The feedback loop is too fast for documents.

The most productive pattern I'm seeing isn't someone writing a spec and throwing it over the wall. It's an operator and a developer sitting together, building synchronously, because anything else leaves value on the table. The PRD as input is dead. The PRD, if it exists at all, is now an output, a record of what was decided, written after the fact, not before.

For more on why specs as inputs don't survive this transition, see Kill the PRD: The Prototype Is the Spec and Death of the PRD.

This shift is the part most "agent operations" conversations miss. It's not just that there's a new role. It's that the entire collaboration model between business operators and builders has compressed into something that looks much more like pair programming than product specification.

The layer underneath all of it

There's one more piece, and it's the part most companies haven't even started on.

Agents are only as good as the context they can access. That context is two things: data and business logic. Knowledge bases, historical records, reference data on one side. Rules, policies, approval chains, compliance gates on the other.

The foundational design decision is what to store persistently versus what agents compute at runtime. Get that tradeoff wrong and your agents are either slow and expensive or stupid and inconsistent. Get it right and you have a shared context layer that every function in the company can build on top of.

Most companies haven't made this decision yet. They're deploying point-solution agents in finance, point-solution agents in support, point-solution agents in HR, with no shared substrate underneath. That works for a quarter. It does not work for a real operating model.

The companies that are going to compound through this transition are the ones treating context as an architectural problem, not a per-team problem. This is the bet I keep coming back to in What Replaces the Product Org in 2028 and the reason I argue the function will report directly to the CEO, not through a CPO sitting between.

Where this is going

R&D already evolved into this model. GTM and G&A are catching up fast, and the gap is closing in months, not years.

What you're going to see at well-run companies in 2026 is Product Builders who are also Agent Operators embedded across the entire org, collaborating with developers the way PMs have always collaborated with engineers, just faster and closer to the work. The job title might say "agent operator" or "AI program lead" or "head of automation" while companies figure out the language. By 2027 the strongest of those JDs will say "Product Builder, [Function]." The work is product management. The skill is workflow thinking, system design, and rapid iteration with builders, all wrapped around an agent substrate.

If you're a PM watching the R&D team wonder whether the role is shrinking, look up. The role is multiplying. It's just doing it outside the place you've been looking.

The product team didn't lose product management. The rest of the company finally caught on to what it was.

What to do this week

Pick one. Not three. One.

1. Map one workflow outside R&D that your company is automating. Finance close. Support tier-one routing. Legal review. Sales ops handoffs. Whichever one is closest to you. Write down the operator, the developer, the agents, and the cycle time. If there is no developer paired with the operator, that's the gap.
2. Audit your shared context layer. Where does the data the agents need actually live? Where do the rules live? If the answer is "in five different SaaS tools, none of which talk to each other," that's the architectural decision your company hasn't made yet.
3. Stop writing PRDs for agent workflows. Sit next to the developer for an hour. Iterate on the prompt and the routing live. Write the README after, not before. See whether the loop actually works.

If you're a CPO, the version of this is bigger. Your scope just expanded across the P&L, whether you noticed or not. The companies that handle this well will have product leaders helping finance, legal, HR, and sales ops design their agent workflows in 2026. The ones that don't will watch consultants own it instead.

The choice is the same one R&D faced two years ago. Product Builders who are also Agent Operators, paired with developers, iterating fast on a shared substrate. The org chart and the title bar catch up later.

---

Aaron Levie's framing prompted this post. The full toolkit, including a worksheet for mapping cross-functional agent workflows, is at falkster.com/toolkit.

Further reading

• Aaron Levie's writing on the agentic enterprise
• Marty Cagan on the empowered product team and where it goes from here
• Ben Thompson (Stratechery) on the structural shape of AI-native companies
• Andreessen Horowitz on AI-native company design
• Lenny Rachitsky on how the PM role is being reshaped by AI