In which I share and summarize resources about whether and when a unified "big" Scrum Product Owner role is preferable or when the role ought to be split between a Product Backlog Manager and a Product Manager.

I have recently been in some discussions about how "big" the Scrum product owner role ought to be in a particular Scrum team - is it a "big" product owner ala Pichler's book or a "small" product owner ala a Technical Project Manager or a Backlog Manager (and if so where does the rest of product management lie).

This discussion was in part supported by Pichler's blog post on this big product owner vs small product owner distinction.

Are you a big or a small product owner? http://t.co/K5SWNcggQG #agile #prodmgmt #ProductOwner pic.twitter.com/gWBIFr42DU

— Roman Pichler (@romanpichler) June 23, 2015

Terms of art are useful for putting handles on ideas.

Product Manager : More or less the traditional Product Manager role as it would be understood outside of Scrum.

• Articulates and maintains the product roadmap (6-12 months out, say)
• Articulates and champions the product vision
• Communicates outward about the value being delivered by the Scrum team
• Listens and negotiates with the customer, the customer proxies, the product backlog manager, the Scrum team more generally, and the users to inform the product roadmap and product vision.
• Guides the product backlog manager as to product roadmap and vision and how well the progress delivered in sprints and releases is fulfilling that roadmap and vision.

With authority comes accountability. The Product Manager is responsible for the product roadmap and the value delivered to the organization through fulfilling that roadmap.

Product Backlog Manager: aka "small product owner" or "technical product manager". This role has authority and accountability for tactical product execution.

• Highly available to the Scrum team
• Clarifies stories and negotiates scope within the sprint (a story is a placeholder for conversation; the Product Backlog Manager is the person empowered to have that conversation with Scrum team members executing the story)
• Articulates stories and prioritizes them in the product backlog, in pursuit of the product roadmap
• Plans releases (over the next quarter, say), in pursuit of the product roadmap.
• Communicates outward about the tactical change and releases being delivered by the Scrum team
• Listens and negotiates with the Product Manager to inform all of this. Informs the Product Manager about what is learned from building the product to inform the product roadmap.

With authority comes accountability. The Product Backlog Manager role is granted authority over tactical product decisions and is given a very costly, powerful tool to deliver on tactical product change and releases (the Scrum team). Accordingly, the Product Backlog Manager is accountable for the product changing to reflect the product roadmap.

Product Owner : Scrum role unifying the authority and accountability that would otherwise be distributed. The Product Backlog Manager and Product Manager roles in one.

• Highly available to the Scrum team
• Clarifies stories and negotiates scope within the sprint (a story is a placeholder for conversation; the product owner is the person empowered to have that conversation with Scrum team members executing the story)
• Articulates stories and prioritizes them in the product backlog
• Plans releases (over the next quarter, say)
• Articulates and maintains the product roadmap (6-12 months out, say)
• Articulates and champions the product vision
• Communicates outward about the value being delivered by the Scrum team
• Listens and negotiates with the customer, the customer proxies, the users to inform all of this.

With authority comes accountability. The Scrum Product Owner role is granted authority over the product and is given a very costly, powerful tool to advance the product (the Scrum team). Accordingly, the Scrum Product Owner is fully accountable for the value of the product to the customer.

Agile is about recognizing that we learn about a product by incrementally building the product and by gaining experience with customer and user reactions to those increments of product. Of course, that learning does not do much good if it does not effect product development. Agile is about steering, about changing the course of the product, at all levels, in response to what is learned. The Scrum Product Owner is the person empowered to change the product, and because there is someone empowered to change the product, it can be changed with agility.

Asked Pichler

One concern to have about the "small product owner" solution of splitting product owner into Product Manager and Product Backlog Manager is that it sets the stage for the "under-powered product owner" and "partial product owner" anti-patterns described in Pichler's book.

That would be the same Pichler who wrote the blog post.

So, I asked him about this.

I’m having trouble seeing how the “small product owner” approach avoids the “Under-powered product owner” and “Partial product owner” anti-patterns described in Chapter 1 of the “Agile Product Management with Scrum” book.

and here's what he had to say:

... If a small product owner is used while the product is young, the anti-patterns you mentioned are likely to manifest themselves. Once the product has stabilised and grows steadily, distributing product ownership across several people works in my experience – as long as the responsibilities are clearly assigned.

and

I find that a single, big product owner is particularly useful when a product is young and does not grow steadily yet. As the product matures, it usually becomes bigger and attracts more features. This can make it unsustainable for one person to own the entire product. In this situation, you have two basic choices: spilt the product owner role or split the product.

The former requires creating a hierarchy with a (senior) product manager or chief product owner at the top. The second option involves unbundling a feature and promoting it to a product in its own right, think of Facebook Messenger, or creating product variants, for instance, iPhone 6 Plus. New product owners/managers would then take care of the new products.

Both options have their strengths and weaknesses, and you can also combine them. In sum, I recommend that you consider the product lifecycle stage and what you need to do to make it or keep it successful when you decide if and how to apply the product owner role.

( see comment on the big vs small blog post )

Reading

I have gathered some annotated bookmarks of things that seem to support a product backlog manager role, at least in some circumstances.

And corresponding bookmarks for a "big" product owner role.

(And bookmarks about the product owner role generally).

Summary of the reading

Reading those bookmarks might be fun, and I have summary snippets attached to some of them. Here is some of what you might draw from reading those.

Scrum Guide specifies Product Backlog Manager role and does not have an opinion about product management authority above that

Looking to the modern Scrum Guide,

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

...

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

( source )

