Greg Cohen on PM v. PO

We’ve talked about the difference between the product manager role and the product owner role. And joining us today is Greg Cohen, author of Agile Excellence for Product Managers and a practicing product manager himself. Thanks you for joining us, Greg. >> Well, thank you, Alex. And thanks for having me. >> Now can you talk a little bit about this difference between the product owner role and the product manager role? >> Yeah, absolutely, and for me, I started observing this in about 2010. When a lot of companies were adopting Agile, and in particular, SCRUM.

And all of a sudden, you had this situation where they had SCRUM, they needed a product owner that’s defined as a role that’s necessary for SCRUM to happen. And person to tap was the product manager. >> [LAUGH] >> The project manager was very busy doing a lot of business facing work thinking about stuff beyond features like whole product. What are all the services that need to wrap around it, they’re supporting the sales team, they’re supporting marketing. And a group by the name of Entheosis did some research. And they observed that when a product manager is tapped to be the product owner, their workload can go up by 40%.

And that just overstretches you if you’re a full-scope product manager doing both business facing and development facing activities. And to have that deeper development facing that you do if you’re a product owner. And I think we’re only beginning to get sort of the handle around this. But I was with a company recently, and I think they had a really great division of it. They have a number of commercial products. They’re in the health text space and their commercial product managers are paired with a dedicated product owner. So they’re a PM PO team. At the same time, that company has some internal software solution tools. And in that case, it’s just a product owner.

That product owner plays the PM and PO roles.

>> And why do you think they made those decisions? >> When you’re dealing with an internal team, so that was the case where they just said, we only need one person here. In that case, your audience is fairly contained. It’s easy to go out. It’s easy to reach them, talk with them, understand what their needs are. Because they’re all within the company, you don’t see a lot of variation. They don’t need to think about generalizing that solution for a marketplace or doing segmentation analysis. And that individual doesn’t have to deal with interfacing with sales, professional services, marketing. The scope of the role is a lot smaller and it can be handled by a single individual.

>> And tell me about what things do you observe when you’ve got a situation where a product manager is spending too much time as product owner and they should probably think about an alternative? >> Right, at some point if they’re doing that, they’re spending too much time with the team and they’re not spending enough time out in the marketplace. Working with customers, analyzing that, building a product strategy. And ultimately, the products start to kind of miss the target. The competition catches up or even moves ahead. I was working with one company and they had the case, so this gets confusing because there’s the role, product owner, product manager, and then there’s the title. >> Yeah.

>> Well, the individuals were titled Product Managers, for starters, but they were really internally facing. Their job was to develop breakdown features and decompose them for the engineering teams to build. And in this case, they were getting all their information either directly through sales or through field marketing. So they were removed from the customer. They were not having significant direct interfacing with the customer, and they got into trouble. That didn’t work. As a product manager, you can’t get your information secondhand. You have to- >> [CROSSTALK] You can’t get all your information secondhand, sir. >> Exactly, you can’t get all your information secondhand. You certainly do rely on what sales tells you and your marketing team tells you.

But you have to go out and you have to validate that.

>> Got it, and what about the reverse? What about you’re a product manager and you’re not spending enough time in the product owner role or working with engineering. What does that look like? >> Yeah, in that situation, the product team is getting ignored, in essence. And the big thing about Agile development is it’s a real change, and you are developing product collaboratively. You are working in step with your engineering team, spending a lot of time with them. And that’s necessary for that process to work. So in that case, the product manager is ignoring the team. The team still has to deliver. And they will figure out how to deliver the product.

But you’re not going to really get the customer voice on that product. And what’s going to happen is when you get to end of a sprint or a development cycle, you’re going to hear the lines like, well, that’s not what I meant. >> Mm-hm. >> It wasn’t what we intended, and you’re going to have a lot of rework in that kina situation. >> Yeah, and what we would like to close with are some tips and some ideas. So for the product manager who, let’s say, the first product manager of their company or their group and they said, well, we’re running. We need to scale this up. So why don’t you figure out product manager, product owner.

You just sort of give us an idea about how you think we should scale your organization or what everybody should be doing current in the future eyes? What do you recommend to this person? >> Yeah, well, that’s a great question. And I think that is one of the infliction points scaling where you need to think about doing that split. So I was with a startup. We were working in a market that doesn’t exist, we’re trying to create it. You need really tight, even tighter collaboration than once you’re in a mature market between team and the product owner and the PM. So in that case, there’s no revenue here. I was doing support on it. I was even doing QA.

It makes sense to have that as a single role. But at the point you move into scaling, you want to separate those roles. Another interesting situation I see, and I can play the example of at least one company, is a lot depends on the maturity of the engineering team as well. So if this was a situation where this company I was working with the product manager specified a report. This is a mature product that already has 50 reports or something in it. And the new report came back and you couldn’t sort it on the column right? All other reports on that product were sortable.

So this is a situation where you have a less mature engineering team and you probably don’t have style guides and standards in place. And product manager and or product owner, whoever is playing that role of product owner, needs to spend a lot of time with the team. >> When you say maturity, you kind of mean the engineering team’s understanding of the product standards that designers, product managers, engineers should probably be co-creating together. >> Exactly, so there’s a set of standards. But there’s also a chance there that it was how this product was architected. That they didn’t even just have a standard framework for a report to get put into. >> Yeah, okay, got it.

>> So there’s two sides of that. And in those cases, you’re going to spend a lot more time detailing the requirements and ensuring the engineering team understands that. >> Yeah. >> I’ve also worked with engineering teams where you have a very high level of discussion about what you’re looking for. And the engineers could go off and deliver it exactly how you envisioned it.

So it depends on the maturity of the team. It depends on, I would say, the size. You’d think, roughly, I would say, the point when you’re hitting a product that’s $50 million in revenue, you almost always need to split that role. That’s a really rough rule of thumb. You can think about where you are sitting in the product stack. That first example, internal customers versus a large commercial product. >> Got it, well, that is some excellent practical advice from the community in practice from Greg Cohen. Greg, thanks again for joining us. >> Thank you, Alex.