Two in a Box PM

Marty Cagan argues that the most damaging way companies try to scale product management is splitting the PM job across two people, the so-called 'two in a box' anti-pattern. The core problem is that the PM on an empowered product team must own value and viability, which requires direct, ongoing access to customers, business stakeholders, and engineers and designers. Splitting any of these relationships between people destroys the PM's ability to make good decisions and innovate. Cagan also catalogs the common non-core burdens (delivery management, QA, user research admin, product marketing, and others) that overload PMs and suggests trimming those instead. He concludes that these can usually be fixed without gutting the role.

01Key takeaways

• Keep the PM's direct access to customers, business stakeholders, and engineers and designers; never insert a person or process between them.
• Splitting the PM job into product owner and PM roles usually severs the PM from engineers and causes long-term harm.
• Audit PM workload for add-on duties like delivery management, QA, and research admin before cutting core responsibilities.
• Hire part-time research administrative help or dedicated QA and product designers to relieve PMs cheaply and effectively.
• Avoid 'associate PM' roles for administrative chores, since they add management overhead and signal the wrong team structure.
• Keep PM span to roughly one product team of about ten or fewer engineers before considering team splits.

02Key sections

Why the PM role gets split

Confusion over what a PM is, and the sense that the job is too much for one person, drives companies to divide it. Cagan notes the industry conflates feature teams and empowered product teams under one title.

Three relationships that must stay direct

A PM on an empowered team needs direct access to users and customers, business stakeholders, and engineers and designers. Placing a person or process between the PM and any of these undermines value, viability, and innovation.

Responsibilities that commonly overload PMs

Delivery management, product design gaps, user research administration, QA, customer service, production operations, product marketing, and managing associate PMs are common add-on burdens. Each can be a significant load and many have cheap fixes.

Team size and scope

Once a PM covers more than roughly ten engineers, or multiple teams totaling over twenty engineers, the role becomes unmanageable and teams tend to degrade into delivery teams. Team topology changes come before stripping the PM's core role.

Early-stage caveat

Early-stage startups often cannot fund dedicated roles, so PMs wear multiple hats. Cagan notes the load is smaller at that stage but the pressure is high.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.