Product Ownership Topology: Who Makes the Tough Calls?

How to organize product ownership? How to think about product owners, product managers, what’s the relationship between them? Do we even need these two roles? Are there roles? Are there responsibilities?

It’s a common conversation and a common challenge, and there are a lot of different perspectives out there in the market.

If we look at the landscape of advice that you get from the different frameworks, there’s the Scrum approach, which says the product owner should be the owner of the product. It’s even in the name. And if there’s a product, it should have one product owner, typically. Large Scale Scrum does talk about the fact that if you have a huge product, you might need a chief product owner. But that’s more or less the Scrum world.

The Scrum world doesn’t talk about the product manager as a title, but we do teach that the product owner should be an agile product manager. They should use product management to maximize the value that the Scrum team creates. And because the product owner is an accountability, or at least should be, that means that anybody could take that accountability. Meaning a lot of the time, product managers are the right people to take on the product ownership accountability. I even like to call it product ownership rather than product owner, to emphasize this point that it’s an accountability.

SAFe of course does split the role. There’s product management, who essentially own product leadership for an Agile Release Train and a group of agile teams. And there are product owners that work more with a single team or a couple of teams and focus more on the team level. But if you look at the modern, current guidance in SAFe as well, you’ll see that there’s quite a bit of overlap between the responsibilities of these two roles. Both product managers and product owners should connect to customers. They should think from a product perspective about outcomes and steer with evidence. Both of them should drive feedback loops. Both of them should connect to stakeholders and manage expectations.

Another perspective you might take is to take product ownership out of the picture altogether. Let’s imagine there was no Scrum. If you were just building a product organization, how would you structure this?

You typically have, as Melissa Perri talks about it, junior product people working more with one team or focused on a specific feature. You’ll have more senior product managers that start to own either a mini product or a product. Even more senior product managers, or group product managers, might start to own a mini portfolio of products. And even more senior product managers own portfolios of products.

That makes sense, right? But it also raises the question: how do you map that to the reality of “I need to figure out product ownership and product management in my organization”?

Say you really have one relatively small product, and one team that will be able to work on that product. The empowered product team, the ideal that we talk about in the modern product organization. Even then you have a couple of options.

One is to say there’s one product person who’s wholly responsible for everything needed to maximize the value created in this product team. That product person would own customer relationships and understanding the market. Everything related to product management, figuring out this product. They would also own the relationship with the team: figuring out what the team should be focused on, answering the team’s questions, helping them deliver value, giving feedback on the value that they’re creating.

What’s frightening, a lot of the time, to product managers that are asked to do that, or to organizations thinking about asking product managers to do that, is a misunderstanding about what Scrum says about the product ownership responsibilities. The thinking is that if you are the product owner for a team, beyond being a product manager for the product, you need to do a lot of things that classic product management doesn’t include. Writing stories. Being with the team day in and day out. Helping them out with a lot of technical stuff. Product managers don’t feel that comfortable doing that, or prefer to spend more time with the customers, or simply feel they need to spend more time outbound than inbound.

That’s a fairly common misunderstanding of Scrum. What we say is the product manager doesn’t have to do all of these things. They just need to make sure that value is delivered by the team and keeps flowing. If it’s useful for them to use user stories, great. But whoever has the product ownership accountability doesn’t have to write all of these things themselves. They don’t have to write all of the acceptance criteria for the stories. They’re responsible for these being the right things for the team to work on. So they need to be in touch with the team. But how is that different than, for example, responsibility for the classic PRD that the team uses to work from?

I think the first lever you have to simplify your product leadership topology is to understand that product ownership doesn’t need to mean much more work than you’d naturally think about in product management. If you have a strong team, they could take on a lot of the work that is needed to break a feature down into smaller slices, iterate through it, and deliver value. And if you don’t have a strong team that can do that, maybe figure out ways to strengthen the team. Maybe bring into the team people that can do some of these things.

So whoever you thought could take on what you might call a technical product ownership role and focus on all of this stuff, maybe they belong on the team rather than being a product owner. Because if you do make them the product owner, they will feel like they’re not really an empowered product owner. They will feel like somebody else decides which features we’re building, somebody else owns the product direction. They are, in a sense, a proxy.

