The PO vs PM madness

The Product Manager versus Product Owner debate keeps spreading and it’s painful to hear the complete madness that is going on. Is there a difference between the two roles? Who owns what? How should they collaborate? And so on.

I am hopeful that this article will provide some clarity, given the terrifying degree of noise around this. And I’ll try to do that by sharing what some of the most influential product people are saying about this.

Madness #1: PO is the same as PM

This one gives me goosebumps and it shouldn't really need clarification. Still, as Melissa Perri puts it:

“Product Owner is a role you play in a Scrum team. Product Manager is the job.”

It’s important to understand that what Scrum may help us with is to ensure that “you’ve built a product increment that satisfies the Sprint Goal and meets the Definition of Done.” Yet, as explained by Maarten Dalmijn, the actual value that particular product increment brings is another story… Unfortunately, that goes beyond what Scrum and the role of the Product Owner, have to offer.

However, the reality is that people are “confusing the rituals of a delivery process, with the skills and responsibilities of a major job on a product team”, to quote Marty Cagan.

They struggle to understand that the PO role is really just a fraction of the total job of a Product Manager. Although this may be crystal clear when we understand the PM role in an empowered product team model, it may not be so straightforward when companies still do what we often refer to as “traditional product management”.

As Teresa Torres puts it, this is where the “product manager sits in the middle between business stakeholders and the engineering team.” In this model, the Product Manager is translating the user and business needs, writing long lists of requirements, and handing them over to the engineering team — who are acting pretty much as mercenaries.

In Scrum, even though the team works in shorter cycles (sprints) and the requirements are written in the format of user stories, they labeled this in-between role as Product Owner (PO). So that’s where the term originated.

Now, in the world of high-performing product organizations, the introduction of this Scrum role is not an issue. But it becomes a mad debate for organizations that have one foot in the “old ways of working”, and the other foot in a (mostly pseudo) customer-centric and agile way of working. Let me unpack this.

Here’s an overview of the different types of “product teams”.

In Delivery teams, we typically have a PO acting as a “backlog administrator” and a Scrum team delivering outputs. I don't think this model adds confusion to the debate, as I hope we all understand that what this person is doing on a daily basis is far away from the job of a true product manager in an empowered product team. To be more precise, and quoting Marty Cagan again:

“Someone does need to do this administrative work, but this is all about delivering output, and it’s really very little to do with what I am concerned about in terms of the need for true, consistent innovation on behalf of our customers.”

However, Feature Teams and Project Teams are similar in appearance to Empowered Product Teams. Yet, very distinct. Some common characteristics of Feature Teams are:

• The Product Manager, or Product Owner, is really just a “facilitator”. A pretty different role than a Product Manager in an Empowered Product Team.
• Executives or middle managers are responsible for the value and viability of the products or features that are being built, rather than the team.
• Discovery is pretty much just design and usability testing, and it’s implemented as a project phase rather than being a continuous team habit.
• The team is mainly composed of mercenaries. Feature teams usually don't feel accountable for the outcomes and there’s no or very little involvement from the engineering team.

Project teams are a variation of feature teams described above but have the additional problem of ownership. The mercenary element can be quite high in feature teams. But here, it just skyrockets… It’s not a team creating and owning something together (missionaries), it’s a group of individuals executing requirements temporarily (mercenaries). When the project is “closed”, the output is shipped, the real outcomes unknown, and some of the project team members go on and execute some other project.

On the other hand, Empowered Product Teams work truly collaboratively in discovery and delivery, where:

“The Product Manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that works for all of us.”

Most “product teams” out there are feature and project teams, which serve as fuel for the next mad pattern. Let me spoil it for you:

Because they’re teams of this nature, a classic example is to have a Product Manager working with a designer in a “project-based discovery” model. This means they define what to build, write the requirements, and — to quote most PM job descriptions out there — “translate the user needs to the engineering team”. Sadly, these needs do need to be “translated” in detail to them because they were not involved in the discovery at all.

Paraphrasing Teresa Torres on this, the challenge we run into with project-based discovery is that sometimes these feature teams are moving really fast and they’re just dumping requirements to the engineering team, constantly increasing work-in-progress. Other times, we see the opposite happening, where discovery is taking a long time, and the engineering team is just sitting and waiting for more work.

