Product Manager vs Product Owner: on the deceptiveness of Product Management job titles
After reading the title, you might be thinking why am I asking a question with an obvious answer: Scrum requires a Product Owner, so you must hire a Product Owner. Duh!
Well, wouldn’t it be nice and dandy if things were that simple? Let’s take a step back and reflect by asking a different, but related question: who do you hire to be a Development Team member on your Scrum Team?
It depends on who you need in your Development Team. It could be a UX designer, DevOps engineer, QA engineer, Full-stack developer, Back-end developer, or a Front-end developer. Heck, it could be any kind of role you need for building your Product Increment.
You hire someone with the right knowledge to fill the role. Whether this person has experience with Scrum or has a Scrum developer certification is less important than having the skills to do the actual job. You don’t hire for the role in Scrum, you hire for the job they are supposed to do.
Now let’s return to the Product Owner role. What kind of person has the right knowledge to take on this role? Before we can answer this question, let’s start with the definition of Scrum:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. — Scrum Guide November 2017 version
The key part is in bold: delivering products of the highest possible value. This is where the Product Owner comes in. The Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team.
How does the Product Owner do this exactly? Well, there you are on your own. Scrum is relatively prescriptive when it comes to how you build something, the delivery of the product. Scrum helps to build the thing right with a short time-to-market. Scrum provides little guidance for building the right thing apart from conveniently putting all of that in the lap of the Product Owner.
Product Owners worry about many facets of delivering value with a product like: what should we be building and why? How do you validate if what you have built is successful? How do you include your stakeholders in an effective way to maximize the value your product delivers?
Scrum provides no answers to these questions: you’re on your own. This is intentional because Scrum is a process framework and not a process. The strength (and weakness) of Scrum is that you need to supplement the framework for it to be successful. Using just Scrum is not enough to build great products.
Having a Sprint Review where you show your product to stakeholders and involve them in what to work on next, won’t guarantee you’re building something that delivers value to users and the business.
Also, finding out something isn’t valuable only after building it is too late. You should try to increase your chances of success by learning before building or building as little as necessary to maximize learning.
So how does Scrum help to make sure you are building the right thing? The following paragraph in the Scrum Guide makes clear what powers the delivery of value:
Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment. — Scrum Guide November 2017 version
In other words, Product Management is the motor that drives the delivery of value. Scrum can make transparent how effective your Product Management techniques are. Inspection and adaptation give you the opportunity to polish and improve these techniques further. This is only possible if there is a person who supplies this Product Management expertise to begin with.
Scrum’s Product Management expert is called the Product Owner. An excellent Product Owner is a strong Product Manager. You can’t be a good Product Owner without understanding Product Management. Without following Product Management practices, Scrum can’t meet its promise of delivering products of the highest possible value.
What Product Managers and Product Owners should have in common:
- Both should be Product Management experts.
What are the differences?
- Product Manager is the agnostic term for someone who maximizes value to customers and the business using their knowledge of Product Management.
- Product Owner is what Scrum calls the Product Manager, and the Product Owner has way more responsibility than the average Product Manager that doesn’t work with Scrum.
Why does the Product Owner have more responsibility than the average Product Manager? Product Management typically recognizes the following seniority levels:
- Chief Product Officer — Responsible for more than one product.
- VP of Product — Responsible for a single product.
- Senior Product Manager — Responsible for one or more teams working on a single product. Possibly coaching other Product Managers.
- Product Manager — Responsible for a single team working on a single product, often under the guidance of a Senior Product Manager.
In Scrum, there is only a single Product Owner for a whole Product. Scrum does not permit spreading this responsibility over multiple people. This means that the Scrum Product Owner role is equal to the Chief Product Officer or VP of Product in the world of Product Management. Senior Product Managers or Product Managers are not Product Owners unless they have no management layer above them.
In Scrum, the Product Owner is supposed to be active across the whole Product Management spectrum:
- Delivery (In Scrum: everything that happens during the Sprint to support the Development Team in delivering value).
Scrum leans heavily on self-organizing teams, to make the Product Owner role work. Self-organizing teams make a Product Owner available for activities other than delivery. If a Product Owner needs to be involved too much in execution, then (s)he will have insufficient time to cover other facets of Product Management. It will be impossible to pay sufficient attention to higher-level activities such as developing the Product Vision, Strategy, and Roadmap.
This is a common problem because many companies work with Scrum in such a way that it’s the job of the Product Owner to babysit Scrum Teams to guarantee features are delivered on time. This is the wrong approach because with Scrum it is the job of the Scrum Master to build a self-organizing team that needs the Product Owner as little as possible to deliver value during the Sprint. Unfortunately, this often fails, and as a result, the product suffers because the Product Owner is just busy running the Scrum Teams instead of looking at the bigger picture of the product.
To circumvent this issue, companies introduce a new role to work around the actual problem: the Product Manager. The Product Owner makes sure the team keeps on delivering and works efficiently inside the Sprint bubble. Everything outside of the Sprint is covered by the Product Manager. The Product Manager is usually external facing to customers and stakeholders, the Product Owner is internal facing to the Scrum Team.
The Product Manager — Product Owner dichotomy is a solution to a problem, but in my experience, it introduces its own host of issues that make the cure worse than the disease:
- Waste and loss of information due to hand-overs from Product Manager to Product Owner, leading to solutions that do not solve the intended problem of the customer.
- Lack of customer and business understanding of Product Owner may lead to wrong ad-hoc decisions during the Sprint, leading to unnecessary rework or features failing to deliver value.
- Product Owners may become disengaged. The Product Owner role is effectively reduced to that of a ticket master, baby sitter, and scribe. This definitely not how Scrum intends the Product Owner role to be.
- There often is a disagreement between Product Managers and Product Owners on the direction of the product, leading to friction and Sprint decisions not aligning with the big picture.
When Scrum Teams require a lot of attention during the Sprint from the Product Owner, then this is the problem you should be fixing. Based on my experience, the Product Owner should only spend around 20% of their time with their Scrum Team. Otherwise, the role won’t scale when you have to handle multiple Scrum Teams.
It is the purpose of Scrum to help with delivering products of the highest possible value. It’s the job of the Product Owner to make sure everybody has a good understanding of how to achieve this without constantly having to rely on the Product Owner being present.
As a Product Owner, I encourage the Scrum Teams I work with to make decisions during the Sprint without involving me. If I do get a question, I often ask follow-up questions to get them to the right answer.
If they are not able to provide an answer, then I spend some more time to explain the context to provide knowledge that is possibly missing. Then after explaining some more, I keep asking questions till they come to the right conclusion (or a better one than mine!). Following this approach increases the chances they will make the right decision without involving me the next time.
So now to get back to the original question: is a Scrum Team better off with a Product Manager or Product Owner?
You should employ someone with the right expertise: an expert in Product Management. It does not matter if their previous job title was Product Owner or Product Manager, it matters what areas of the Product Management they are experienced with. Having experience with Scrum is less important, especially because there is a Scrum Master’ available to coach them in the realm of Scrum if necessary.
However, with Scrum being so popular, it is increasingly rare to find a great Product Manager who does not have experience with Scrum. Seeing how much Scrum is growing, it is a matter of time until Product Managers who lack Scrum experience will start raising eyebrows during interviews.
When someone says they are a Product Manager or Product Owner, you can’t conclude just based on their title how much Product Management experience they have. Some Product Managers have more responsibilities than Product Owners, but it can also be the other way around: Product Owners that have more responsibility than a Product Manager.
This explains why there is so much confusion surrounding the two roles. I expect this confusion to not be resolved, no matter how many articles will be written. Product Manager and Product Owner job titles are deceiving. How the role is fulfilled differs from company to company.
As with any hire you make: a title never tells the full story, the actual experience on the job does. Only by asking the right questions can you discover whether you trust the person is capable of doing the job you want to hire them for. Is this Product Owner just a ticket pusher that never talks to customers? Or is it someone who understands the craft of Product Management and spends most of the time talking to customers, understanding the business, running experiments, and researching the market?
Unfortunately, people are often suckers for titles, as it is an easy way to draw conclusions about someone without having to spend a lot of cognitive effort. Look past the title and focus on what the person who you’re talking with has experience with. Especially when it comes to Product Management job titles like Product Manager and Product Owner.
Looking beyond the job title is much harder, but it will provide far more signal and information than a bunch of letters can.
Special thanks to Olaf Molenveld for suggesting to write this article.