Engineering Beyond Agile: The Agentile PM splits into three
Se2 Ep1: The PM Fragments Too
Every popular account of the AI-era product manager makes the same promise: the role gets bigger. The “AI-native PM” masters the tooling and ships faster. The “PM as orchestrator” conducts a section of agents. The “product engineer” swallows the boundary between building and deciding. The “mini-CEO” becomes a broader, more singular owner. Different labels, one shared assumption — they all keep the role whole. One person, more leverage.
I made a version of that promise myself, back in February, when I asked whether we still need a PM in an Agentile team and argued the role was stretching: meeting engineers earlier, writing specs instead of stories, carrying decisions that used to wait for a later milestone. I was half right. Stretch a thing far enough and it doesn’t get bigger. It tears.
We already ran this experiment on the engineering manager, and that is not what happened. The EM didn’t get leaner or more powerful. The composite — five accountabilities we’d bundled into one title and hoped one human could hold — came apart at the seams the moment machines started executing without pause. What climbed out wasn’t a better manager. It was a team of separately-accountable roles where one person used to stand. The product manager is that same composite, one altitude up. And it fragments the same way.
The power of three
Three roles come out of the wreckage. Or the ashes, if you feel mythical.
Role 1: The Product Mind
The first is the Product Mind: the sense-maker. The human who holds customer truth, decides what’s worth building, and, more importantly, what this product will never do. This is the part everyone is right about, and also the least novel; Marty Cagan has been describing the discovery instinct for a decade, and good PMs were always sense-makers. What changes is only where it sits: inside the cell, next to the engineering and business minds, close enough to the work that there’s no hand-off left to manage. This shifts the power balance and reduces coordination tax.
Role 2: Product Spine Author
The second role is the one that has been unnamed, but it’s the one that matters most: the Product Spine Author — the person who owns the product-policy spine: the enforceable rules for what the product will and won’t do to a customer, the product-side counterpart to the architect who authors the engineering spine. When agents execute without pause, product intent can’t live in a slide deck or a quarterly roadmap that a human walks people through. It has to be authored as structure the agents inherit — the guardrails, the trade-offs, the non-negotiables of how this product treats its customers, written in a form that is enforced rather than hoped for. Where the Product Mind decides what the product will never do, the Product Spine Author writes that “never” into structure the agents can’t route around. And here is the uncomfortable status flip: a Product Spine Author whose constraints govern how twelve cells interact with customers has more product influence than a Group PM who ran four teams through a roadmap. Authority moves out of the meeting, into the structure.
Can Spec-Driven Development resolve it all?
Early versions of that already exist. Spec-driven development — GitHub’s Spec-Kit, OpenSpec, Kiro, the whole “the spec is the source of value and the code is a lossy projection of it” argument — is the industry already building the substrate. Product intent is being codified as specification because agents need something durable to read.
But a spec registry gives you spec files; it does not give you a person accountable for the product policy those specs encode. Martin Fowler put the gap precisely: “Correctness is outside any sensor’s remit if the human didn’t clearly specify what they wanted in the first place.” No amount of agent review recovers a product intent that was never authored. The research is already formalising this: a 2026 line of work on “constitutional” spec-driven development encodes the non-negotiables — the must-nots — into the specification layer itself, enforced by construction rather than inspection. The tool is the statute. Somebody still has to author the law. That somebody is the Product Spine Author.
Role 3: Domain Product Lead
The third role is the Domain Product Lead — the human accountable for outcomes in a vertical, the one who owns the domain deeply enough to say whether the system is doing the right work, not merely whether it shipped. At enterprise scale this is your CPO; below it, it’s whoever carries end-to-end accountability for a product line. It reports on outcomes, not activity — and it’s the only one of the three a board already knows how to hold to account, which gives it the gravity to swallow the other two if no one draws the lines.
What happens now
Now the honest part, because this is a prediction, not a press release. No public dataset shows PM titles splitting into three, formally. Org charts lag reality by years, and there’s a failure mode I wrote a whole chapter about — the immune system, where new vocabulary gets bolted onto unchanged structure and the org congratulates itself for transforming while nothing actually moved.
If this fragmentation gets reabsorbed, I can tell you which role goes first. The Product Spine Author funds itself, because a product with no authored guardrails breaks in ways a dashboard catches. The Product Mind — the judgement, the customer truth, the slow human work of deciding what’s worth doing — is the one absorbed “for now” and never restored. It doesn’t fail on a schedule anyone is watching. It just stops being anyone’s job.
If you’ve followed along in this series, the image below is how this Agentile product team pieces together. The book goes deeper into the dynamics and the governance model.
Get rid of the PMs → Profit?
There’s a more radical version of the counter-argument: AI doesn’t fragment the product role, it deletes it — one capable engineer and a handful of agents absorb the whole squad. The most rigorous case study of exactly that setup turns on its own finding. The one-person squad works — but the binding constraint stops being model capability and becomes specification quality and institutional knowledge. Remove everyone else, and the authored product intent and the judgement behind it become the entire game. That isn’t the death of the product roles. It’s a demonstration of which ones were carrying product development all along.
A fair question if you read my previous posts: the Engineering Manager fragmented into four roles, so why does the PM yield three? Because one of the EM’s four was the people axis — careers, compensation, hiring, the feedback that has to report from outside the domain to stay honest. PMs carry far less of that. Strip the people-management seat and the same logic gives you three, not four. Same law, different composite. I’d love your opinions on this, dear reader.
On concentrating the value upstream
The strongest objection deserves a straight answer. Marty Cagan’s current argument is that as the cost of delivery collapses, our advantage moves upstream to product discovery — and that the answer is still the empowered product team, not a new org chart.
He’s right that discovery is where the value concentrates; that’s the Product Mind, and I’d defend it as fiercely as he does. But the empowered model assumes human-speed execution: a team that deliberates, decides, then builds. When the building never stops and the deciding has to be encoded in advance for agents to inherit, discovery alone isn’t enough: someone has to author the product’s constraints as structure. The fundamentals don’t disappear. I’m not refuting the product operating model — I’m saying machine speed forces a layer it left blank.
That layer has an author now. Three of them, actually.
This is the product side of an argument my book makes in full: the composite-role fragmentation of Chapter 9, the cell and its three minds in Chapter 5, and the product mind’s day in Chapter 11. If the engineering version landed for you, this is its mirror. Ghost Decisions is out now on Kindle, Kobo and paperback on Amazon.
Next in the series: Your IDP Is a Menu.