For years I have been using this picture to describe the Product Owner role. For years I have been saying:
“The title Product Owner is really an alias. Nobody should have Product Owner on their business cards. Product Owner is a Scrum defined role which is usually filled by a Product Manager or Business Analyst, sometimes it is filled by a Domain Expert (also known as a Subject Matter Expert, SME) and sometimes by someone else.”
In telling us about the Product Owner Scrum tells us what one of these people will be doing within the Scrum setting. Scrum doesn’t tell us how the Product Owner knows what they need to know to make those decisions – that comes by virtue of the fact that underneath they are really a Product Manager, BA or expert in the field.
In the early descriptions of Scrum there was a tangible feel that the Product Owner really had the authority to make decisions – they were the OWNER. I still hope that is true but more often than not these days the person playing Product Owner is more likely to be a proxy for one or more real customers.
I go on to say:
“In a software company, like Microsoft or Adobe, Product Managers normally fill the role of Product Owner. The defining feature of the Product Manager role is that their customers are not in the building. The first task facing a new Product Manager is to work out who their customers are – or should be – and then get out to meet them. By definition customers are external.”
“Conversely in a corporate setting, like HSBC, Lufthansa, Proctor and Gamble, a Product Owner is probably a Business Analyst. There job is to analyse some aspect of the business and make it better. By definition their customers are in the building.”
With me so far?
Next I point out that having set up this nice model these roles are increasingly confused because software product companies increasingly sell their software as a service. And corporate customer interact with their customers online, which means customer contact is now through the computer.
Consider the airline industry: twenty years ago the only people who interacted with airline systems from United, BA, Lufthansa, etc. were airline employees. If you wanted to book a flight you went to a travel agent and a nice lady used a green screen to tell you what was available.
Today, whether you book with Lufthansa, SouthWest or Norwegian may well come down to which has the best online booking system.
Business Analyst need to be able to think like Product Managers and Product Managers need to be able to think like Business Analysts.
I regularly see online posts proclaiming “Product Managers are not Product Owners” or “Business Analysts are not Product Owners.” I’ve joined in with this, my alias argument says “they might be but there is so much more to those roles.”
It makes me sad to see the Product Manager role reduced to a Product Owner: the Product Owner role as defined by Scrum is a mere shadow of what a good Product Manager should be.
But the world has moved on, things have changed.
The world has decided that Product Owner is the role, the person who deals with the demand side, the person decides what is needed and what is to be built.
I think its time to change my model. The collision between the world of Business Analysts and Product Managers is now complete. The result is an even bigger mess and a new role has appeared: “Digital Business Analyst” – the illegitimate love child of Business Analysis and Product Management.
The Product Owner is now a superset of Product Manager and Business Analyst.
Product Owners today may well need the skills of business analysis. They are even more likely to need the skills of Product Management. And they are frequently expected to know about the domain.
Today’s Product Owner may well have a Subject Matter Expert background, in which case they quickly need to learn about Product Ownership, Product Management and Business Analysis.
Or they may have a Business Analysis background and need to absorb Product Management skills. Conversely, Product Owners may come from a Product Management background and may quickly need to learn some Business Analysis. In either case they will learn about the domain but they may want to bring in a Subject Matter Expert too.
To make things harder, exactly which skills they need, and which skills are most important is going to vary from team to team and role to role.
Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development