Product managers SHOULD take on the responsibility of product ownership for their product. Whether they’re excited to do so is an excellent sniff test for whether your team topology is product-oriented.

There’s another topology, which is to split the product role into outbound and inbound. That’s a classic split in the product management world. One way you could frame that in Scrum terms is product manager and product owner. I’m not sure that’s the best way, actually. An alternative would be to say that the outbound, or overall strategic, product manager is the product owner in the Scrum world, and you have a technical product owner for the inbound work, or don’t even call that product owner.

But the reality is that in most organizations at this point, what you’ll see is that the technical or tactical product person is called the product owner. It’s a shame, but that’s the reality out there.

Let’s complicate this a bit. Say it’s still one team, but this team is working on a product that’s sort of a platform product, with multiple other products that it’s serving.

Think, for example, about a hybrid hardware-software company. They have multiple hardware products that use more or less the same software. You might call it driver, automation, firmware. There are variants. They deliver features and capabilities that are specifically needed for a specific hardware product, but they are also advancing the platform in order to support all of these products.

You can think about the firmware for printers. There’s a set of printer models that all use similar software, and the software needs to support different capabilities for these different products. What really sells, what goes to market, isn’t the firmware. It’s the actual printer. So the printer products have a lot of sway in the organization. They are the ones that own the P&L.

So if you’re the owner of this software piece, the automation piece, and you’re working for these products, you have a challenge. Whether you’re in life sciences or consumer hardware or whatever. You’re called the product owner or the product manager for your product. Doesn’t really matter what’s the name at this point. You have very strong stakeholders that each have their own roadmap, their own commitments, their own salespeople with quotas. Those salespeople are asking them to commit to certain features of the software or the hardware that they need you to support. So if you look at your backlog, a lot of it is controlled by your internal customers, the internal products that you’re supporting.

That brings challenges, especially if the topology is that you’re thinking about this as a technical internal product. It makes sense to have a product owner for it. But because it’s not market facing, it doesn’t deserve a product manager. In a lot of these companies the product management organization is separate from the engineering organization, and it doesn’t consider this a product that deserves proper product management attention. So there’s only one engineering-side product owner. They have to maximize the value that they’re delivering to these products, and they have to make some pretty tough decisions when it comes to who do I support.

I’m getting asks from five different products. All of them say their stuff is revenue driving and all of them say it’s the most important thing. How do I make decisions? I’m not even in the business organization.

It’s a recipe for a lot of frustration for everybody. What typically happens in these sorts of organizations is a lot of power plays and escalations, where the product owner cannot really own the roadmap of their product. A lot of the stuff is escalated to a higher level, whether you call it portfolio, product, prioritization group, leadership team, whatever. Or just informal conversations between engineering and product management leadership.

So what could be a better setup for this? It’s almost obvious that my perspective is that despite the fact that this isn’t a market-facing product, if it’s so strategic for delivering market value because of its value for the other products, it does make sense to have proper product management for it. A platform product manager that is close to the product organization, that sees holistically across the business, probably makes sense here.

An approach you might take is to say, you know what, now that we understand what Yuval is talking about with the product ownership role, maybe the product owner for this product is actually the product leader responsible for the portfolio of these market-facing products. So if there’s a product leader for the division that is all of the inkjet printers, let’s say, or consumer-facing inkjet printers, just to keep it a bit more manageable, maybe they are the person that should be the product owner for this product. Even though it’s a technically focused product. Even though it’s a small team.

Now, you might be shaking your head and saying, what? How could a leader, a group product manager, let’s say, be the product owner for this team?

If you’re thinking that what they would need to do is to write stories and be there with the team day in and day out, then you’re right. It’s probably not the right fit. But if you’re thinking about it as the person that owns the roadmap, the strategy, the goal, the tough decisions that need to happen on this product team in order to maximize the value that they bring to the organization, then who else is gonna do that?

I’d argue that in reality, the people making these decisions, the ones that eventually maximize the value this team delivers, are these more senior product leaders.