The Rise of the AI Product Manager: Builder, Not a Faster PM

I've spent the last six months taking a new product to market, which has mostly meant sitting across from product people. Calls, design-partner sessions, hallway conversations at conferences, dozens of them. At some point, I caught myself summarizing for a colleague what they were actually struggling with, and it wasn't what I expected.

It came out something like this. Product people are overwhelmed and siloed, running like cowboys, heads down, too slammed to talk to engineering until the work is already in motion. Their requirements are often ambiguous, missing edge cases, security, and integrations, and now that engineering has coding agents, that ambiguity doesn't get caught. It gets built fast and wrong. Scope still triples the second the work hits the team, because the technical reality was never in the package. The real understanding of what they're building lives in their head and a few Slack threads, never in the doc. And under all of it, there's a newer, quieter worry: even if we ship the thing, is it any good? They've never really had the time to watch it all.

That's the group I'd call the good product managers (PMs), for what it's worth. They feel that pain because they're reaching for the real job. There's a second group in a different kind of trouble. The PMs, product owners, and some product analysts whose work is mostly process and ceremony, running the scrum, pulling data out of one system to build a report in another, summarizing roadmaps up the chain. They've seen the AI promise and nodded at it, but they're too buried in their current responsibilities to actually change how they work, and they haven't caught the vision of what a builder PM even is. I think those jobs are in real jeopardy. And from the conversations I'm having, they sense it too.

The market has noticed. There's a new "product management operating system" every other week now. Notion templates, Miro boards, skills- and agent-driven methods, AI copilots, a dozen tools each promising to be the system of record for product. Product people are bolting them on by the armful and feeling the exact same pain, because a tool was never the missing piece.

What's actually happening isn't a tooling gap. It's the job itself changing underneath us. People are starting to call the new version the AI product manager, or AI PM for short, and the one everyone reaches for first is the fast one: writes specs in minutes, ships more, and moves quicker. I think that version is a trap, and chasing it will get a lot of PMs in trouble, because speed was never the hard part of this job.

Carlos Gonzalez de Villaumbrosia (Product School) named the trap at ProductCon better than I've heard anyone name it. His point: almost every product org now has an AI strategy. Very few have an AI operating model, and the operating model is what actually executes the strategy. Without it, you get what he calls the "messy middle" or the "false summit." You buy the tools, your best people get individually faster, everyone feels like they're winning, and then none of it shows up in the business. Something like 80% of teams are stuck right there. Individual magic that decays the second you try to make it work across a team.

The rise of the AI product manager isn't the rise of a faster PM. It's the rise of a PM who owns a different job. A job not possible without using AI to help.

Why AI product teams get stuck

For thirty years, basically every ritual we have had was built to manage one constraint: engineering capacity. Backlogs, sprints, MVPs, prioritization frameworks, the whole apparatus. All of it exists because dev was slow and expensive, and we had to be careful about what we fed it.

AI changed the economics. Dev got fast. But raw velocity does nothing for a team still shaped for the slow world. Speed wants small, nimble teams that are autonomous and self-directing, carrying as few dependencies as possible, able to decide and move without waiting on three other groups. Now that engineering can move this fast, that shape matters more than it ever has. Get individually faster inside the old structure and the gains stall the moment they have to cross a team.

That's the mechanism behind Carlos's 80%. Teams sped up the one part that was never going to move the business on its own and left everything around it untouched. We've seen this movie before, with DevOps. The whole point of DevOps was to kill the friction between dev and ops, and it did so by automating the path to production. But automating the build does nothing if the work then sits for a quarter before shipping. If you can build a feature in two weeks and it still takes a quarter to get it out the door, what was the point? Speeding up only the build just exposes everything that was always slow around it. You can ship five times faster and have it mean nothing.

What an AI product manager actually is

The word I hear used most is "builder." Product Builder, AI PM, builder PM, the label moves around, but the idea underneath is the same. In the old project model, and in plenty of so-called product orgs, the person carrying the PM title is really a project manager, gathering requirements and shepherding a roadmap someone else already decided, and AI is quietly automating that job out of existence. The people having the most fun with AI right now are often automating their own replacement. In the product model, the PM owns the outcome, and you can't own an outcome by managing a handoff. You have to shape the solution. That's the builder.

