Paweł Huryn's post on the PM/PO split is mostly right. The split-role setup is broken. The PM gets disconnected from reality. The PO gets soul-crushing translator work. Engineers get filtered context and miss the actual problem. He nails the diagnosis.
The prescription is two-thirds of the way there. Merge the roles. Restore the product trio. Cite Marty Cagan. Move on.
I want to push the argument one more step. The PM/PO split is not the root cause. It is a symptom of running Scrum in a 2026 operating environment that does not match Scrum's assumptions. Merging the roles fixes the symptom. The frame still needs to go.
The short version
Huryn diagnoses the PM/PO split correctly. The split creates handoffs where you need collaboration, translator work nobody enjoys, and filtered context that breaks discovery. He prescribes merging the roles and restoring the product trio. That fix is necessary and not sufficient. The Product Owner accountability exists because Scrum's sprint cadence requires someone to translate strategy into ceremony-shaped artifacts (user stories, refined backlogs, sprint commitments). Merging the roles without killing the ceremony just gives one person two broken jobs. The real fix is a four-to-six person builder pod that runs on prototypes, evals, and an outcome ledger. The PO role has no work in that structure.
For the broader argument about the role split, see The PM Interview Question I'd Refuse to Answer in 2026. For why the underlying ceremony is the problem, see Agile Is a Coping Mechanism and Kill the AI Office Hours.
Where Huryn is right
Three places, all worth crediting.
First, the description of what the split-role org looks like. The PM disconnected from implementation. The PO doing translator work. The engineers hearing third-hand context. The discovery meetings where the PO can't decide and "takes notes to share with the PM later." This is the lived experience of every mid-sized org that ran a Scrum transformation between 2014 and 2024. Anyone who has been a PM or a PO in that setup recognizes the picture immediately.
Second, the claim that backlog work is AI work in 2026. Writing user stories, breaking down epics, refining acceptance criteria, maintaining sprint documentation. All of that is automatable now. If the Product Owner role is mostly administrative backlog management, the role should not exist. Automate it. This argument is correct and underused.
Third, the citation of Marty Cagan's product trio (PM, designer, engineer working together with direct customer access) as the model worth defending. The trio is not a panacea but it is the right shape for the work, and orgs that have shed the trio in favor of role specialization have consistently produced worse products.
If the post had stopped at "kill the split, run a trio, automate the backlog," I'd be a co-signer.
Where it stops short
The post tries to fix the PM/PO split inside the frame the split came from. That is the mistake.
The Product Owner role is not an accident of poor org design. It is a structural requirement of Scrum. Scrum specifies a sprint cadence (two weeks, usually), specifies a refined backlog as the input to each sprint, specifies a sprint commitment as the output of sprint planning, and specifies someone (the PO) as accountable for "maximizing the value of the product." That accountability has to be cashed out as ceremony-shaped artifacts because Scrum runs on ceremony-shaped artifacts.
Merging the PM and PO roles does not change any of that. The merged role still has to:
- Maintain a refined backlog
- Show up to sprint planning with prioritized items
- Make sprint commitments
- Translate strategic intent into user stories
- Defend velocity numbers to leadership
That is two jobs in one calendar. The translator work that was previously someone else's problem is now your problem. The reason orgs split the roles in the first place was that one person couldn't do both well. The PM/PO split is the org's revealed preference about its own ceremony load.
Huryn names this objection directly ("too much work for a single person") and dismisses it with "you're doing product management wrong." That is too easy. The math is not about how good the person is. It is about how much ceremony the operating model demands. Scrum demands a lot.
What replaces it
The four-to-six person builder pod.
One PM. One designer who prototypes in code. Two to three engineers. The pod owns one customer-facing outcome end-to-end. The artifacts are:
- A prototype that ships and gets used by customers in days
- A five-row eval suite that defines done
- An outcome ledger with three to seven active bets, decided in two to four weeks
That is the entire artifact set. There is no backlog. There is no sprint planning meeting. There is no sprint commitment. There is no Product Owner role because there is no role-shaped work for a PO to do.
The PM in this pod is doing what Huryn correctly described: direct customer access, direct engineer collaboration, prototype-driven discovery. The difference is that the PM is not also maintaining a 200-item backlog or refining stories for the next sprint. Those artifacts do not exist.
This is what builder PM work looks like in 2026. It is not a merger of PM and PO. It is the absence of both, in the Scrum sense, replaced by a smaller and tighter set of artifacts.
The PSPO appeal
Huryn closes with an appeal to his PSPO III certification as authority for the claim that PO is "accountability, not a job title."
This is the move I want to push back on hardest, because it is the exact appeal-to-credential the rest of the post is supposedly fighting against.
The PSPO III certification confers authority inside the Scrum frame. If you accept the frame, the credential matters. If the argument is that the frame itself is the problem, the credential is not load-bearing. You cannot rest the case for killing the PM/PO split on the document that defines the PO accountability in the first place.
This is not a personal criticism. Huryn is a sharp writer and the broader product community is better for the post existing. The internal contradiction is the tell that the argument hasn't quite finished resolving itself. Once you accept that backlog work is AI work and that role splits are translator work, the Scrum Guide loses its authority as the document that adjudicates which role does what.
What to do this week
If you are in a split-role org, you do not need to win a doctrinal argument to start fixing the problem.
Pick one pod. Run it as a builder pod for one quarter. Same headcount minus the PO seat (or with the PO reassigned to a builder role). Track:
- Time from customer signal to shipped prototype
- Eval pass rate on the first ship
- Number of handoffs between strategy and code
Compare against a peer pod on the old setup. The numbers will be obvious. The argument inside the org becomes operational, not theological.
If you cannot get one pod free for the pilot, the smaller move is to retire the sprint commitment as a meaningful artifact. Keep the cadence if you need the rhythm. Drop the commitment language. Replace it with the outcome ledger. The PO accountability quietly stops being load-bearing within a quarter.
Huryn is right that the split is broken. The next move is bigger than merging the roles. It is killing the structure the roles exist inside.
The builder pod template, the outcome ledger format, and the role-shape diagnostic are on the toolkit. For the pillar this sits inside, see Your AI Agent Fleet and Hiring the Builder PM.
Sources: Paweł Huryn, "Product Owner Is Not a Job Title", Marty Cagan on the product trio, Scrum Guide 2020, Teresa Torres on continuous discovery, Reforge on builder pods.
Further reading
Frequently asked
What is the PM/PO split?+
An anti-pattern where one person is hired as Product Manager (talks to customers, sets strategy) and a separate person is hired as Product Owner (writes user stories, manages the backlog, attends sprint planning). Common in larger orgs and orgs running Scrum strictly. Paweł Huryn's March 2026 post correctly identifies this as one of the worst patterns in product management.
Why is merging the roles not enough?+
Because the split exists because Scrum requires a Product Owner accountability and most orgs do not have a PM-shaped person who can or will play that role inside a sprint cadence. Merging the roles inside the same Scrum frame just gives one person two broken jobs. The real fix is to retire the sprint frame the PO role exists to staff.
What replaces the PM/PO setup in a builder org?+
A four-to-six person builder pod with one PM who ships prototypes, one designer who prototypes in code, and two to three engineers. The artifact is the outcome ledger and the eval suite. There is no backlog to administer because the work is the prototype, the eval, and the production ship. The PO role does not have a job inside this structure.
Doesn't the Scrum Guide say PO is an accountability, not a job title?+
Yes. It does. The Scrum Guide is correct on that point and Huryn is correct to cite it. The problem is that the Scrum Guide is also the source of the cadence that makes the accountability load-bearing. You cannot fix the PM/PO split by re-reading the Scrum Guide. You fix it by exiting the Scrum frame.
What about the appeal to Marty Cagan?+
Cagan's product trio (PM, designer, engineer working together) is right and worth defending. But Cagan's framing assumes a Scrum-adjacent operating model where the PM still owns prioritization and backlog stewardship. In 2026 the trio shrinks to a builder pod that doesn't need either of those artifacts because the prototype is the spec and the eval is the acceptance test.
Where does Huryn's piece nail it?+
Three places. (1) The split-role org guarantees translator work that nobody enjoys. (2) Backlog administration is AI work in 2026 and shouldn't be a human role. (3) Engineers get filtered context when there's a PO middleman, and that filtering is the actual quality problem. All three are right.
What's the polite way to push this internally?+
Pilot one pod without the PO role. Same headcount, no separate PO. Show the velocity, the eval pass rate, and the time-to-customer-feedback. Compare against a peer pod on the old setup. Most orgs convert one pod per quarter. The argument is not theological. It is operational.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn