What is a good Product Owner and am I the right person to fill in this role?
If you have ever struggled with this question, you should probably keep reading.
The advantage of being a trainer and a consultant at the same time is that you get the chance to meet a lot of Product Owners. I hear the stories of Product Owners struggling with their daily challenges. Sometimes these stories are beautiful & inspiring, but mostly they look like an episode of 'House of Cards' (meaning it's ugly and full of politics and tough decision making).
Looking at all these stories you can see an evolutionary pattern appear, describing how a Product Owner grows in his role.
The pattern
Many Scrum minded organisations are trying to create a good implementation of the Product Owner. But where do you start? Who is the right person to fill in the role of the Product Owner? Do they come from marketing, sales or maybe from the IT department? Or maybe it's that perfect project or product manager? All these questions will pop up, once you start implementing Scrum. The answer to this question is not that simple. It is hidden in the evolution pattern, that describes how many organizations have implemented the role of the Product Owner.
The pattern describes the required 'features' of a Product Owner. It's an incremental pattern, where at each step in the evolution the expected benefits of the role grows. It's like a Russian nesting doll that becomes more beautiful and richer the more it grows.
Five levels
The evolution pattern contains 5 levels of Product Owners that I encountered. These levels can be described by a graph that we use in the Professional Product Owner training:
Each of the PO-versions in the graph is an upgrade of its predecessor:
The Scribe
As a first attempt of implementing the Product Owner role, organizations often start with someone who has strong analytic skills. This is often a member of the Scrum Team that was used to writing requirement specs or someone who used to be the 'Business Analyst'. Since this person typically comes from the IT department, it is easy to take the first step towards implementing Scrum and we can get started with the creation of a Product Backlog.
However, a Scribe has limited benefits, since they often need others (marketing, sales, product/project managers, steering committees, etc) to answer difficult questions. This delegated decision making often leads to a disruption of the flow, bottlenecks, large piles of stocked work, and a slow generation of Business Value.
The Proxy
In order to solve the communication problems of a Scribe, organizations update the Product Owner role with a senior analyst that has strong communication skills. This person is like an account manager that is still coming from the IT department. The focus of a Proxy shift from creating Product Backlog items towards creating Product Increments.
The expected benefits of a Proxy are slightly better since they are more connected to the business than the Scribe. Although the delays, waiting time, and hick-ups will decrease, many of those remain.
The Business Representative
A problem that is often heard with the Proxy (and also the Scribe) is that the business (often marketing & sales) is disconnected from the IT department. Once organizations understand that they need to break down the inter-departmental barriers, they send in someone from marketing/sales/product management to fill in the Product Owner role. This upgrade to a business representative is the next step in the evolution. From this moment on the Scrum Team consists of people from all parts of the organization, and not only from the IT department.
The expected benefits increase again since there is a broader collaboration. Now there is direct availability of functional knowledge & stakeholder expectations. Yet, the business representative still has limited autonomy, since marketing\sales\product management department is still the real authority.
The Sponsor
Once a Business Representative has felt the pain of continuously asking the business departments to make decisions, they will probably fight to get some mandate. Once the business departments dare to give control to and trust the Business Representative, the next step in the evolution is made and the Business Representative is upgraded to a Sponsor.
It works better if the person is not only from the business but also has the trust and the mandate to take decisions (on the spot). A mandate is a signal that the role is taken more seriously. The sponsor is often allowed to spend more time as a Product Owner, leading to fewer hick-ups, context\task switching & largely improved flow. The Developers can focus more, and get things done.
The issues of a Sponsor mostly come down to a need for lobbying for a budget. A sponsor still needs to negotiate to free up money from the different business departments. Maybe he can already decide on how to spend the money for his own department, but there are still other departments that need to be convinced.
The Entrepreneur
The last step in the evolution of the Product Owner is to make him fully responsible for functionality and budgets. This makes him a real Entrepreneur, whose job is to create as much Business Value for his customers as possible. They are like a mini-CEO, a real owner over the product.
The Entrepreneur is responsible for all aspects, like marketing, competition, users, legal & finance within the scope of his product. His professional life is dedicated to the well-being of the product.
Unfortunately, this kind of Product Owner is still a rare species, since organizations are often not ready to delegate this kind of control.
If you would like to use the personas described in a workshop, you can download them here.