Just like how the Development Team role and Scrum Master role that can be easily misunderstood, the Product Owner is also easily misunderstood by organisation who are using Scrum. Over and over again I see people who are assigned as Product Owner are not really a Product Owner, either they do not have the attribute of a Product Owner or they aren't playing the Product Owner role.
Many Product Owners currently do not really have any ownership with the product they are managing. The label has changed but the behaviour hasn't. They aren't empowered to make decision for the product and they can't say NO to the stakeholders. Basically they're just a proxy for the real Product Owner. Or they're just focusing on requirements engineering, writing perfect requirements. They are still expected to write perfect User Stories. The way requirements are written has changed, but the perspective towards requirements hasn't.
Many people thought that Product Owner is just another name for a Business Analyst. The Scrum Guides clearly states that the main responsibility of the Product Owner is maximizing the value of the product and the work of the Development Team NOT requirements engineering or business analysis. This misconception is becoming more acute in our industry because currently there are many Scrum organisations who are educating the Product Owners how to be a User Story expert. These people are not doing any good to an already broken industry.
Through this article I will elaborate on the attributes that Product Owners should have, filling in the missing pieces that aren't in the Scrum Guide.
1. Product Owner is an entrepreneur
Great Product Owners have the entrepreneur mindset. There is no single theory to be an entrepreneur, what may not work for one Product Owner may work for other Product Owner. Many great entrepreneurs do not even attend Business School. As an entrepreneur, Product Owners do not spend a lot of time doing requirements engineering and speculating what may change in the future, great Product Owners do not waste time on scenario planning. This is what makes Product Owners different to Business Analysts.
As an entrepreneur, Product Owners is a risk taker. They may invest in areas that their competitors aren't even looking. With Scrum, Product Owners create small risks along the way and turn the output into learning opportunities. They exploit failures generated every Sprint and use it as an opportunity to innovate. From failures to innovation. They see a Sprint as a container for making failures in a controlled manner rather than a mini-deadline for the Development Team. Only by treating the Sprint like this the Product Owner are able to maximize the value of the product and the work of the Development Team.
2. Product Owner is an innovator
Human beings are happiest when they're exercising their ingenuity.
— Mihaly Csikszentmihaly
It is our nature as human beings to improve things.
— Jenan Kazim
Innovative Product Owners are able to see where game-changing ideas come from. Product Owners are visionaries who hold the vision for the product. They believe in their product. They have the ability of looking at the world that throw new opportunities into great products that customers love using. They somehow can see the tiny dot in the future that others can not. Think of someone like Elon Musk or Steve Jobs if you need a role model of a Product Owner.
As an innovator, Product Owners think the unthinkable. They don't believe that the future is the extrapolation of today. They believe what may work yesterday may not work soon in the future. Product Owners keep creating the future, they bring the future closer and challenge the current status-quo and never settle for less. They unconsciously develop a mentality of continuous renewal and impart that to the whole organisation.
Having work with many visionary Product Owners, I have to admit that sometimes it is a pain working with visionary Product Owners. That is why visionary Product Owners need many Unicorns inside their organisation. Product Owners should rethink about hiring cheap developers if he wants his vision to become a reality.
3. Product Owner is a systems thinker
By "building to think" instead of "thinking about what to build", an organisation can dramatically accelerate its pace of innovation.
- Tim Brown (IDEO)
As a systems thinker, Product Owners are able to see the whole system that create the problem. In a complex system, software development team is only the smallest factor that contributes to software development project. Product Owners are not only focused with the software development team.
Product Owners are constantly on the lookout for emerging discontinuities, small things that are already changing but ignored by their competitors. Product Owners are going to work with the end-users so that the product can be valuable for them. They have the empathy towards their customer and able to read customer's emotional state. From their customer emotional state, they are able to design a product that their customer could not ever imagine and make their customer a fanboy of their product after their customer once experienced it.
As a systems thinker, Product Owners are able to see the current organisation and the world around it as an asset that can be combined to create great product and generate value for their customers. Great Product Owners are able to maximize the core competencies and strategic assets of the organisation to invent strategies that is more efficient to meet customer's needs. Product Owners who are systems thinker are able to utilize the skills and assets in the organisation as a game-changer in the industry. Great Product Owners challenge the beliefs that everyone else takes for granted.
4. Product Owner is a Mini CEO
Product Owner treats her product like her own company therefore she is a Mini-CEO. As a Mini-CEO, Product Owner is empowered to do the right thing by the higher level management. Product Owners must also be a great negotiator and do what is best for the product. As a Mini-CEO, Product Owner must know how to say 'NO' otherwise every 'YES' that she is saying does not have any meaning. The whole organisation must also respect every 'NO' that Product Owner says. For the Product Owner to succeed, the entire organization must respect his or her decisions. They don't only work just as a proxy who must always get approval for every single decision they make. Product Owners who are only going to work as a proxy are not going to be effective in doing their job.
Product Owners are not like project managers in traditional sense who are only focused about meeting time and meeting budget as success criteria for the product they are managing because there are many products that are delivered on time and on budget but do not create any value for the customer. Product Owners concentrates mostly on maximizing the value of the product.
Many people asked me how can software drive value to a company that is not in technology business? Any business that operates in 21st century must maximize the usage of software if they still want to sustain success. To sustain success companies, even those who are not in technology business, must have the humility and courage to leave the old things that are no longer relevant in 21st century. Many brick and mortar business went bankrupt in 21st because the rise of software. Software is eating the world.
5. Product Owner is a manager
In Scrum, everyone is a manager of their own area of accountability. Product Owner does not manage people or the Development Team like managers in traditional sense because the Development Team manages themselves. Product Owners manage strategy for the product so that it will drive value for the company he belongs. Product Owners manage the product by managing releases, product road map and product version. All of this can be seen by how they manage the Product Backlog.
People should think things out fresh and not just accept conventional terms and the conventional way of doing things.
— R. Buckminster Fuller
Product Owner is not a requirements engineer and not a User Stories expert as many people have assumed until today. Product Owner is not another name for Business Analyst. In fact labeling the current Business Analyst with Product Owner is not going to make things better. Managing the Product Backlog does not mean that the Product Owner write the Product Backlog Item. Product Owner who are only focused on requirements engineering might as well work inside the Development Team. Development Team should not push back imperfect User Stories to Product Owner as it is Development Team responsibility to serve the Product Owner. Development Team should see ambiguity as an opportunity to stimulate their creative mind.
Product Owner is empowered to do what is right for the product. Product Owner is not a proxy who translates what the business want into technical requirements, in fact Product Owner is from the business. Product Owner have full accountability with the product they are managing. Value of the product is the only measurement that the Product Owner should care about NOT on-time, on-scope and on-budget.
Hopefully this article clears up the confusion on the role of Product Owner. But if you still find the term and the role of Product Owner is difficult to understand, please feel free to ping me.