Terrence Joe bio photo

Terrence Joe

Agile Consultant

Email Twitter LinkedIn

Overview

I went to an agile talk where the speaker made an outlandish claim. He said in an off the cuff comment that in about 20 years of consulting across many different agile teams, he has met only 1 or 2 good product owners.

That statement, like a carefully crafted Daily Mail headline, got me thinking… How many good product owners have I seen? What makes one “good”? Are we asking too much from one role? How can we try and improve the situation?

There seems to be a lot of focus on agile coaches and scrum masters, and the poor product owner can often be overlooked. However the Product Owner plays arguably the most important role of a team, a critical role for successful agile delivery.

What is a Product Owner?

With numerous responsibilities, there are a number of different thoughts our there about what defines them, and what is involved with the role. I think though there is one key attribute that defines the product owner:

The person who is ultimately responsible for the direction and success of the product

That is a pretty heavy burden for anyone to take on. What exactly is expected of a product owner to justify such a big claim?

Be the product owner they said, it'll be fun, they said...

The Product Owner

…owns the Backlog

The backlog is the priority ordered list of User Stories that the team will work on. While User Stories may originate from a number of different sources (the team, the sales department, the CEO, etc), it is the Product Owner who must filter through the noise and make the final call on what does and what doesn’t go to the top of the Backlog.

To do this they will have to gauge the value of the stories vs the size of the stories. Of course, both of these figures will just be best guesses, but the product owner can get help to guess the value of a story by engaging stakeholders, and communicate with the team to help size them.

Note: The toughest part here will be saying “no” to new user stories. There will likely be far more stories coming in than what the team will be capable of outputting.

Owning the backlog makes the Product Owner a bit like the captain of a sailing ship. We have all seen videos of the crew on a ship working at a fervent pace, and the whole crew are responsible for how well the ship will move and respond. However at the end of the day, the ship will go exactly where the captain points the rudder. In the same way, the scrum team will work hard to achieve their sprint goals, and the team is responsible for the quality and speed of its output, but ultimately the product will end up where the Product Owner steers the backlog.

This is not to say that the team cannot feel some shared ownership of the product, or have some input with writing stories on the backlog. There is however, one role who can see the “big picture” and so has the final say on what stories make it into the backlog.

…is the Business Domain Expert

The Product Owner is generally an expert in the business domain of the product; a person who may be a power user of the system, or who has intimate knowledge of the business domain, or who has a great understanding of the intended market.

This may not necessarily be the case at the very beginning; a product owner could certainly learn the business ins and outs along the way. If the product owner is not the current business domain expert, they know who is and can help the team to get access to the experts when necessary.

…is a visionary that can inspire

The Product Owner should have a clear roadmap in mind of where they intend to take the product. Of course, in the spirit of Agile and empiricism, this vision is subject to change as feedback is received.

A good Product Owner not only has a vision, but is able to share it and use it to inspire the team, to give them purpose of where they are going.

A sailing crew will work hard for their captain, and follow his direction even when they can only see blue water ahead. But what a difference it would make to their drive and motivation, if the captain told them that while they cannot see it now, he is leading the boat to an island full of treasure!

Sharing the vision of the product, and how that vision is being achieved, can go a long way towards inspiring and motivating the team.

…is a part of the team

So far, the product owner is like the face of the business and the domain experts to the team. Well on the flip side of the coin, they are also the face of the team to the rest of the business.

With the product owner being so invested in the product that the team is working on, it only makes sense that they are in the trenches with the team, working closely with them, knowing exactly where they are at and helping to answer any questions they may surface.

I think it is crucial that the Product Owner is counted as, and behaves as, part of the team.

If this team bond is strong, and the team trust and respect their product owner, they will feel more combined ownership of their product and work hard to support him or her. The more shared ownership and knowledge the team may glean from the product owner, and the less they are blocked or go in the wrong direction because such knowledge is absent, the better.

The product owner in turn will have greater knowledge of how the team functions, what they are working on and any pain points they might be experiencing. He or she will then be much better placed to provide an answer when asked how the product is progressing, and can confidently and accurately represent the product status back to the business. The product owner doesn’t have to be a technical giant, but a small understanding of what the team is working on will definitely help.

…gathers and responds to customer / stakeholder feedback

The success of the product in itself might be a tough one to define. It might be that the software is fit for a particular purpose, or that the number of user sales or sign ups are increased, or that customer satisfaction goes up. Whatever the case, there will usually be one, or many customers/stakeholders, who can help to guide the product along the way.

Because Scrum works with iterative releases, there should be many opportunities for the stakeholders (or customers, control groups, etc) to be able to see the product and to give feedback on how they think it is going. For the best chance at “success”, it is essential that the product owner takes advantage of such feedback and continually uses it to reassess the direction that the product is going in.

Summary

These are just some of the key functions that a “good” Product Owner will need to fulfil. The product owner owns the backlog, is a domain expert, a visionary, the face of the team, the facilitator of key stakeholders, and an all round generally good person. All of these roles are interrelated, however all of them centre around having strong collaboration and communication skills.

The reality is though, as noted at the beginning, while it is a critical role in the team and for agile delivery, more often than not it’s not such smooth sailing. In a future post I will run through common barriers teams and organisations may face with the product owner role, and what we as agile coaches, scrum masters, and team members can do to help to mitigate them.

Product Owner - 3 challenges with the backlog
Product Owner - 3 challenges with the role