Scaling the Consolidation of Product Owner & Product Manager

TL;DR —So let’s say we go ahead and reunify the Scrum-imposed separation of Product Owner and Product Manager, what then? How does this scale?

The Topic

One of my predictions for 2019 asserts a continued consolidation of product ownership and product management. In response to this Ed Roshitsh, CEO at Dude Solutions posed this excellent question on LinkedIn:

This question got me thinking, how indeed would a consolidation of product ownership and product management scale?

The Split Defined

To answer Ed’s question, let’s first identify what we’re consolidating, or perhaps I should say let’s identify what we’re reconnecting after an arbitrary split inspired by Scrum.

Somewhere in our Agile past, and in response to issues of scale, Scrum spun-out a whole new role from Product Management, one that we can see defined by the Scrum Alliance as a Product Owner who is: “Responsible for the business value of the project.”

Scaled Agile Framework (SAFe), expands on this, prescribing a functional split along the tasks assigned to a team-facing product owner versus activities associated with an outward facing product manager.

The blog post ‘Scrum Evolution Over Time: Part 2 — Roles’ provides additional insights into this separation of concerns, but for brevity, let’s move on.

The Conflict Defined

Not everyone in the Product community feels such a function-driven split is a good idea. That with this division of effort, we potentially introduce any number of unintended consequences that I’ve aggregated among various sources as:

• Disconnects between the PO with the customer, even though the former is somehow asked to serve as a proxy for the latter.
• Disconnects with the PM and the team, where the former potentially blunders into trust-breaking actions or requests out of a lack of connective continuity.
• Increased communications overhead, best described in the portion of “Brook’s Law” warning of a combinatorial explosion due to the rise in differing communications channels.
• A career path caste system, where product owner becomes an entry-level point into product management, and with that an unfortunate treatment of the PO role as being something lesser than that of the PM.

In other words, while splitting concerns across PO roles and PM jobs scales, are we simply scaling in a whole new set of problems along with it? I think answers to the affirmative exists in some excellent blog posts on the topic, including these:

• Melissa Perri — Product Manager vs. Product Owner
• Revenge of the PMO — Mary Cagan
• Aha! Blog –‘The Product Manager vs. Product Owner’

But let’s move onto the consolidation.

The (re)Consolidation

As people in Product continue to re-examine and challenge this division of duties, we see the push back is away from a focus on a split along tactical lines in favor of consolidation of Product management along strategy.

This reunification is a topic worth one more blog posts in its own right, but for now, here is just a smattering of the ideas we’re seeing emerge where the thought is to consolidate along strategy instead of activities.

· Anna Aria — ‘Product Owner vs Product Manager: Who is the Boss?’

· The Scrum Title “Product Owner” must die! — Saeed Kahn

· Martin Eriksson –Your (Product) Team is Smarter Than You Are

· Product teams — agile done right — Michael CotéVerified

· Anne Thomas — Pairing for Product Managers

The Mechanics

Annnnnd here’s where I stick my neck out and offer my humble opinion on how this all scales.

As you may notice in my recent product management prognostications, I intentionally sandwich consolidation of PO and PM positions in between outcomes, experimentation, and automation. In part because of how I believe these factors — when combined with the reunification of roles along strategy — contribute to making this paradigm shift scale. Let’s see if I can briefly enumerate how.

Refocusing organizations on outcomes over outputs. Along with better results for value delivery, we free up our product teams when we remove the time-sucks associated output-centric actions introduce. For example:

• Less “are we there yet” communications — others in org need to stop tapping product people as personal assistants and librarians.
• Move the conversation and KPIs along “problems solved for customers” rather than “features delivered.”
• Challenge Management (and Product) to read ‘Escaping the Build Trap: How Effective Product Management Creates Real Value.’

Automation at the role level of the more mundane, the librarian tasks, will also further reduce the need to split along the following activities:

• User Story generation that is not intended to delivery fully-qualified stories, but rather speed-up some of obligatory form and factory aspects of tickets so product people can focus more on communicating the feature.
• Democratize the feature request process, tying this channel into the feature consideration and story creation process.
• Automated distributions, reports, and radiators to eliminate “is it done yet?” communications. Oh, and tell people in sales, marketing, etc. to use such channels.

Bake experimentation into your CI/CD framework, as this will help resolve some of the following impediments and obstacles that can hamper or misdirect product delivery:

• Encourages the safe but rapid delivery of small slices of functionality.
• Produces more immediate feedback on the impact and adoption of features.
• Further removes the emotion from product decisions and prioritization.

The Next Steps

The above lists are not complete. As I’ve already mentioned a couple of times, some of the thoughts I’ve documented here deserve blog posts of their own.

Moreover, this conversation is only at the end of its beginning. That is to say, there is much, much more to discuss and think about. So feel free to add your thoughts, detail your disagreements, or offer your suggestions. All of it is good!

And thanks Ed! Your question on how such paradigm shifts scale is both a timely and appreciated contribution to these dialogs.

YMMV