A PM builder does not mean the PM now does the design and the engineering too because the tools allow it. The few who can genuinely do all three are rare and worth a fortune, and not because they can drive Claude Code. They're valuable because they've built real judgment in each discipline, and that judgment doesn't scale by piling three jobs onto one person. The point of the AI PM isn't that the PM swallows the team. It's closer to the opposite. Delivery got cheap, and that finally frees the PM up for the part that was always the actual job and never got enough time: figuring out what's worth building, and whether it worked.

So what does a builder actually produce? At its center are prototypes you can put in front of a customer. Not a deck about the idea, the thing itself, real enough that someone can react to it. The bar for that moved, too. A wireframe used to count, gray boxes and arrows standing in for the product. It doesn't anymore. People expect something interactive now, something they can click through and feel, because the tools to build that got cheap enough that a static mock reads as not having tried. Alongside the prototype, the builder writes the evals. An eval is just a clear, checkable definition of what good looks like, the bar the work has to clear whether a person or an agent produced it. Good ones are specific and falsifiable: not "the summary should be high quality" but "the summary names the three at-risk accounts and nothing else." If you can't write the eval, you haven't actually decided what you want. And then there's the part PMs love to skip, the non-functional requirements. Performance, security, scale, reliability, the things that aren't a feature but bury you when they're missing. A good engineer used to carry these silently. An agent won't. So the builder has to hold them, deciding up front how fast is fast enough, what the system has to survive, where the compliance lines sit, because no one downstream is going to slip them in for you.

AI product manager vs. traditional product manager

What changes is accountability. The old model was simple. Often, leadership decided, top-down, which problems were worth solving and roughly where to invest. The PM turned that into a list of features, handed off the requirements, and waited. The new model puts you on the hook for the outcome, which means the trade-off matrix that used to live in engineering's head is now yours. Features versus defects. Features versus risk. Features versus the infrastructure bill. Features versus the token bill. When building software is cheap, those get redetermined every week, and there's no engineering lead to absorb them for you. You're not a feature curator anymore. You're a portfolio manager who can build. Better to think of yourself as a mini-CEO of your problem area.

The clearest version I've seen up close is Curtis Sherbo's group at Athenahealth. I had him on Stacked Sessions to walk through their AI transformation, and what stuck with me was where they started. Not with the engineers. With the PM. They reimagined the role first, restructured the teams around it straight out of Team Topologies, carved out dedicated time for people to learn, and ran the whole thing as a framework rather than a process. Curtis put it the way only someone living it would: the role has changed so much since he came up as a PM that he's had to relearn it. The orgs getting real leverage out of AI are the ones treating the PM as the thing to redesign, not the thing to speed up.

Shipping faster is a setup, not a finish line

There's a bigger shift sitting underneath all of this: the democratization of shipping code. The product and software development lifecycles collapse into one. A PM expresses requirements in natural language, works through wireframes, defines the evals, and agents draft the pull request, with human-engineering guardrails in place for review before anything hits production. With the right guardrails, anyone can ship. RIP to Agile?

And making the build cheap does nothing about whether you built the right thing. Marty Cagan (SVPG) puts it bluntly: most teams are just turbocharging their feature factory, garbage in and garbage out, only faster. We learned this once with the "10x engineer," and we're about to learn it again with the "10x PM." Speed into an unmeasured stream isn't progress. You're just faster at building the wrong thing, and now you've got more of it to maintain.

So are we actually getting better at solving the problem? Or are we just measuring the easy things, whether we blew up production, whether we shipped on time, whether we hit the quality bar, whether we "used AI"? The one thing that matters, whether the work moved the outcome, is the hardest to measure, so most teams quietly measure something else. Teresa Torres has been hammering this point about product discovery for years over at Product Talk, and she's worth following.

Build to learn, then build to earn

Jeff Patton has a line I keep coming back to: sometimes we build to learn, and sometimes we build to earn. Engineers mostly build to earn, the real thing customers depend on, reliable, scalable, and safe. PMs and designers mostly build to learn, throwaway prototypes whose only job is to answer a question. Both got faster with AI, but build-to-learn is where the AI PM now lives. You spend the week running cheap experiments, putting rough things in front of people, killing the ones that don't land, because the cost of finding out dropped to almost nothing. The detailed grind, the wiring, the boilerplate, the first draft of everything, you hand to AI. What's left for you is the learning: which problem, which solution, what the evidence actually says. That's the job, and it's finally most of the job.

