Phillip Starke
A three leveled approach to being a product owner
The product owner role in Scrum – if done correctly – is extremely powerful. It is a single person that “is accountable for maximizing the value of the product resulting from the work of the Scrum Team”. This single person accountability gives the role extreme leverage in determining the success of product development efforts. Unfortunately, many cannot or are not allowed to fulfill the potential of the product owner (PO) role.
Some people don’t know the full extent of the PO’s responsibilities. Some are overwhelmed by the sheer amount of things to do. Some are prohibited from taking on the full role by the company culture or organizational structure. There are other causes but for most it’s probably a mix of these three that explain why they aren’t fulfilling the PO role.
But there exists a path of growth to becoming more proficient as a product owner if you take it step by step. In my mind, there are three levels of being a PO. And all of us should strive to ascend up these levels. Today, I want to share this mental model. It is what I always use when coming into a new team and I think it can help you also create a path of growth in PO proficiency.
Before we get going, let me share a quick reminder of the PO activities.
The Backlog is a newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Managers or Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox.
A Product Owner should be a Product Manager
Some may disagree, but in my mind the Product Owner shouldn’t be any different from the product manager. The goal for both is to “Build products that our customers love that also work for our business” (from Inspired by Marty Cagan). This entails a lot of activities.
I like to sort these into three categories shown in the picture below: defining the product, understanding users, and stakeholder management.
Defining the product are the obvious activities like writing epics and user stories, defining a vision, strategy, and roadmap, making day to day decisions, prioritizing issues, or determining the product backlog.
Understanding users is everything needed to make informed product decisions. Examples are conducting interviews and usability tests, doing market research, analyzing usage data, running assumption tests, or explicitly asking for feedback in surveys.
Stakeholder management are all activities that ensure the team’s work is aligned with the rest of the company. This means dealing with complaints feedback, resolving conflicts of priorities between teams, communicating progress, or managing dependencies to other teams and products.
This list is by no means exhaustive but it should include the most important things.
The three levels of being a product owner
Considering all of these activities, it’s not surprising that the sheer number overwhelms people. Especially if you want to do everything at once. You can’t. You have to go step by step.
That’s why I use a mental model with three levels of thinking about the role. You can think of them as a path of growth in your PO career. Whenever I start working with a team I do the same, starting with the lowest level and working myself upwards. The levels are shown in the picture below:
- Backlog Administrator
- Base Product Owner
- Expert Product Owner
Level 1 – The backlog administrator
Unfortunately, many POs don’t get further than being a backlog administrator for a delivery team. They are doing things to make sure Scrum looks right.
A backlog administrator gathers requirements and wishes from various people within the company, makes sure internal dependencies are taken care of, creates a backlog, and is there for the developers to answer questions about the stories.
Due to various factors – chiefly company culture & lack of trust – this person is not empowered to actually make important product decisions. She is simply making sure the team builds what others think makes sense. It is a reactive role that certainly can’t claim that it is owning the product.
You can have success on this level. Nevertheless, all product owners should strive to at least reach the second level.
Level 2 – The base product owner
Everyone can and should end up being a base product owner. While level 3 may not be accessible to everyone, e.g. because of company culture or because of dependencies to others, I believe almost everyone can arrive at level 2.
This is where you can start actually talking about a product owner in the literal sense of the word. The base product owner is starting to take the reins and actually making meaningful product decisions.
This starts with things like gathering feedback from users and customers through various means, conducting market research, and regularly running interviews. The base product owner uses all that input to come up with his own plan for the product development efforts in the form of a roadmap. He is sometimes allowed to own the strategy but rarely the product vision itself.
Nevertheless, it’s a big step up from the backlog administrator. I strongly believe that base product owner is the level every PO should eventually get to. It may take some convincing but most companies and cultures will in the end allow it.
A note on interviews. I believe that there is nothing more insightful than regularly talking to your users and customers. If there is one thing to aim for from level 2, it‘s establishing a regular cadence of interviews. If you are already regularly talking to your users ist only a small step to start testing features and assumptions, activities within the 3rd level.
Level 3 – The expert product owner
The expert product owner has full control over the product shaping the vision, strategy, and the short term focus areas.
This is also someone that is aware of the risk inherent to product development. She does everything she can to minimize these risks. As much as possible, she pushes for small experiments to test the assumptions underlying proposed solutions. Usability testing and various other techniques are deployed to increase the chances of the product being successful.
Data plays an increasingly larger role in decision making, whereas gut feeling and guessing are diminished.
The expert product owner is part of an empowered product team and has evolved from a reactive backlog administrator, through a base product owner that is starting to make meaningful decisions, all the way to being able to holistically shape the product development efforts.
Applying the three levels of product ownership
When I coach POs I don‘t expect anyone to know everything at once. Noone becomes an expert product owner overnight. Many are also dependent on others to unlock the activities in level 3.
Think about making decisions based on usage data. You can’t just start doing this. You likely need to build some sort of logging and reporting infrastructure before being able to actually use the data in decision making. Or think about interviews in the B2B context. You likely need support and trust from the sales teams in order to start talking to customers and users. It takes time to resolve these dependencies.
Nevertheless, I do expect that POs attempt to climb these levels, even if it only is one tiny step at a time.
This is how I approach working with new teams. I go step by step. I start at the bottom, make sure we are good at running Scrum, have well written stories, and have good communication channels towards our stakeholders.
As soon as I can – whenever we have established a more or less smooth Scrum process after two to three sprints – I try to schedule user interviews.
Shortly after – roughly four to six sprints in – I try to move from being only reactive to becoming more active by explicitly seeking out feedback, defining our own short term plan and mid-term roadmap.
Finally, I encourage the team to start testing our ideas and assumptions in various ways.
It’s a team effort
And this word „team“ is imperative here. Most of the activities are team efforts in the end. Usability testing is something UX designers know how to do, architectural discussions are led by the engineers, you may have a BI team that can help with usage data. The PO doesn‘t have to do everything himself. He should, however, be the person that pushes for the activities to happen.
As such the progression of the PO from backlog administrator to expert product owner goes hand in hand with the progression of the entire team from delivery team through feature team all the way to fully empowered product team.
Taking it one step at a time and working yourself up the three levels of product ownership therefore means you are not only working to fulfill the potential of the PO role. You are also working to fulfill the potential of the entire team.