Product Owner vs Product Manager: Worry About Outcomes not Titles
Over the past year I’ve worked with hundreds of product managers in dozens of companies, and there’s been one question that has sounded like a persistent drum beat: “What is the difference between the role of a product owner and a product manager?”.
When confronted with this question, I used to hesitate, because from company to company there are a million things that can affect the roles; the product, larger organization structure, product development process, cultural differences, regional differences in commonly-used titles, the list goes on.
On the advice of my colleague Martin Eriksson, I now turn the question around on the questioner, and put forward two questions for them to consider, namely: “What are you trying to fix?”, and/or “What outcomes are you looking to achieve?”. It makes sense that before you look to impose a new or different role, you should have a clear understanding of what’s happening now.
At a high level, there are two buckets of work. The first is to set the strategic vision and continual alignment of the product with the rest of the organization. The second bucket is implementing, tracking, and reporting back on progress. In my experience, one role handles elements of both of these buckets. In Scrum that person is called the product owner. In Agile that person is called the product manager. In general, when referring to these responsibilities the two roles are completely interchangeable.
Complexity is introduced when organizations add a layer of hierarchical oversight, aka the layer that is ultimately responsible for making decisions about the product vision. When I worked at Pivotal Labs, an Agile shop, we referred to our client sponsor as the product owner. They could also be referred to as the business owner or more generally the key stakeholder. In organizations that implement Scrum, this becomes muddied because the product owner runs the backlog, but isn’t empowered with a final say, so a product manager gets slotted in. You see the rub?
Mind the Product Training is currently working on a project that illustrates this point. Despite the fact that I’ve been a digital product manager for the past eight years, I’m not a product manager at Mind The Product – I’m the Director of Training Products. My main remit is service design for our training programs. Yet, there are several digital products that Training needs in order for the service to function properly and I don’t have time to manage those projects and deliver our service.
Enter Christopher Massey, Mind The Product’s Product Manager (so meta). He is responsible for the planning and delivery of all of Mind the Product’s digital products, including our website and admin tools. Our training program is past its testing phase, and we can now turn our attention to honing our digital interactions and touch points. So I called for a meeting with product (Chris), marketing (the brilliant Amy Roberts) and myself. We came out with a nice plan for moving forward with our needed training pages. Chris will be the product manager, and I will be the product owner.
So let’s unpack this a bit. Why is Chris the product manager in this scenario? Simply put, it’s his current title, but more closely, he will be managing the breakdown of vision into workable stories, and will ensure that the delivery team understands intention, value, and priority. Chris will manage the “how” of the product. My role as product owner will be to hold the training goals and vision so that the digital products can be appropriately guided. I will own the “why” of the product because I’ve spent the past 12 months figuring it out. At other times, for other products, Chris will actually wear both of those hats because he will have done the work to create the product vision, and he is empowered by Mind the Product to do so. In those cases, there is no need for a product owner.
My point in presenting this scenario is that the titles are not as important as understanding the outcomes that you would like to achieve, and the weaknesses in your current structure and process.
Here are some questions that you could take to your team, not necessarily to impose a new or different role, but to understand whether your product role is appropriately empowered and supported to deliver the product.
- Who is currently doing what right now?
- What are you trying to fix first? Second?
- What are the main challenges of the key players?
- Who holds information you need?
- Do you feel you have clear access to the information you need?
- What is your process for making decisions?
- Is there clarity around current process? Is ownership clear? Are your people empowered?
- Is alignment and reporting an issue? Why?
- What does success look like?
If you gather answers to these questions via one-to-one interviews with relevant parties, you will at least come up with a better understanding of what’s happening in your team. Next, I would recommend a collaborative retrospective framed around improving process, focused on creating action items with assigned responsibility to individuals. This would then become your “beta test” for changing roles.
I’d like to hear from you. Do you have product owners? Product managers? How does it work for you?