I see so much confusion around the role of Product Owner. A lot of the reason is that Scrum does not really specify anything except how a group of people will work together to achieve a purpose. All the roles are poorly defined. This was to provide maximum flexibility to allow Scrum to be applied to any kind of work. But it has led to a lot of confusion.
We can tease out what a Product Owner is by looking at the responsibilities of a Product Owner and compare them to other more well-defined roles.
Essentially, a Product Owner is responsible for the vision, goals, or direction of the team and the prioritizing of the work to achieve the vision, goals, or direction while maximizing value.
What does this look like in real life? Because of the Product Owner level of responsibility, a Product Owner looks most like a Product Manager. Which will not help you figure out what a Product Owner does if you do not know what a Product Manager does! So let’s consider some scenarios.
Assume you have an idea for a product. This is something you are passionate about, so much so that you decide to create that product and get it to market. You do not know how to actually create the product, so you find a few people to come and work with you on the product. You all get together in your garage every day to work on the product.
You start by sharing your vision with the team. This is the problem you have seen, this is the product you envision, this is how the product will change the world. The team gets really excited. You have long conversations together about the product, how it might work, what it looks like.
You go off and do market research. What has already been done? What do people like about the other products, and what do they dislike? Meanwhile the team starts researching ideas for how to create this thing. You are in the garage together all day, talking with each other and sharing what you know. You tell the team what you are discovering about the product, the need, and the market. The team shares with you what they are finding out about potential solutions and what it will take technically to create this product.
Together you and the team come up with a list of things to work on. Some of the things are little tests of pieces of technology to see if they will do what is needed at a price that makes sense for your product. Some of the things are features you want to start showing to focus groups. The team gives you estimates of how much effort it will take to complete each work item. You take that information and what you know about the importance of each item and suggest to the team which items to work on first. They argue with you about a couple of them, but in the end, you all agree on the first work items that the team will implement.
Since you are in the garage with the team, they bring things for you to look at every day. This turned out really well, but this idea was a big mistake. What do you think of this design? You and the team talk all the time about what is working and what is not. You make adjustments to the list of work items based on what you are learning.
At some point, you have enough to share with some potential buyers of your product. You get feedback on what they like and what could be improved. You take that information back to the team and have great discussions about what you learned and how it will impact the design, implementation, or priorities of the product.
You are a Product Owner interacting with your team. It is your money funding the product, so you own the product vision, direction, and priorities. But you are always working with the team to shape that vision, direction, and priorities because they are the ones who know how to make your vision real.
Let’s take this a step further. You don’t have enough money to go to market, so you find some people to invest in your product. Now you have some additional responsibilities.
Most investors will not just give you money and walk away. You have frequent meetings with the investors, sharing with them what you are discovering about the market and what the team is learning about how to build the product. The investors talk with you about budget and what they see are important features of the product. While you are still responsible for the vision and the ultimate success of the product, you have to also take your investors concerns into account.
The important thing is YOU ARE STILL IN CHARGE! You are not a spokesperson for the investors, doing whatever they tell you to do, and passing that on to the team. But just as you had to modify your vision as you learned about implementation from the team, you also have to modify you vision to meet the realities of investors wanting a return on their investment. You just wanted a product; the investors also want to make money.
You have discussions with the team about costs. They may find a less expensive way to do something; you may rearrange the order of work to focus more on desirable but low-cost features, leaving expensive features for later after the product is making money.
Now you are probably thinking, this sounds really nice, but I work in a corporate environment. What does a Product Owner look like there?
It should be the same. Basically pick up that whole team I just described and put them in a corporate setting. Instead of investors, you have a VP with a budget they gave you to develop a product or service. If the company truly believes in the Product Owner role, then you should behave exactly as if you are that passionate person who believes so much in a product, that you spend your own money to develop it.
You sit with the team all the time.
You research the market, competitors, options, users, subject matter experts.
You talk with the team about how they would go about creating the solution. You ask the team for several ideas and the relative effort of implementing those ideas. You have conversations with your VP (investor) about the best way to spend the money. The VP leaves the final decision to you, knowing that you will spend the money in such a way as to get the most value.
You have the autonomy and the authority to make the decisions that lead to the highest value product that you can deliver within the budget allowed. You do this after having conversations and considering the needs of the VP, users, other stakeholders, and the team. Your VP/investor and your team trust you to identify the highest value items. You trust the team to implement the solution effectively, efficiently, and with high quality. You trust the VP/investor to give you the best information about corporate direction and priorities.
That is a real Agile Product Owner.
If you have your VP /investor telling you what to do, then you are in a command and control environment. You are essentially working as a Senior Business Analyst, passing commands from your stakeholder to the team. If an Enterprise Architecture team is telling the team how to create the solution (instead of having conversations with the team about possibilities), you are not in an Agile environment. If a committee of subject matter experts is evaluating solutions without involving you, then telling you what solution they picked for your team to implement, they are not treating you as a Product Owner. You are in a command and control environment.
Agile is about conversations. It is about empowering people to be part of the solution. It is about trust.
