Scrum's Unintended and Gradual Disconnect from Product Management
The Self-inflicted Product Owner vs. Product Manager Confusion That Demoted the Product Owner
Scrum’s failure to embrace the world of Product Management by coining a separate Product Owner (PO) accountability was a mistake. It started with good intentions, to give the Product Manager (PM) more authority by calling them a Product Owner.
We can now safely say the Product Owner rebranding backfired. Product Owners usually have less authority than Product Managers. Which is the opposite of what the Product Owner label was supposed to achieve.
When you talk to Product Managers and explain to them that the Product Owner is actually the Product person with the greatest accountability over the product, then they look at you with disbelief.
There is a big rift between the world of Product Management and the realm of Scrum, and I only see it growing unless the Product Management misconceptions are better addressed in the Scrum Guide.
With the decision to rebrand the Product Manager as a Product Owner, the resulting confusion caused the world of Product Management to slowly slip away outside the realm of Scrum. The Product Owner confusion is why we still have Product Manager vs. Product Owner discussions.
People started attaching their own meaning to the Product Owner role because the role doesn’t scale. *Poof* out of pandora’s box the akimbo Product Manager/Product Owner craziness escaped. A bureaucratic solution that is strongly disliked by both the Product Management and Scrum community.
We now see Product Managers working outside of the Sprint together with Product Owners. In such an arrangement Product Owners are trapped in the Sprint bubble and usually granted less ownership over maximizing the delivery of value than the Product Manager.
Even at companies that don’t have Product Managers, many of them don’t even have real Product Owners. The Product Owner label in practice means something completely different than it means in theory. Companies usually have multiple Product Owners per Product and not a single Product Owner, thus breaking the single Product Owner per Product rule.
Unfortunately, the Scrum community seems unwilling to inspect and adapt. It clings to a Product Owner ideal that is rarely used in practice and doesn’t scale. It’s easier to point fingers and claim that people with PM/PO solutions or multiple POs per product are not doing Scrum.
How did we end up in this crazy situation? And what should we do about it?
Let’s start going back in the history of Scrum to see how the Product Owner came to be.
The Product Manager and Product Management gradually slipped away from Scrum
In the early descriptions of Scrum, Product Management has a far more prominent place than it currently holds.
The seminal 1995 OOPSLA paper on Scrum discusses both Product Management and the Product Manager exactly once. That might not seem like a lot, but keep in mind not a single word is devoted to the Product Owner or Scrum Master. Both of them had not entered the picture yet.
Let’s take a look at the Product Manager description:
Management: Led by the Product Manager
Summarizing this paragraph: management is responsible for Product Backlog management and they’re led by the Product Manager.
Are we witnessing the first sprouts of the Product Owner role under the guise of the Product Manager? I believe so.
I’m not impressed by the way the Product Manager's responsibilities are described. The description has more in common with a Project Manager than a Product Manager.
Also, not a single word in this snippet talks about value. In fact, in the whole paper, the word value is mentioned zero times. To contrast it with the current Scrum Guide: there the word value is mentioned 25 times.
Let’s examine what is written in the paper when we look up ‘Product Management’:
“Each Sprint is followed by a review, whose characteristics are :
The whole team and product management are present and participate.” — Scrum Development Process, OOPSLA 1995
Product Management is mentioned separately as an important stakeholder that should be present at the Sprint Review. The rest is lumped under the label of the whole team. The presence of Product Management at Sprint Review looks eerily similar to the current important role of the Product Owner at the Sprint Review, right?
The presence of Product Management at the Sprint Review is the second glimpse of something that would ultimately turn into the Product Owner role. To me, it’s completely evident that the Product Manager and Product Management being referred to would later fall under the purview of the Product Owner.
But wait, there’s more! In the first incarnation of the Scrum Guide, where the Product Owner role is described, the following tip appears:
“For commercial development, the Product Owner may be the product manager. For in-house development efforts, the Product Owner could be the user department manager.” — Scrum Guide V1, 2010
By now, let there be no confusion about it: the Product Owner role has its roots in Product Management. A nice label was slapped on it that might create the impression or illusion that it’s something different, but the Product Owner is supposed to be a Product Manager after all!
What was the idea behind the founders of Scrum deciding to call the Product Manager differently?
Why was Scrum’s Product Manager rebranded as a Product Owner?
I believe the reason behind rebranding the Product Manager as the Product Owner was to clearly indicate the far-reaching authority of full value ownership over the Product.
The ‘Owner’ label would establish beyond a shred of doubt that a single person owns the product, instead of multiple people. The ownership part was considered to be more important than being clear about the necessity of Product Management for the Product Owner.
The Scrum Guide didn’t stop at the rebranding of the Product Manager as the Product Owner. In the latest 2020 version of the Scrum Guide, any mention of the word Product Management was removed, increasing the Scrum — Product Management divide even further.
I assume the intent was to make the Scrum Guide more generic to allow it to be tailored to your specific context even more. However, it only added to the Product Owner — Product Management confusion.
Coining a new Product Owner role and later removing Product Management altogether from Scrum was a big mistake now happily exploited by scaling frameworks like Scaled Agile Framework (SAFe) to downgrade the Product Owner to a Team Backlog Owner.
The problem is that it isn’t just the scaling frameworks.
Last week a Product Owner on LinkedIn told me that when his Product Manager left, the former colleague gave him the advice to apply for the Product Manager position, as it would be a promotion. Writing this feels absurd to me, but it’s not the first time I’ve heard it.
The bigger problem is that in my experience these Product Owner downgrades are not isolated instances, but systemic. Let me tell you a story from personal experience.
I remember my manager telling me that we were doing everything wrong and that we should hire Product Managers to work together with our Product Owners. I tried to argue and explain the idea behind the Product Owner role, but to no avail.
Ultimately the decision to have Product Managers and Product Owners working together was reverted. Nobody was happy with the arrangement and all Product Managers and Product Owners did not believe it worked.
I believe these misunderstandings become possible because the Scrum Guide has no direct, explicit connection between the Product Owner and their Product Management capabilities. Nor does the Product Owner label sound serious or heavy enough for the actual role. The title of a Product Manager carries more weight than a Product Owner. This is absurd when you realize the true accountability of a Product Owner is far greater than your typical Product Manager.
As the number of Scrum Teams grows it is entirely unclear how the Product Management activities should scale. A single Product Owner per product isn’t good enough beyond a few teams and the product management expertise isn’t easily delegated.
Even though the history of Scrum and the Scrum Guide shows there was an explicit connection between Product Management and the Product Owner in the past, the link has been completely severed in the 2020 Scrum Guide and in the popular practice of Scrum.
Voila, here we are now, with people having Product Manager vs. Product Owner discussions, and scaling frameworks exploiting the confusion by creating a false disconnect between Product Management and the Product Owner.
The false disconnect between Product Management and the Product Owner
Here’s the PM/PO combo as advocated by SAFe and made possible by the illusory disconnect between Product Management and Product Ownership:
The only reason the wonky PM/PO solution becomes an option is that people do not understand what the difference is between a Product Manager and a Product Owner. A Product Owner sounds less important than a Product Manager. Hence, this solution of having a Product Manager funnel requests to the Product Owner makes total sense for people who are unfamiliar with Scrum.
Scrum defines the Product Owner as an accountability belonging to a single person. That someone who is ultimately accountable for the value of the product as delivered by the Scrum Team. Who performs the Product Owner responsibilities does not matter. Those responsibilities may be delegated to anyone capable of doing it.
When you have a few teams, the Product Manager can be one person. Beyond a few teams, this becomes difficult if not impossible. I believe this is why we see a separation between Product Managers and Product Owners today — to deal with scale because Scrum doesn’t provide an adequate solution out of the box.
Depending on the context and scale of your organization, your Product Owner could be the CEO, the Chief Product Officer (CPO), the VP of Product, a (senior) PM. Whoever is ultimately accountable for maximizing the value of the Product. That’s why the approach of having a PM spoonfeeding requests to a PO makes zero sense.
The confusion is further exacerbated by the fact that people mistakenly believe Product Ownership and Product Management are something different. Yes, the Product Owner is an accountability, but that accountability is powerless without Product Management happening at the team level.
We need to remind ourselves that the PM/PO combo is a well-meaning solution to the problem that a single Product Owner who carries both the accountability and responsibilities doesn’t scale.
Empowered Teams require Product Management expertise for short value feedback loops
Scrum talks about empowered / self-organizing / self-managing teams, and that means the Product Management expertise, if necessary, is part of the teams that do the work. Either through the Product Owner if you have few teams, or by having Product Management expertise as a part of your Development Team.
Both the Product Management and Scrum community realize the importance of empowered teams. That’s why Scrum Teams shouldn’t rely on a single person outside of the team in order to be empowered. How empowered are you if you have to run every request through a single person called the Product Owner?
Here’s what it would look like if you have a single Product Owner per Product with many teams and Product Management expertise as part of the Scrum Teams:
The growing divide between Product Ownership and Product Management
It’s time for a wake-up call in the Scrum community: instead of pointing at what the Product Owner label was supposed to achieve, let’s take a look at the rubble and confusion it leaves behind and take responsibility.
A single Product Owner per Product doesn’t scale without the Product Management expertise being part of the teams. How you call that person that brings the knowledge to the teams, a Product Manager, Product Owner, or whatever, doesn’t matter. That’s just semantics. It doesn’t even have to be a separate title, as long as it’s present.
Inside a flurry of self-invented and confusing Product Owner explanations that exist in the wild, maximizing the delivery of value with Scrum drew the shortest straw. That’s something we all as Scrum practitioners should be worried about.
Let’s give Product Management a central place again in the Scrum Guide. Let’s define how it should be, instead of letting the imagination of the outside world run wild.
Let’s change the Product Owner label to something that is easier to understand. Conforming to existing labels that are well-known in the Product Management community may be a good place to start. Nobody in his or her right mind will dare to propose a PM — CPO solution.
This way, Scrum might have a fighting chance against the Frankenstein PM/PO solutions that make people miserable all over the world and diminish the delivery of value.