The AI product team gets small

The team shape changes to match. The unit that works now is a tight trio: a product manager, a designer, and an engineer, operating as one squad instead of three functions passing work over walls. They sit on the same problem, ship something every week, and carry as few outside dependencies as they can. They share an understanding of the platform they're building on and the outcome they're chasing, so the lines between the three roles blur at the edges, on purpose. Amazon gave us the two-pizza team. The AI-era version is closer to two slices. Smaller, faster, more accountable, and a lot harder to hide inside.

The skills an AI product manager needs

The AI product manager's kit looks roughly like this. Some are old skills that suddenly matter more; some barely existed three years ago.

• Product sense. The judgment for what's worth building. Still the table-stakes skill, and the one AI can't hand you.
• Product strategy. Knowing which problems to solve and in what order, so the bets compound instead of scatter.
• Business sense. How does this actually make money? The viability question isn't engineering's or design's job; it's yours.
• Customer feedback. Pulling real signal from real users, fast, and reading it honestly instead of for confirmation.
• Prototyping. Building the thing well enough to test it, not just describing it.
• Evals. Defining what good looks like precisely enough that a person or an agent can be measured against it.
• Context engineering. Assembling the customer, code, delivery, and decision context that an agent needs so it isn't guessing.
• Analytics. Living in the data yourself, not requesting a report once a quarter.
• Agentic orchestration. Running a stack of agents on your behalf, and knowing when to trust what comes back.

Your context window just got bigger

To make any of the product direction calls well, you have to hold more than the job used to require. Not just the roadmap and a few customer calls. The whole picture: customer feedback and support tickets, open issues and incidents, the backlog, what leadership said in the last all-hands and what got decided in the meeting you weren't in, the competitive landscape, and the industry shifting under you, which matters double on AI features, where the ground moves monthly. No one holds all of that in their head anymore. The job is getting it into a form you and your agents can actually reach. I'll go deep on that in an upcoming blog. So I won't repeat it; just know it's part of the job now, not the background.

Security and compliance are now the PM's job

One more new job, and it's the one PMs most want to wave off as someone else's department. When the build was slow and gated, security and compliance got caught downstream by a review, by an engineer who knew better, by the gate itself. Cheap, fast, agent-built software blows straight through those gates. If the definition didn't say to handle this data this way, meet this regulation, fail-safe here, the agent won't invent it. It'll ship past it at machine speed. That makes security, privacy, and compliance a product responsibility now, not a box checked at the end. You don't have to be the expert. You do have to own that it's in the definition and that someone qualified signed off, because when it's missing, it's your outcome that takes the hit.

So go forth and conquer

If you've read this far, you probably had one of two reactions. Either this lit you up, the problem-solving, the ownership, the shot at actually shaping what gets built, or it landed as a sign your energy might be better spent somewhere else. Both are fair reads. For me, it's the first one, easily. I don't think there's ever been a better time to be in product, or a wider-open opportunity to solve real problems for real people.

So the operating-model question for an AI PM was never "how do we ship faster?" We solved that. The harder, and the right, question now is: did we do the right thing, and how quickly did we find out? The AI PM worth becoming is the one who can answer that. Everyone else gets to the wrong place sooner.

Frequently asked questions

What is an AI product manager?

A builder, not a faster PM. Delivery got cheap, so the AI product manager spends the time on what was always the actual job: deciding what's worth building, prototyping it, defining the evals, and confirming it worked. The job moved from managing a handoff to owning the outcome.

What's the difference between an AI product manager and a traditional product manager?

A traditional product manager turns leadership's decisions into a feature list and hands off requirements. The AI product manager owns the outcome, which means the features-versus-risk-versus-cost trade-offs that used to live in engineering's head are now theirs. You stop being a feature curator and start being a portfolio manager who can build.

What skills does an AI product manager need?

Product sense, product strategy, and business sense first. Then reading customer feedback honestly, prototyping, writing evals, context engineering, living in the analytics yourself, and orchestrating agents, which means knowing when to trust what comes back. The old judgment skills matter more, not less.

Will AI replace product managers?

It's replacing the ones whose job is mostly process and ceremony: running scrum, moving data between systems, summarizing roadmaps up the chain. The builders who own outcomes are the most valuable they've ever been. The role isn't disappearing, it's splitting, and which side you land on is mostly a choice.