Sounds like the Product Backlog Manager role as I've described it above.

That is, Scrum itself, in the Scrum Guide, doesn't specify that the Scrum Product Owner role has product management authority above the tactical.

It also doesn't specify that the Scrum Product Owner role doesn't have product management authority above the tactical:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Okay. How this is done varies. What do the sources say about ways that work in doing this?

Some sources think "small" product owner aka Product Backlog Manager is a good idea

Some sources think that what Scrum needs is a Product Backlog Manager and that it was a mistake to think that that role also needs to entail Product Management responsibilities above the level of backlog management. Organizations already know how to do product management, so goes the argument, already make roadmaps and mission statements and compute profit and loss and all that, and those things are not necessary to combine with the backlog management to keep the backlog, well, managed.

From a Development perspective, the core issues that need to be addressed are:

• the need for ongoing backlog prioritization
• the necessary interaction with the Development team so they can make progress on the backlog and stay aligned with the needs of the business.

That’s it. Everything else, from P&L to budgets, to roadmap and vision ... are irrelevant. In most companies, those responsibilities already have owners so there is no need to muddy waters and blend them into the “Product Owner” role.

As a “role”, the term “Backlog Manager” seems reasonable.

As a title, “Technical Product Manager” (TPMs) is best, particularly for companies building commercial products. It’s unambiguous…the person is part of the Product Management team, there can be multiple TPMs working with multiple Scrum teams (not necessarily in a 1:1 relationship mind you), and they have a clear technical focus.

( source )

(Personally, I find that "not necessarily in a 1:1 relationship mind you" to be particularly broken. Part of what makes Scrum work is unifying authority to make product decisions from the perspective of the Scrum team so that the Scrum team can execute change with agility -- lose that single voice and you are heading for an Office Space style "I have eight different bosses right now".

But the "not necessarily in a 1:1 relationship mind you" was parenthetical. Reading the idea without the particularly broken parenthetical, it sounds a lot more reasonable -- the Scrum team needs someone to prioritize the backlog and clarify stories, be the conversant in stories-that-are-placeholders-for-conversations, so that's the role, and it need not be bigger, so goes the argument.)

Some sources think "big" product owner is a good idea

Ughh - product owner turned backlog manager? So sad :-( @DavidWLocke @brainmates @ProdMgmtTalk @johnpeltier

— Carol Kollm (@ckollm) July 7, 2011

The reasoning is simple for dividing product leadership, but we think it’s all wrong. At the end of the day, there should be one product champion driving the business forward.

...

splitting the product manager in half does not help her or the organization. It destroys both. With humility, hard work, and teamwork product managers can own their entire product and lead with conviction. And when they are given the authority to do so and held accountable, everyone wins.

( source )

and

All too often I run into companies that have ... two different people covering the product role.

Usually the way they split it is they have one person responsible for interacting with customers and stakeholders (which they often call the product manager), and another to interact with the development team and manage the backlog (which they usually call the [small] product owner [or product backlog manager]).

...

As appealing as this strategy [of splitting the Product Owner role into a Product Manager and a Product Backlog Manager] may sound, ... this approach typically yields very weak product and little innovation.

( source )

Some sources think "small" product owner aka Product Backlog Manager is sometimes a good idea, and sometimes a "big" product owner is a good idea

Maybe it depends upon

• nature of product
• releasedness of product
• maturity of product
• age of product
• size of team

Some of the posts about how the Scrum product owner role needs to be split are nuancing their advice on the context of the product.

Depends on whether a custom or mass-market product

The distinction might be whether you're doing custom in-house software development or you're developing a software product that will then be sold to many customers, to a "market" (think, say, Office365 from Microsoft's perspective). The argument goes that agile has in-house custom software development roots and the product owner role ala Scrum addresses some problems with this kind of in-house software development that arise when you don't have this unified role, but

One huge problem is when one person tries to do both roles. From personal experience, I can confirm that especially with large-scope products in multi-national corporations with products in multiple silos, it’s practically and effectively impossible.

( source )

This sounds like a strong call to separate the Product Manager (strategic) role from the Backlog Manager (tactical) role:

When the Product Manager occupies the role of Product Owner on the development team, splitting time between strategic marketing and tactical development items, both parts of the job suffer.

but he's talking about the context of developing an off-the-shelf product after an initial release. (Think: Microsoft Word or Office365).

For custom software vendors developing the first (or subsequent) versions of a product, there really is a single “Product Owner” that fits with Scrum orthodoxy. There is no “Product Manager” in this scenario representing a market of customers. This “Product Owner” is a representative of the single customer.

( source )

or

a single product owner who shares product manager responsibilities is the best choice in all quadrants except for a mature commercial product.

and

The Product Manager Should Team With a Product Owner On Mature Mass-Market Products

( source )

.

Depends on product age

If a small product owner is used while the product is young, the [under-powered product owner and partial product owner] anti-patterns ... are likely

but

Once the product has stabilised and grows steadily, distributing product ownership across several people works

( source )

Depends on engineering team size

When ... the engineering team is larger than about 20 — many companies split the product role. They decide to invest in a market-focused product manager who is externally focused and works on the long term vision, and an internally focused product owner who supports the engineering team and manages the software development details.

( source )

The argument here seems to be: a unitary product owner would be great, but at scale or where market complexity is high no one person can do that, so here's how to split up the responsibilities.

Conclusion

This blog post is not about concluding anything, it is just about sharing and summarizing resources. Conclusions are left an exercise to the reader.

Post photo credit : magia3e per cc-by-nc-2.0.