You’re not doing it wrong. You’re doing something different, and you can do that well.
In this episode, Richard and Peter answer a question that’s essentially: “Most of the standard Product Ownership advice doesn’t seem to apply to my situation. Am I just doing Product Ownership wrong?”
Listen in as they discuss two modes of Product Ownership—visionary and facilitating—and when each one is the right approach.
Learn More
Episode Transcript
Richard Lawrence
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!
Today, we’re talking about Product Ownership, and how many Product Owners are in a situation where most of the standard advice doesn’t seem to apply. We’ll share a distinction between what we call Visionary Product Ownership and Facilitating Product Ownership that has been really useful for many of our clients.
Peter Green
Before we jump into today’s episode, we want to help you with whatever challenges are most frustrating you right now. If you’re feeling stuck on something, whether that’s trying to take a more human-centric approach to your work, trying to make your product or business outcomes better, or if you’ve just got a more tactical, process-related question, let us know about it. Send us an email at mailbag@humanizingwork.com with a few details about your situation, and we’ll share how we might think through thar challenge right here on the Humanizing Work Show.
Richard
And just a quick reminder to rate and review the HW Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you. We really appreciate your help spreading the word is super meaningful to us!
Peter
And if you want to get access to more content we produce, not just the show, you can sign up for our newsletter where we share one key idea every week. Sign up at humanizingwork.com/hwnews.
On to today’s question:
We got this question from a Product Owner in a pretty large company: “I hear this Product Owner stuff about vision, strategy, business cases, etc. But my role mostly seems to be managing all my stakeholders’ requests and getting them through my team. Am I just doing Product Ownership wrong? Should I be making more strategic decisions about my stakeholders’ stuff?”
Most descriptions of the PO role assume the PO has a certain level of authority, as the name “Product Owner” implies. They own the product, its vision, strategy, biz outcomes, etc. But many POs are playing the role for a team that provides a core capability or service to a number of internal and possibly external customers. In that case, a lot of what we teach about customer research, strategy, and how to prioritize for value seems much harder to do for those Product Owners, if not impossible. Richard, I’ve heard you talk about two different kinds of Product Owners, the visionary product owner and the facilitating product owner, and that seems to be a really useful way to think about this. Would you tell us a bit about what the difference is, and maybe where they came from?
Richard
Sure. I think the best way to explain it is to go back to the original situation that caused me to make this distinction.
Some years ago, I was working with a Product Owner at a client who was in a situation very much like the one described in today’s question. This Product Owner was the keeper of everybody’s lists. She had a team that created features, did updates, for a number of different applications around the finance area for this big company, that kind of owned all the financial stuff, and there were more than a dozen different stakeholders across the organization who needed different things to change in those applications, so this Product Owner had a spreadsheet for everybody’s requests of all the things they might need, and she was kind of the keeper of the lists, and then did some kind of rudimentary prioritization to figure out which thing came next across all these different lists or aggregating that into a backlog of some sort for the team, but it was an exhausting role, running around and keeping track of all the different stakeholders’ things, and a lot of the time, it was managing things on these lisst that were never making it up to the top of the backlog so it felt like a lot of her work was wasteful.
And she was feeling this tension with the way the Product Owner role is described in the Scrum Guide and the way it’s described in our Product Owner courses, where we’re talking about the Product Owner as the visionary, who knows where the product should be going and decomposes that vision into features and features into user stories, and all the stuff that you hear us talk about around Product Ownership, but that really didn’t seem to apply here. There wasn’t one vision pulling this all together. She didn’ have the strategic expertise over all of these things to even make prioritization decisions about it. And really, nobody did. So it wasn’t like it was the wrong person for the job and we needed a visionary Product Owner in there; it was really a different kind of a situation.
So we went looking for a way to make this work better. And the first move was to stop keeping everybody’s lists. Teach them how to keep their lists, and only take the top things from everybody’s lists. So she started getting this group of stakeholders together, I think it was monthly, and asking “What are the most important things for you right now?”
Now, those were still kind of messy things coming in, and some of them were like, “I need the team for the next several months, and nobody else gets them,” and that of course, wasn’t going to fly, so she realized part of her job, now, was not just having them keep their lists and getting them together, but having them get good things on their lists, like helping them come up with minimum marketable features- small slices of value that would have a real impact for that stakeholder that could then get aggregated together into a backlog.
So she was kind of facilitating helping them do a little bit of Product Ownership, and then facilitating this negotiation about what’s most important and what should come next, so even though she wasn’t the one making the calls about the strategy and ultimately the prioritization, she was facilitating the work they were doing around Product Ownership, kind of collectively, so that they ended up with the kind of outcomes that you want a Product Owner to produce. So I came to call that way of working “facilitating” Product Ownership; and we said instead of trying to turn that into the traditional approach, which I came to call “visionary” Product Ownership, where the Product Owner holds the vision, let’s make this facilitating Product Ownership as effective as we possibly can, and look at the skills, behaviors, practices, tools, that would make that happen to produce the outcomes you want to see from a team always doing the most valuable thing.
So, to summarize, visionary Product Ownership is the thing we talk about by default in Scrum, where the product owner really does own the thing end- to- end, has the vision, works with the team to achieve that vision,
Facilitating product ownership is where the Product Owner role is aggregating many sources of demand for a team and still working in collaboration with all those different demand sources to make sure that the team is always doing the most valuable thing and getting those increments of value to Done as quickly as possible.
Peter
Yeah, my first reaction, when I heard you say the word “facilitating” Product Ownership, or that term, and described briefly what it was was like “So is this just a bandaid on a bad org structure?” But then something you said, in there, where nobody–no one person actually did have the strategy, but the collection of them kind of did, the capability to come up with the strategy for what that Product Owner’s team should do existed– it just didn’t exist in any one brain, and so it really required like this organism of multiple stakeholders to somehow agree on something. And that could be a strategy for her team, but there were a lot of competing kind of demands for that. How do you think about that?
Richard
I think there is a situation where you could end up with this as a bandaid over a bad org structure choice, or just choosing not to do the Product Owner job, because there’s a sense in which every Product Owner is aggregating information from a number of sources, even if you’re just working on one product, you have a bunch of different customers, and you’re getting input from them, and you’re trying to decide what to do– so we don’t want to abdicate the role, and just turn it into “We take requests and we run them through a team.” That’s that feature factory anti- pattern, and we don’t want to end up there. I think the thing that makes this different, is you have a team that works no a number of different things, and you have various demand sources that know different things, and there’s not really a unified vision or strategy around them, so it’s like pulling together a supply of delivery capability and pulling together a bunch of different demand sources, that all have some sort of thematic thing in common, but it really isn’t about working on one product or making one unified group of customers happy. It’s that kind of “many to many ” relationship that you’re pulling together. Because maybe, strategically, you don’t want to dedicate a whole team to each of these things. Maybe there’s not always enough demand– there’s not always a “most valuable thing” to do. And so you’ve chosen to aggregate that supply in order to be able to do what’s most important at different times– but there’s no one person who can really be the Product Owner over that in a visionary kind of way. So I think it actually is a good solution, often in an IT situation– an internal thing like this was– the team that was working on all these different financial systems. It made sense to generally aggregate the supply of enhancements to financial systems.
Peter
Are there other situations besides that, where you’ve seen this pattern useful, where it’s not really like an IT team providing services across multiple stakeholders, but they needed the facilitating style of Product Ownership?
Richard
There was another client I worked with that wanted to adopt Scrum, but they were in a situation where it was almost impossible to fill the Product Owner role. Here’s why:
The work they were doing was in service of scientific researchers, and those researchers would get grants to study a particular thing, and then this part of the university would provide data analysis tools and features on some existing systems to help them do their research, so their grant would have you know– 1.5 FTE developers funded in there, and before Scrum, they would get one person full time and another person half time– so there was a project manager kind of trying to manage the supply of developers across all these different researchers, some of the things they were working on ended up on the same tool; other things they were working on were pretty bespoke, for a particular research initiative. Most of those developers were pretty overwhelmed, with the multi-tasking across all these different things, and the researchers weren’t always getting what they wanted so they had this hypothesis that maybe Scrum could help. Maybe we could turn these 14 developers into cross-functional teams, but then they had the problem of “Who’s the Product Owner for that?” Not only was there nobody in the organization who could fill that role of being the visionary for all these different things– there’s literally nobody in the world. Because each of these researchers was the one person who was the expert in their particular field of research, and there’s nobody who could sit over all of them and say, “No, your thing isn’t important. We’re not going to work on that right now.” So that was another place where it made sense to actually start with the facilitating Product Ownership model, because we had the same pattern of aggregating supply across several different things to serve a collection of demand across several different sources.
That turned out to work really well for them. Not only because they were better able to manage the flow of work through that and have a whole team swarm around something for a researcher and really make progress for them, and then turn their attention to something else instead of a trickle of one person full time for a year or half time for a year, they were also able to find ways to build capabilities that would be useful over time. So the shared data analysis tools ended up growing because now you had a group of people seeing the patterns that were happening across all these different research initiatives. That was a really good move for that organization.
Peter
I’m thinking about when my team was part of the Creative Suite at Adobe, and those Product Owners in the PhotoShop, Audition, Premier Pro– those were all really strong visionary Product Owners– really understood thee customer, really understood what they were after, but as you described this, I can think of times when even those Product Owners were using that approach for some things. When our team needed to contribute to a broader Creative Suite initiative back in those days, somehow we had to figure out how to do it, what the goal was, how to slice it up, what the priority or those things was, and I can see that even teams that were part of a broader system, would really benefit from having this play in their playbook. Where most of the time, my focus is on visionary Product Ownership for my thing, but because we’re part of a larger thing, there’s a real benefit to bringing the people together, all who have different needs and desires around those things and doing a little bit of this facilitating Product Ownership, to say “How are we going to split up this larger effort– how do we decide what’s most important out of all that?”
Richard
Right. I think there’s a set of skills and practices there that, as you said, are a good play to have in your playbook for those situations where you have demand coming from sources who really are the expert on the thing, and you’re not, so you want to bring their voice into it, and you want to facilitate helping them communicate with your team in a useful way, or helping them negotiate with other stakeholders in a useful way. So a lot of Product Owners should have this in their playbook, even if most of the time they are operating in that standard visionary Product Owner model.
And the reverse can be true as well, which is what we saw at that university organization, where, over time, that facilitating Product Owner started getting a vision for some of the shared data analysis tools, and putting on the visionary Product Owner hat for a while, when those things came to the top of the backlog. So I think they’re two centers for how you may work as a Product Owner, but I can see drawing from the other one, as is appropriate for your context.
Peter
Thanks, Richard, I think this will be really useful to Product Owners of all types, whether you’re primarily visionary or primarily facilitating, and, if you’re in that second camp, having some language for this and a way of thinking about this, and really permission to say “Yeah, I’m not going to create a vision for these 14 different business units, all who want different things, that’s going to stick. Like, yeah.” You can drop your shoulders a little bit and say “All right, this is the situation I’m in– I’m going to take this other approach.” That’s really helpful.
Richard
Yeah, you can feel good about, you’re not doing it wrong, you’re doing something different and you can do that well.
Peter
Please like and share this episode if you found it useful, and keep the questions coming! We love digging into topics like these, so send them our way. Thanks, everybody.
Last updated