The PM Role Is Re-Merging
The bottleneck moved. Now every product org has to decide who owns what got left behind.
A few weeks ago I was on a call with a Head of Product at a Series B software company. Second-time PM leader, she knows what good looks like. We were comparing notes on how AI tools had changed her team’s velocity, and she said something that stuck with me:
"My PMs aren't writing fewer stories. They're writing longer ones, triaging more customer input than they've ever had access to, reviewing prototypes other teams vibe-coded – and line-editing everything the AI touched, because it all looks almost right."
It wasn't a complaint. She was describing something she hadn't fully named yet. Velocity on every individual task was up. But the role itself had quietly expanded in every direction at once, and nobody had decided which of the new responsibilities was actually the job. Her PMs reported feeling like they were doing several jobs they weren't hired for.
I’ve heard a version of that this year from numerous product leaders. Quiet, never framed as a crisis, usually near the end of a conversation that started somewhere else. The specifics vary by team. Some PMs are consolidating volumes of customer requests they could never process before. Some have stopped running A/B tests and started running A-through-Z, because the cost of an experiment collapsed. Some are reviewing apps the sales team or a customer vibe-coded, turning rough prototypes into real product input. Some are writing longer and longer specs, because a thin spec means the AI builds the wrong thing. None of that work is bad. Some of it is upside the role couldn’t reach two years ago. But it all landed on the same person, in the same week, with the same headcount.
Take a composite PM – call her Sally. On Monday she wrote ten user stories with AI assistance. Tight stories, acceptance criteria, edge cases called out. The kind of work that two years ago earned a shout-out in standup. By Friday, four came back from engineering with questions she didn’t expect. The stories were clear. But the AI had pulled the definition of “active user” from an old PRD – true in 2024, retired in 2025, still sitting in the docs the model could see. Engineering, also working with AI tools, built against that older definition. It compiled, tested, passed review. Nobody caught it until QA found the regression two days later.
Sally didn’t write a bad story. The AI didn’t hallucinate. Both produced clean, plausible work. Wrong gets caught. Almost right gets shipped – and almost right is the failure mode product leaders are starting to feel without being able to name.
The role started whole
Worth dusting off a piece of product history. The PM role didn’t always look like it does now. It started as one job – figure out what to build, and define it well enough that someone could build it. The strategy and the precise spec, same person.
Then orgs scaled and the role split. Part of it drifted outward – discovery, roadmap, exec alignment, accountability for outcomes. The other part of it stayed close to the build – backlog, acceptance criteria, the spec precise enough to hand to engineering. The textbook names them: Product Manager for the strategy-and-outcomes and Product Owner for the delivery responsibilities. In practice, real life is messier than textbooks. Many never staffed a Product Owner at all. Many use the title for a junior PM or a contractor, or just run senior PMs on definition and junior PMs on throughput. The distinction is still worth keeping, because it names two genuinely different kinds of work even when one person does both. That split held for fifteen years because definition was a hand-off. You wrote the spec, passed it downstream, and your part was done. The artifact left your desk.
AI is breaking the hand-off. Not by changing the definition work – by deleting the downstream. The spec is becoming context that one AI tool reads on Tuesday and a different one reads on Thursday. It never leaves your desk, because there’s no longer an “off” to hand it to. And once definition stops being a hand-off and becomes something continuous, every org has to answer a question it could previously ignore: who owns this now?
I watched a version of this question once before. At xMatters, the company I ran before Atono, we spent the back half of the 2010s moving from on-prem to SaaS. The “operations engineer” role changed quietly the whole time. Same title, same leveling rubric, but the people who were excellent at the job in 2014 weren’t automatically excellent at it in 2019, because the underlying constraint had moved from managing hardware to managing a software-defined system. What strikes me looking back is that there was no single right response. Some teams retrained their veterans. Some hired specialists alongside them. Some rebuilt the role around the new tooling and let the org absorb it. The teams that struggled weren’t the ones who picked the wrong path. They were the ones who never noticed a choice was on the table.
Product sits there now. The constraint moved. The job description hasn’t. There’s no single org shape that answers it – there are a few, and which one fits depends on where you already are.
Three paths that actually work
Re-merge the role. Collapse strategy and definition back into one person. AI makes this newly practical – it absorbs enough of the delivery-side mechanics that a single PM can now build the stories that once took a dedicated Product Owner. For smaller and mid-stage orgs where one person can realistically hold both roles, this is the cleanest answer, and arguably the strongest: product tends to be better when whoever decides what to build also owns how it gets defined. The ceiling is headcount. Past a certain size, no individual can carry both halves across a wide surface area, and forcing it produces a burned-out PM and thin definitions.
Keep the split, but reweight it. Maintaining product context is senior work now. Larger orgs that already separate strategy from definition can keep that structure – as long as the definition role reflects that. If your org runs a separate Product Owner or definition role, the move is to staff it with experienced people, pay it accordingly, and stop treating that seat as somewhere people pass through on the way up. The risk of leaving it as it is: your strongest definition people leave for orgs that took it seriously.
Distribute it into infrastructure. No single owner. The product’s definitions live in a shared layer the whole team maintains, and the PM acts as steward rather than sole author. This is honestly where a lot of teams will land, because it scales past what any individual can hold and it survives turnover. The risk is that “everyone owns it” quietly becomes “no one does” without a named steward and a real home for the context.
One honest caveat before you pick. Context is not the only thing driving rework right now. Some of the flat cycle time is normal review-and-QA load, some is teams still early on the AI learning curve, some is test coverage. Missing product context is one driver of almost-right work, not the whole story. But it’s the driver that’s structurally new, the one your existing rubric wasn’t built to catch, and the one that gets worse as you add tools.
What this means if you run a product org
Two things hold across all three paths.
The artifact of good PM work is shifting. The ticket is becoming a byproduct. The structured product context that produces good tickets – and good code, and good answers when someone asks an AI a customer question – is the thing that matters. If your PMs are still evaluated only on ticket quality, you’ll underweight the people doing the work that actually moves outcomes – and those people, often your strongest PMs, can tell when the rubric is measuring the wrong thing.
The senior-junior gradient is steepening. The story everyone was told is that AI lifts juniors to senior output. The reverse is happening. Senior PMs know which definitions to pin down and which decisions to capture. Juniors don’t yet know what they don’t know, and AI widens that gap rather than closing it. If you’re hiring, asking a candidate to write a story is a weaker signal than asking how they’d onboard a new AI assistant to your product.
We got obsessed with this on our own team. Our AI tools had no shared model of how our product actually worked, and the gap produced exactly the almost-right work I’m describing. When we ran our Glossary against the AI-generated stories already in our backlog, 60% needed changes – not because the AI was bad, but because it was working from an incorrect understanding of what our product does. That’s our own dogfooding, not a market number. It’s what made the abstract pattern concrete enough to build around. Atono’s Glossary captures how your product actually works – the roles, workflows, permissions, features, and integrations that define it – and keeps that understanding available to every AI tool your team uses, so the context has an owner regardless of which path you pick.
Pick the path that matches your org. The piece you don’t get to skip is the conclusion all three share: definition is becoming continuous, load-bearing context, and it needs an owner whether or not you’ve named one. The orgs that fall behind won’t be the ones who chose a different path than their neighbor. They’ll be the ones who never noticed there was a choice.