Because of this, conventional organizations start wondering:

“Hmm… this is not working very well. We either need more discovery teams or more delivery teams. Let’s have the Product Managers dealing with discovery and business with the Designers, and then a Product Owner managing the backlog and leading the engineering team!”

At this point, we run into the PM plus PO madness.

Madness #2: The PM plus PO

For feature factories, it may be convenient to add Product Owners as a separate position to work with Product Managers. It’s an excuse to separate “the business person” from “the person that talks with the developers and manages the backlog”.

This may be seen as beneficial but if your goal is to bring through innovation to serve your customers in ways that work for your business, it’s just ridiculous — to put it bluntly. It doesn’t work. Melissa Perri “has never seen it working”, Petra Wille shares the same experience, and I could go on referencing similar opinions.

Because we’re introducing even more handovers and have the engineering teams even more distant, this model leads to many systemic challenges: from slow and deficient innovation, tragic technical debts, wasted engineering talent and creativity, to sky-high turnover of great product people that won’t put up with this. To quote Marty Cagan,

“I absolutely believe it’s critical to be a single person rather than two.”

Note: If you’re doing SAFe, a scaled “agile” framework, you’ll be familiar with this institutionalized double role madness of PM plus PO. Cagan has previously described the framework as “deadly to innovation” and I couldn't agree more. Jonathan Smart also mentions: “SAFe clearly can’t, and I don't believe is intended to, optimize for outcomes across a diverse, heterogeneous, complex adaptive system.”

Madness #3: The PO as a PM overnight

I hope it’s somewhat clear by now that if your goal is to build products that customers love within sustainably profitable and innovative business models, having both a PO and PM in the same team is — as a rule of thumb — madness.

Yet, another mad scenario is having people who’ve never worked in Product Management but have a Product Owner certification (CSPO), doing the job of a Product Manager overnight — without any further training or understanding what’s expected of them. This happens especially when the organization is already infected with madness #1 and thinks the roles are “fairly similar”. Most “digital transformations” these days involve establishing Product Manager titles so, unfortunately, this is more common than you might think. Yet, and again, as Cagan puts it:

“The result of this is that countless people with just product owner training — but the product manager title or responsibilities — to put it bluntly, have absolutely no clue what they’re doing.”

If you want to move into an empowered product team model with true Product Managers, and you currently operate on a delivery/feature/project team model with Product Owners, make sure you train your POs in Product Management if you want them to succeed in a very different role. And, of course, make sure you empower them too.

Summarizing the madnesses

My goal with this article was to shed some light on a few pathologies related to the PO vs PM debate and reinforce the case that:

• The Product Owner’s responsibility is just a very minor part of the Product Manager’s full scope of responsibilities
• Having a PO and a PM in the same team working together is usually madness if what you’re aiming for is consistent innovation on behalf of your customers. This is also a sign that you’re probably organizing in feature or project teams
• You can’t just expect that a PO working in a delivery team today is capable of thriving in a PM role tomorrow, without training and coaching.

I also want to make something clear: it’s not that agile delivery (which, if you’re using Scrum, requires the role of a Product Owner) isn’t important. It’s very important. Crucial. But it’s just not enough… The best product teams in the strongest product organizations have the role of the “Product Owner” as someone who understands the various dimensions of the business and is part of a small cross-functional team with Design and Tech — ensuring that what they’re creating is desirable, feasible, and viable. In other words, true Product Management. And yes, for most organizations, this is the Product Manager.

The role of the “Product Owner” is really just a fraction of her total job.

As Dave West from Mind The Product puts it, “this means more work for the product manager”, but is also why Product Managers need to be great leaders and have the ability to sense what’s really important for the team to continuously deliver a great product — rather than treating delivery frameworks, such as Scrum, religiously and be obsessed with the wrong things.

Instead, great teams manage themselves and truly collaborate to create and capture value at high speed, while being inspired and coached by great product leaders.

They help each other with designing experiments, building prototypes, and making product decisions in an environment of fierce intellectual debate by bringing several perspectives to the table. Engineers are part of the discovery, able to unleash their creativity and contribute with their understanding of technology. Everyone feels truly accountable for the results and understands why they’re doing what they’re doing, as well as what the strategy is to make their vision a reality.