Pawel 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, and engineers get filtered context and miss the actual problem. He nails the diagnosis. The prescription, merge the roles and restore the product trio, is two-thirds of the way there. I want to push it one more step. The split is not the root cause. It is a symptom of running Scrum in a 2026 environment that does not match Scrum's assumptions.
Where the merge argument is right
Three things are worth crediting. The description of the split-role org is exactly the lived experience of every mid-sized company that ran a Scrum transformation between 2014 and 2024. The claim that backlog work is AI work in 2026 is correct and underused: writing stories, breaking down epics, refining acceptance criteria, all automatable now. And Marty Cagan's product trio, PM plus designer plus engineer with direct customer access, is the right shape for the work. If the argument stopped at "kill the split, run a trio, automate the backlog," I would co-sign it.
Why merging is necessary but not sufficient
The mistake is trying to fix the split inside the frame the split came from. The Product Owner role is not an accident of poor org design. It is a structural requirement of Scrum. Scrum specifies a sprint cadence, a refined backlog as the input to each sprint, a sprint commitment as the output, and someone accountable for maximizing product value. That accountability has to be cashed out as ceremony-shaped artifacts because Scrum runs on ceremony-shaped artifacts.
Merge the PM and PO and the merged role still has to maintain a refined backlog, show up to sprint planning with prioritized items, make sprint commitments, translate strategy into user stories, and defend velocity numbers. That is two jobs in one calendar. The reason orgs split the roles in the first place is that one person could not do both well. The split is the org's revealed preference about its own ceremony load.
What actually replaces it
A four-to-six person builder pod. One PM, one designer who prototypes in code, two to three engineers, owning 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, and an outcome ledger with three to seven active bets decided in two to four weeks. There is no backlog, no sprint planning, no sprint commitment, and no Product Owner role because there is no role-shaped work for a PO to do.
You do not need to win a doctrinal argument to start. Pick one pod. Run it as a builder pod for a quarter with the same headcount minus the PO seat. Track time from customer signal to shipped prototype, eval pass rate on the first ship, and handoffs between strategy and code. Compare against a peer pod. The numbers make the argument operational, not theological.