What do a peanut, a Panama hat, and a starfish have in common?
Stumped?
Well, they’re all misnomers. A word or term that suggests a meaning that is known to be wrong.
A peanut is not a nut, Panama hats come from Ecuador, not Panama and a starfish is not a fish.
Another misnomer is ‘Product Owner’. Does the Product Owner really own the product?
A Product Owner is a role defined by the Scrum Agile methodology. A Product Owner is part of the team working on the development of the product. A Product Owner prioritizes the requirements in the backlog, specifies requirements ready for the next sprint and answers questions from development about the requirements that are being built. The focus is on optimizing development and working with the Development team.
A Product Manager has a much broader role. From the long-term product strategy and roadmap to business cases, getting market insight, proposition development, sales support, product marketing, and firefighting. OK, other people in the business may do some of these activities but nevertheless, someone needs to have a joined-up and balanced view across all the different aspects of a product. Someone needs to be responsible for its success. That’s usually the Product Manager and they’re usually very busy.
So if anyone owns the product within the business it’s the Product Manager. It’s not the person managing the requirements – the Scrum ‘Product Owner’. No wonder people get confused.
Forget about job titles. In reality, we find that many Product Owners do parts of the product management role and many Product Managers work on requirements. In fact, according to our annual survey, 35% of Product Managers also do the Product Owner role.
I always ask Product Managers on our training courses – “If you do the Product Owner role, how much time does it take?” Of course, the answers vary but it seems to average out at just under 2 days a week. That’s 40% of a Product Managers’ time attending meetings with Development and working on requirements.
Nothing wrong with that. The work needs doing. But it gets at a big dilemma many Product Managers face. Should you be the Product Owner for your product? Is it the best use of your time?
Sometimes you don’t have a choice. There is no-one else to do it. But it is another role to take on and means you’ve got less time for everything else.
Our preference is to try and get someone else to do the Product Owner role – someone who takes direction from you. Maybe a Business Analyst or Manager working in Development. They can focus on the detailed requirements and you can focus on the high-level roadmap, commercial aspects and making sure the product is a success.
What’s your view?
Ian Lunn
Director, Product Focus
Join the conversation - 13 replies
Depends on context. With a mature product in market that has paying customers, there’s no other way.
But during new product development, pre product/market fit, I find a team is less likely to deliver an effective solution if the roles are split. One person has to shepherd a vision into an (early) tangible thing.
I agree with product management’s being a broader role. The potential conflict between PM and PO often ends up in practice as an opportunity to scale functional ownership of the product. In my experience, it’s common for POs to continue reporting to development as organizations “scale up”. I’ve seen this setup work well with the right role definitions and leadership support. I think the ever-broadening scope of the PO role in the literature is a direct result of a realization that gaps relative to the traditional definition of the PM position needing to be filled.
Personally I have never been one for splitting the role as I think the Product Manager has the overall vision, and should be the one to share this with development. Anybody else in between can dilute the message. I think it’s only when you truly own the product that you can be the Product Manager – knowing it inside out.
It is difficult to balance the ‘doing’ with the ‘thinking’ but with an effective team around you it can be done.
I agree that a Product Manager spending up to 40% of their time on stepping into the Product Owner role will compromise other important Product aspects. Substituting this role with someone like a BA makes sense. The BA skill set is tuned to understanding business impacts and opportunity, and if the Product Manager provides guidance on requirement priorities the Product Owner role can operate effectively with a BA. The Product Manager will still need to stay close though, set rules (and agree) as to how the BA should perform the role, and be consulted by exception
I agree the roles and the context in which they operate are different. I follow a different approach. With very distinct PO and PM roles, often the responsibility and accountability gets mellowed. While PO(inbound) is in the solution space and PM is in the problem space (outbound), I mandate my PO’s to mandaorily allocate time in outbound activities to have the market perspective so as to define the product requirements in practical context. This also serves as the growth path for the PO’s to move into PM role as they move ahead. But the commercial success and the QCT sign off on developed product is the responsibility of the Product Manager
I actually feel the seperation of PM and PO is easier to achieve when the product in question is of maturity, giving a BA direction on the maintenance of a mature product is much easier than trying to share with them the entire vision that a Product Manager has built up from all the neccessary sources. I feel it would be dificult to seperate these roles in a new product, having spent all that time in preperation and gathering market requirements the PM is in the best position to take on the PO role to begin with.
We have speerated out the Product Marketing role which allows more time for the PO role at my company and due to the nature of our business this works well
I agree that ‘product owner’ is a much more narrowly defined role than ‘product manager’. I suspect that while developing the agile methodology the intention was that the product owner owned what the particular scrum team was producing, i.e. their product.
On the flip side, the term product manager is used over a very broad spectrum of activities. So much so that in the company where I used to do product management, it was split in 3 functions: commercial product manager, operational product manager and technical product manager (I was the latter).
I think this is a very important distinction, in terms of roles although would agree that often the lines are blurred often by necessity. Even with the PO being an extension of the development team I would still have them reporting into Product Management function as prioritization of requirements still needs to be around market needs and hence the interlock with Product and Portfolio Management is absolutely key. I also see the distinction in roles being related to the persona focus too, where if the scale of the offering supports two roles then have the PM being buyer centric and the PO being user centric.
From my experience, in a larger PM team, for larger products/portfolios, you will typically have “specialty” PM roles, and PO is one of them. To continuously reinforce the product vision to engineering and design, and to prioritize the backlog based on market- and business needs, the PO indeed needs to take direction from the senior Product Manager. In short, PO should spend a lot of their time with Engineering, but report up though PM.
What these different roles are and what they are called vary a lot, but here are some synonyms I’ve seen:
1. Inbound Product Manager = Technical Product Manager = Product Owner = Business Analyst (what we’re talking about in this thread)
2. Outbound Product Manager = Product Marketing Manager (works towards the field, i.e. sales, marketing, partners, eco-system)
3. Commercial Product Manager = Strategy Product Manager = Business Owner (usually a senior role, often portfolio-level, responsible for the business aspects)
I’m sure there are different ways you can organize it…
I’d first appreciate different terminology because ‘product’ means different things to different stakeholders. Our project is to create a website for a company who make products. They already have Product Managers and don’t consider the website a ‘product’ at all. As new as they are to these methodologies, its hard to get off the ground when its not clear if we need someone to work with the engineering team and the solutions as well as the problems that the business needs to solve.
I can’t disagree more.
“A Product Owner prioritizes the requirements in the backlog, specifies requirements ready for the next sprint and answers questions from development about the requirements that are being built.”
This is only a tiny piece of what a Product Owner is responsible for, and it can/should be delegated to the team or someone else. From the Scrum Guide -> “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”. Annoyingly vague. But you need some good old strategy to know what to build to maximize the value, i.e. Product Manager.
The state of Scrum is quite dismal. Companies have relegated the role of Product Owner to “requirements manager” which is what you’re referring to here. In a healthy Scrum team, there is no difference between a Product Owner and a Product Manager. I wish Scrum would start using Product Manager instead of Product Owner…but until then the dysfunction of the unnecessary role of requirements manager…eh hem…I mean “Product Owner” will continue.
In 2024, Scrum industry certification bodies assert that a Product Owner is an Agile Product Manager. Like all Product Managers, they’re accountable for the Product. This is due to Scrum’s current evolution that focuses on product management and no longer with ‘agile project management’.
Scaled agile frameworks, like SAFe however, don’t align with this perspective. To solve the scaling problem, SAFe creates a hierarchy between the 5-12 Product Owners (team level) and the Product Manager (value stream level). Similarly, Scrum @ Scale has a Chief Product Owner, and LeSS (Huge) inserts local area Product Owners under the Product Owner (Product Manager) role. Nexus is the only scaled framework that maintains a single Product Owner (Product Manager) role. The result, unfortunately (in immature product organisations), is that the Product Owner becomes a bottleneck for the multiple teams they support.
Now add modern Scrum into traditional project management, and the Product Owner often devolves into a requirements manager, further adding to everyone’s confusion.
As an SPC6, Professional Scrum Trainer, and Certified Transformation Coach, making sense of this mess for clients is, sadly, a full-time job and isn’t easily resolved.
Thank you for sharing your thoughts on the evolving roles of Product Owners and Product Managers within Agile.
You’ve highlighted a significant challenge that many organizations face when scaling Agile methodologies: the blurred lines and varying interpretations of these roles across different frameworks.
It’s true that as Scrum has evolved, the distinction between Product Owner and Product Manager has changed, leading to confusion in implementation. The introduction of hierarchies in scaled frameworks aims to manage complexity but can inadvertently create confusion, especially in organizations that are still maturing their Agile practices.
Your point about the Product Owner devolving into a requirements manager is particularly insightful. This shift can dilute the strategic impact of the role and hinder the agility that Scrum aims to promote.
Navigating this “mess,” as you aptly put it, indeed requires dedicated effort. It sounds like you’re doing valuable work helping clients find clarity and succeed with their implementations. Wishing you continued success in your endeavors.