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 for joining us Greg. >> 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 are adopting Agile and in particular Scrum. And all of a sudden, you have 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 the only person to tap was the product manager. >> Yeah. [LAUGH] >> The product 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 Enthiosys 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 phasing and development phasing activities and to have that deeper development phasing that you do if you're a product owner. So I was with, 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 tech space. And their commercial product owners, they are paired with a, I’m sorry, personal product managers are paired with a dedicated product owner, so there 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 PMM 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 market place 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 are not spending enough time out in the marketplace working with customers, analyzing that, building up 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 is 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. The 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, you can't as a product manager, you can't get your information secondhand. You have to go- >> You can't get all your information secondhand certainly. >> 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 your product manager and your spending too much time, you're not spending enough time in the product owner role or you're working with the 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 teams, 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 in that product. And what's going to happen is when you get to the end of a sprint or a development cycle you're going to hear the lines like, well that's not what I meant. Wasn’t probably intended and you're going to have a lot of rework in that kind of situation. >> Yeah, and we’d like to close with some tips or some ideas. So for the product manager who let's say their boss just told them, the first product manager of their company or group and they said, well we need to you know we're growing, we need to scale this up. So why don't you figure out product manager, product owner, and you just sort of give us an idea about how you think we should scale the organization and what everybody should be doing in the current and in the future. What do you recommend to this person? >> Right, yeah that's a great question and I think that is one of the inflection points scaling, where you need to think about 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 a really tight, even tighter collaboration, then once you're in a mature market between team and the product owner, and the PM. So in that case there was 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 the point you move into scaling, you want to separate those roles. On another interesting situation I see and I could tell you the example of at least one company is a lot depends on the maturity of the engineering team as well. So, this was a situation where this company I was working with, the product manager specified a report. This is a mature product, it already has 50 reports or something in it. And the new report came back and you couldn't sort it on the column headings, all other reports in 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 the product manager or product owner, whoever is playing that role of product owner, needs to spend a lot more time with the team. >> So when you say maturity, you kind of mean that the engineering team's understanding of the product standards that designers, project managers, engineers should probably be co-creating together. >> Exactly, so there's the set of standards, but there's also a chance there that it was how this product was architected? They didn't even just have a standard framework for a report to get put into. >> Yeah, okay. >> Right, so also there's two sides to that and in those cases you got to spend a lot more time detailing the requirements and ensuring the engineering team understands that. >> Yeah. >> I have 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 can think roughly, I would say at 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 staff. That first example, internal customers versus a large commercial product. >> Got it, well that is some excellent, practical advice from the community of practice from Greg Cohen. Greg, thanks again for joining us. >> Thank you, Alex.
