Great artile! For people wondering what's the difference between PO and PM, the best explanation I've ever heard goes like this: "PM is a profession with a specific skill set; PO is a role."
TLDR: If you're PO, make yourself a favour and learn how to become a good PM.
By the way, the term "owner" lends itself to a very bad interpretation IMHO. It's way too common for POs in large orgs to become gatekeepers between the team and the business which never ends up well.
You’re raising some very good points, and I agree there’s an anti-pattern at play with the PM/PO layers.
But how do you get from A to B in situations where the right people aren’t in place and things are in flux? Especially when domain expertise is too valuable to simply replace with a ‘Product Management Product Manager,’ who might move on to a different product in a couple of years.
For instance, let’s say we’re building an entirely new version of an established application for law firms, and the Product Manager is a trained lawyer with deep domain knowledge but limited understanding of what’s technically possible. Furthermore let’s say a development team has just been hired and they’re completely new to this domain.
Couldn’t an experienced Product Owner bridge that gap initially (and possibly step away once their job is done)?
Or even, hear me out, rather than seeing it as a Batman and Robin situation (Batman is the boss) we could approach it more like Kirk and Spock, a complementary pair that is more than the some of its parts.
You've got to make it work with the cards you're dealt, not fantasize about the deck you would like to have to win.
The key thing is that you're aware of the different choices with their pro's and con's, and you're consciously choosing this (temporary) solution. Many companies don't even know the other options or don't even seriously consider them.
Would be good if you differentiated between the terms Product Manager and Product Owner. I've worked at orgs where they are the same role. In this article you clearly speak of them as different roles, but it's not clear what each would do for a product. It must be made VERY clear there is only ONE Product Owner that makes decisions based on priorities. So, what does a Product Manager do?
And, the phrase "Usually, a Product Owner should be able to handle more than one team" needs to be struck from the article. There is NO correlation between PO and the # of teams. None. Product Owners own products, not teams (as you stated later). Just stating this implies there's some magical number of teams where you then decide to add another Product Owner (to the same product) and that's just wrong.
I clearly speak of them of different roles, because that's NOT how it should be. It's an anti-pattern.
There rarely is one product owner per product, I know the theory.
There is a relationship between the PO and the number of teams they work with. I've been a PO, and worked with companies all over the world. Very often you see PO's assigned to teams, very rarely do you see them assigned to products. That's the reality.
So yes, there is a correlation in the real world. In the theoretical world of Scrum it's perfectly one PO per Product.
I agree. But more often than not the real-world has implemented Scrum wrong. I too have seen a PO per team...and it's the first thing I change. Orgs need help determining what their products even are...then start over and assign POs per product. If it's determined that there are "too many" teams required to support that product, then we step back and take another look at the product. Is it really 2 or 3 products? It's the last thing I want to do, because the more products the more complexity you introduce. I've found that an org has multiple POs per product (typically a PO per team) I simply ask "what do each of you do for 40-60 hours/week?" you find that much of what they do has nothing to do with the product, or they're duplicating effort, or they're doing something that's a complete waste of time because they have the time.
Great artile! For people wondering what's the difference between PO and PM, the best explanation I've ever heard goes like this: "PM is a profession with a specific skill set; PO is a role."
TLDR: If you're PO, make yourself a favour and learn how to become a good PM.
By the way, the term "owner" lends itself to a very bad interpretation IMHO. It's way too common for POs in large orgs to become gatekeepers between the team and the business which never ends up well.
Here's a good article on this:
https://medium.com/the-value-maximizers/the-gatekeeper-a-misunderstood-product-owner-stance-6e7cc620eb21
You’re raising some very good points, and I agree there’s an anti-pattern at play with the PM/PO layers.
But how do you get from A to B in situations where the right people aren’t in place and things are in flux? Especially when domain expertise is too valuable to simply replace with a ‘Product Management Product Manager,’ who might move on to a different product in a couple of years.
For instance, let’s say we’re building an entirely new version of an established application for law firms, and the Product Manager is a trained lawyer with deep domain knowledge but limited understanding of what’s technically possible. Furthermore let’s say a development team has just been hired and they’re completely new to this domain.
Couldn’t an experienced Product Owner bridge that gap initially (and possibly step away once their job is done)?
Or even, hear me out, rather than seeing it as a Batman and Robin situation (Batman is the boss) we could approach it more like Kirk and Spock, a complementary pair that is more than the some of its parts.
You've got to make it work with the cards you're dealt, not fantasize about the deck you would like to have to win.
The key thing is that you're aware of the different choices with their pro's and con's, and you're consciously choosing this (temporary) solution. Many companies don't even know the other options or don't even seriously consider them.
Would be good if you differentiated between the terms Product Manager and Product Owner. I've worked at orgs where they are the same role. In this article you clearly speak of them as different roles, but it's not clear what each would do for a product. It must be made VERY clear there is only ONE Product Owner that makes decisions based on priorities. So, what does a Product Manager do?
And, the phrase "Usually, a Product Owner should be able to handle more than one team" needs to be struck from the article. There is NO correlation between PO and the # of teams. None. Product Owners own products, not teams (as you stated later). Just stating this implies there's some magical number of teams where you then decide to add another Product Owner (to the same product) and that's just wrong.
I clearly speak of them of different roles, because that's NOT how it should be. It's an anti-pattern.
There rarely is one product owner per product, I know the theory.
There is a relationship between the PO and the number of teams they work with. I've been a PO, and worked with companies all over the world. Very often you see PO's assigned to teams, very rarely do you see them assigned to products. That's the reality.
So yes, there is a correlation in the real world. In the theoretical world of Scrum it's perfectly one PO per Product.
I agree. But more often than not the real-world has implemented Scrum wrong. I too have seen a PO per team...and it's the first thing I change. Orgs need help determining what their products even are...then start over and assign POs per product. If it's determined that there are "too many" teams required to support that product, then we step back and take another look at the product. Is it really 2 or 3 products? It's the last thing I want to do, because the more products the more complexity you introduce. I've found that an org has multiple POs per product (typically a PO per team) I simply ask "what do each of you do for 40-60 hours/week?" you find that much of what they do has nothing to do with the product, or they're duplicating effort, or they're doing something that's a complete waste of time because they have the time.