In Scrum, we have a product owner. It is an accountability, it’s no longer a role according to the 2020 Scrum guide.
There are different categories of product owner:
scribe
proxy
business representative
sponsor
CEO of the product.
The Scribe Product Owner
A scribe is like a really poor waiter in a restaurant. They take your order even though they know that you should not order what you are ordering.It’s probably the worst thing on the menu, and the chef does a terrible job of that dish.
A scribe just takes your order regardless, of whether it’s a good or a bad idea, they don’t add any value.
The Proxy Product Owner
A proxy is maybe someone who is like a waiter who’s taking your order but realizes that you’re ordering the wrong thing or it’s not a really good thing and in a very polite and diplomatic way, they might say, well, sir you probably should look at this dish, we’re recommending this as a special.
They add more value however they still don’t have any power. It’s usual for a proxy-type product owner to be a person who might be a very good person. I’m sure they’re a very good person, but they don’t have any power. The person with the power just couldn’t be bothered doing product owner roles so they’ll delegate it to somebody else.
A lot of product owners are actually proxy product owners quite sadly.
The Business Representative Product Owner
Then there’s business representative which is slightly better than proxy. Some organizations, believe it or not, segregate IT from the business or one department from another department.
In the case of an IT situation, the product owner who was a proxy working in IT because they couldn’t get a representative from the business, maybe now they’ve been seconded into the business. Even better, someone from the business has decided or has been asked to be a product owner and that person is in at least the right network to have more influence, but still doesn’t have any budget.
The Sponsor Product Owner
Then there’s the sponsor, which is the person who actually has the budget for the product, including:
the total cost for the product;
the whole life cycle;
running the product or the service; and
improving the product or the service.
The CEO of the Product
A person who can take risks, who can basically decide whatever they want to do in relation to the product, but they work in a very data-informed way.
What experience tells me
The best product owners I’ve ever worked with, I only had access to them maybe 10 minutes a day, sometimes only every second day, and the same for the developers and the team.
The reason we were so effective is because when we asked the product owner questions, she knew the answers. She didn’t have to:
“Oh, I’ll check with this person”.
“Oh, I’ll check with that person.”
“Oh, I need to align with these, align with those”.
They just gave an answer.
Sometimes they did still need to do alignment offline, but they manage that themselves because the biggest job of a product owner is to connect with stakeholders and manage their expectations in relation to uncertainty and basically say no to a lot of things and say, you might get these things.
“the biggest job of a product owner is to connect with stakeholders and manage their expectations”
Managing uncertainty & Creating the Vision
Managing the uncertainty about maybe when those things might be delivered. That’s the biggest job really for the product owner.
What’s our vision? Co-creating that vision, but maybe creating it and, and then making sure everyone’s inspired. I like to co-create, but you don’t have to as a product owner.
The product owner will continually update that vision, that direction of travel, and that goal in consultation with the stakeholders, the customers, and the end-users.
They’ll meet the customers and the end users a lot to inform their decision-making. They’ll walk the Gemba of value consumption. They’ll really understand what’s going on. They might even be mature enough to just witness what customers are doing without asking them leading questions such as:
“what do you think of this”
“what do you think of that”
Maybe just seeing what the customer plays with.
John Carter, when he spoke to me about his work at Bose, mentioned that they bought a music store in the city where they operated. And they just observed what people were buying, what they were picking up.
They didn’t say, here’s a shiny new product. Here’s something we’ve been innovating on and we’re really excited about it. They just wanted to see if anybody would notice it.
That’s how they innovated. They listened.
I had the pleasure of interviewing John Carter on the Xagility™ podcast — the episode goes into a lot of depth on innovation and how we market innovation. Listen to the episode here.
Indi Young would say, you deeply listen to your customers.
I had the pleasure of interviewing Indi Young on the Xagility™ podcast — the episode discusses why we should not look at a problem through the aperture of a solution. Listen to the episode here.
Most product owners are scribes or proxies
Most product owners in the world are either scribes or proxies, at best they’re representatives of the business if you like.
Most people who order my classes are in that situation, and when they come to me for product owner training, they come with a couple of myths.
Myth: Product management is taught in product ownership classes
One of them is that in the product owner class we teach about product management.
We don’t.
We do show some practices that are practiced in product management, but we don’t delude people into thinking we’re teaching them about product management. We just say, here’s a window, here’s a door. You need to find out more about this.
A coping strategy is if you are a proxy or a scribe or even a business representative, become a developer on the team.
Only one product owner in Scrum for the entire product
We only have one product owner in scrum for the entire product.
What is a product?
The product typically being a vehicle through which we deliver value but’s essentially what an external customer would buy with their:
money;
time; or
data.
Somebody consumes the product or service and somebody produces it.
So if you have a product, a real product, and you have multiple teams working on that product, we just have one product owner.
How team product owners create separate backlogs
What I see typically is we’ve got people acting as team product owners, and when you’re a team product owner, what tends to happen is you tend to look after your part of the backlog. Even if it’s all a big list, actually you just look at one filter of it. So implicitly you’ve got a separate backlog.
So I might not even see what’s more valuable on Vanesa’s backlog, and everybody would know that what Vanesa’s working on is much more valuable. But because I’ve just my own little filter of the world, being a team product owner, I just do what my team does instead of doing what’s most valuable for the company and learning how to deliver what’s most valuable for the company.
So team product owners, product owners growing like flowers. It’s a typical anti pattern in companies.
In Scrum, there’s only one product owner.
The product owner owns the product.
If I was just to do a very quick comparison with product management here, I’m going to do another post on this to go into more detail.
The comparison between product owners and product managers/leaders
A real product owner is very similar to a product leader in product management.
It’s fine to have a product manager per team because a product manager doesn’t necessarily own the product, although context is king.
If you’ve got one team, it might be the same person, but in a multi-team context, which is a situation for most products, you can have a product manager working per team and the real product owner looking after the product is the equivalent of a product leader in product management.
But I will talk more about that in another post because product managers/product leaders do much more than what we do in product ownership.
Thank you.