Episode Transcript
**Richard:** Welcome to the Humanizing Work Show!
Today, we're looking at the Product Owner role in Scrum, and specifically our real-world advice about a split PO role.
We'll discuss how the Product Owner was originally defined, why some organizations choose to split the role between 2 or even 3 people, whether that's a good idea, and how to get the best results if you're part of a split PO role.
## Sponsorship/Show Introduction
**Peter:** The Humanizing Work show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration. Visit the contact page on our website, humanizingwork.com, and schedule a conversation with us if your organization wants to see stronger results in those areas.
If you want to support the show, the best thing you can do if you're watching on YouTube is subscribe to the show, like and share this episode, and click the bell icon to get notified of new episodes. Drop us a comment with your thoughts on today's topic. If you're listening on your podcast app, the best thing you can do is give us a five-star review in your podcast app, and share the episode along with your thoughts and questions on your socials.
## Main Content
**Richard:** Let's start by talking about the Product Owner role and where it came from. It was originally just a renamed product manager. As the name implies, the goal was to emphasize ownership of the product.
It’s not just managing things, which can imply somebody who's just taking input from other people and creating documents from it, but a sense of really owning outcomes for a product.
It was designed to be an end-to-end role from understanding customers and markets all the way to collaborating with a team to make the product exist.
In Scrum, the PO role is one, unified role that sets the direction for a team.
And if the Product Owner role is designed to be one role, that implies that it's designed to be done by one person. And in the early days of Scrum, there was some unfortunate but evocative language around that, where Ken Schwaber would refer to the Product Owner as the "single-wringable neck," like the one person who was responsible for the outcome of a Scrum team’s work.
**Peter:** Despite that original design for the role, in many organizations today, the Product Owner role ends up being split between two or even three or more people. Why does this happen?
Well, we’ve seen two main reasons for it.
The first is a desire to match existing job codes through a career progression. One of the weaknesses of the Scrum roles is that there's not a clear way to have a career as a Scrum Master or Product Owner moving up a hierarchy and seeing progress in your career. That's important to people. They experience a sense of mastery and purpose from having more responsibility and more recognition and, for better or worse, that happens in organizations through promotions.
If you just have Scrum teams in an organization, things are fairly flat. So some organizations split the PO role so that it lines up with other job codes that have more junior and more senior roles. The junior ones are more tactical, working closely with the team. The senior ones are more strategic, working with customers and thinking about big picture stuff.
**Richard:** And the second reason that we see the Product Owner role get split is when the job gets too big for one person, which usually happens where you’re scaling an initiative beyond a single team or have a team serving multiple demand sources.
So either you have multiple teams working on the same thing and the job starts getting too big for a single Product Owner and you kind of have a hierarchy of Product Ownership that happens pretty naturally there.
Or you have multiple demand sources coming to a single backlog that one or more teams work on. And in those cases, you may not have one person that's the expert on all the things.
And for more on how to handle the latter, check out Ep 82 on the visionary versus facilitating Product Owner models. [tk link to [visionary/facilitating PO models episode](https://www.humanizingwork.com/visionary-vs-facilitating-product-ownership/)]
Either way, as the job starts getting too big for one person to do, it makes sense for more than one person to share it.
**Peter:** So you may have kind of an objective workload-related reason that causes you to split it. And you may also have a career progression reason that causes you to split the PO role. And both of those can intersect in the same context.
**Richard:** But is this a good idea? Does splitting the Product Owner role actually create the outcomes you want?
**Peter:** Well, I mean, it's going to create the career progression possibility. So it does that job, and that can be pretty important.
**Richard:** I think the other question we need to look at though is, does it create better outcomes? Does more value flow through teams? Do you get better return on your investments if you split the role?
And I think the answer there is a lot of times you don't. You see diminishing returns as things get larger and roles get split because coordination is a challenge. There's often not clarity at the handoffs between the different roles. And so information gets lost. There's rework. There's just building the wrong thing. There's lots of time for creating alignment. And that eats away at a lot of of the benefits that you might get.
With the rest of this episode, we want to talk through what do you do in that situation?
For one reason or another, it has made sense in your organization to split the Product Owner role. Maybe you have somebody with a Product Manager title doing a more strategic end of things. Maybe you have somebody with a Product Owner title doing the more tactical team-facing end of things.
How do you make sure that you don't pick up the downsides of that split, of lack of clarity at the handoffs, troubles with coordination and alignment?
Here's the secret for making the most of a split PO role...
Don't treat the parts of the PO role as you've split it as separate roles. Treat it as one role, owned by the most senior, most strategic person who does part of the role, with them delegating some of the role to others. It's a delegation problem.
And we have tools for thinking clearly about delegation.
Let's play that out...
**Peter:** When it comes to delegation, we find Jurgen Appelo's 7 Levels of Delegation a really useful model for thinking clearly about sharing power or authority. For most people, if they think about delegation or shared decision-making at all, they think of essentially three options:
- It's my decision
- It's your decision, or
- We have to agree on the decision
In the 7 Levels of Delegation, those are 3 of the levels, but they're not actually the most useful ones. There's nuance in between that's much more practical for real-world decision-making.
Level 1 is TELL. At level 1, it's my decision. I'll tell you what I decided but we're not really going to discuss it.
Level 2 is SELL. At level 2, it's still my decision, but I want you to understand why I made the decision, and I'm going to invite questions about it.
Level 3 is CONSULT. Now it starts getting interesting. I'm going to decide, but I'll consult you and take your input into account before I make a decision.
Level 4 is AGREE. At level 4, there's no decision unless we agree on it. Level 4 is consensus.
Level 5 is ADVISE. This is the mirror image of level 3. Now, it's your decision, but I want you to seek my advice before you make a decision.
Level 6 is INQUIRE, the mirror image of level 2. You decide, but after you've made it, I'd like to be able to ask questions about it to make sure we're aligned.
Finally, level 7 is DELEGATE. It's totally your decision, and I may not even ask you about it.
**Richard:** So how does this apply to a split Product Owner role? Well, we can take the whole series of decisions that a product owner needs to make from what target customer are we going to go after, what problems are we going to focus on for them, what's our vision for a successful outcome on this initiative, all the way down to what are the details of this backlog item at the top of a product backlog, and everything in between.
You can list out that whole series of decisions. And check out our PO board model to get a nice visual for how those decisions chunk out over time horizons in a backlog. [tk link to Ep 45, [PO Board model episode](https://www.humanizingwork.com/poboard/)]
Then for each of those decisions, model it as the most senior person delegating parts of the role to others.
[tk do animated graphics for the following to connect the decisions and levels. Could just be our Miro frame from HWLI, highlighting the relevant stickies and delegation levels as I say them.]
You may have the chosen customer segment, the target market sitting at a two. I'm going to decide that, but I want you to understand why I decided it.
You may have the vision for an initiative sitting at a three. I'm ultimately going to own the vision, but I want to get your input and perspective as I do it.
We might do some feature mining together and agree on the first feature to explore. That might be at a four.
Breaking the feature into stories might sit at a five. I'm going to provide some input about that, but you can come up with the stories that make sense as part of this feature, and it's up to you.
The details of those stories and what done looks like, that might be a five or six.
You can see there's this progression from less to more delegated as things get more tactical.
We've skimmed over just a handful of decisions here, but you'll see the most strategic are going to be at the top of the levels of delegation. The more tactical are going to be at the bottom of the levels of delegation. As they pass through levels three, four, and five, consult, agree, advise, you get these opportunities for creating alignment at the handoff. You don't have this hard, it's mine, and then suddenly it's yours, which causes information to be lost. Seeking and taking advice into account around the middle of the handoff provides opportunities for creating alignment and shared clarity on the job.
## Practical Application
**Peter:** That's how we recommend being successful with a split PO role. Figure out what decisions need to be made as part of the product owner role, and then figure out how the more senior, more strategic, person is effectively delegating pieces of that product owner role to somebody else and at what level of delegation. You may not agree on this, so it's good to negotiate where those boundaries are and how you're going to make those decisions.
One of the big breakthroughs that our clients often have is realizing all these things that they were acting like were at level 2 and 6 are really at 3, 4, and 5. Agreeing explicitly on those things makes it much easier to work together when multiple people are sharing a role like this. It makes expectations really clear.
## Call to Action
**Richard:** If you can avoid it, I would say don't split the PO role. Keep it simple. Start with one person who owns something end-to-end, but in the real world, as organizations scale, as initiatives scale, you may need to split the role to make it manageable, and
*"If you must split the Product Owner role, don’t treat it as separate roles—treat it as a delegation problem and get crystal clear on decision-making."*
If you'd like to learn more about these ideas, join me in an upcoming Product Owner or Advanced Product Owner workshop. You can find the details at humanizingwork.com/cspo. [tk link to CSPO landing page]
And if you want help working out a split PO role in your unique context, contact us through the contact page on our website.
**Peter:** Thanks for tuning in to this episode of the Humanizing Work Show. We'll see you next time!
