One of the key contributors to an effective agile team is having a good Product Owner. A good Product Owner helps the team by setting the priorities. They also help the team to understand the “why” of doing things – what is the underlying problem that needs to be solved. The team can then more accurately design a suitable solution.
Problems with Product Ownership
While almost no one disagrees with the above, it is surprising how often teams still have to work without a Product Owner. Problematic situations arise if:
- the Product Owner role is handled by the Scrum Master or a line manager
- the role is taken care of by the product manager, who is not engaged with the team on a daily basis
- a Product Owner is missing altogether
- the role is thrust to someone who already has too much on their plate
These suboptimal approaches are the result of the whole organization not understanding the impact of good product ownership. The end result is that teams work without priorities, direction, or purpose. This leads to reduced motivation, poor cooperation, and ineffective use of time and resources.
Check out the free Product Owner’s startup guide.
Dedicated to the team
A good Product Owner has to be able to dedicate at least 40% of her time to product ownership. She also has to work intimately close with the team. This is one of the key success factors for good Agile. The great power of the Product Owner can be understood when you realize how an agile product development team works. Let us take a brief look at different factors that show why good product ownership is so essential.
The quality of the output depends on the input
The product backlog is the team input. No matter how great the team is, the output can only be as good as the quality of the input. The Product Owner is responsible for choosing and prioritizing the items on the backlog. The team and the PO together are responsible for discussing and defining the top items before starting. The why of the items, the acceptance criteria, and other definitions help the team to do the right thing.
In Agile, we don’t need more “yes” people. We need more “why” people. The Product Owner must learn to say NO. The core of prioritization is that not everything can be done. Someone must say no.
Many organizations reward people or teams who “try to do it all.” People who try to prioritize and say “no, we are not going to do that,” or “please explain why this is important” are sometimes regarded as difficult people.
If we agree that there are always more ideas and opportunities than the team can actually complete, then it is also true that we cannot do everything. Someone has to say no. Saying no is, in fact, the same as prioritizing.
Squeeze the why
Saying “no” is the first step in forcing the requester to explain herself in more detail. With a reflex-yes, we are bypassing the powerful stage of interrogation. Why do you request this thing? One of the main services that a Product Owner can offer to the team and the organization is to “Squeeze the Why” out of the people who make requests.
This is one of the key reasons for the importance of the Product Owner role. By having Product Owners and agreeing that these people say no, the organization in principle institutionalizes the decline as acceptable, even needed behavior.
The biggest lie – “I will put it in the backlog”
The above statement is the most common lie of a Product Owner. If someone proposes an idea, but it is difficult for you to see its potential, it is much easier to say that “I will put it in the backlog” than “maybe we won’t do this in the near future,” or more frankly, “this does NOT sound sensible.”
Saying that we will do it just to get away from the person making the request is dishonest. It also adds unnecessary items to the backlog, making it longer and more difficult to manage.
Length of the backlog
Backlogs that include many years worth of work are not functional in practice. These backlogs grow to be so massive and the lead times so long that items near the bottom are never implemented. They become forgotten, slowly decomposing into “backlog mud,” a smelly set of stories nobody wants to touch.
In such situations, the team starts to introduce new important items near the top of the backlog. The rest is never looked after. The risk is that some part of the decomposing backlog of mud items can actually contain valuable items that should be nearer to the top.
The Product Owner should manage the size of the backlog so that regularly scanning it completely is not too time-consuming. This is only achieved by holding strict controls on what actually gets into the backlog and directing other requests with quick analysis to garbage or wishlists.
Everything has its place in the order of priority. If you do not know it, guess!
The Product Owner should be able to guess how valuable an individual idea could be and how much work it would require. The ability to estimate the effort improves when the Product Owner familiarizes themselves with the product and gains experience in it. Until you are able to accumulate adequate experience, you should get assistance from members of the development team and carry out assessments of the ideas during a backlog grooming session or informally, for example.
Writing stories together is important
The next task of the Product Owner is to ensure that the stories allow the right things to be completed. The stories should have an agreed level of acceptance criteria and descriptions. They should also be discussed with the team members to ensure that everyone understands what they are doing and to make any necessary technical adjustments to the stories’ implementation. Effort estimates after such discussions are much more accurate. Accurate effort estimation improves the team's velocity and sprint loading accuracy. This reduces the stress level of the team and, in that respect, also leads to a positive cycle of creativity.
Trust the team but be curious and interested
The Product Owner should be curious about the stories in progress while giving the team technical ownership to implement the stories in a high-quality, healthy, and easily maintained manner. I would recommend that the Product Owner visit the development team on occasion to ask how the work is progressing and whether they have encountered any problems. In many cases, these issues involve good opportunities to fine-tune the story to be even more valuable.
Discuss with customers and stakeholders
A Product Owner’s work mostly entails making educated guesses about which stories are the most valuable right now. Sometimes some stories have to be rejected outright. Sometimes stories should be abandoned after they have been studied for a while.
The most challenging part of a Product Owner’s work is to maintain adequate customer contact and market understanding in order to ensure the best possible guesses in these situations. The value of customer contact and continuous discussion is very high to a Product Owner, and an adequate number of working hours should be reserved for it. How much is enough? Rather than a strict number, I recommend Product Owners to think, “Which stakeholder should I talk to today?”. If you engage stakeholders or pilot customers a day, you are sure to be in contact with all important parties soon enough.
Cooperation with the Product Managers
Cooperation between the Product Manager and Product Owner is usually one of the success factors of well-functioning product development organizations.
The Product Manager has a wider responsibility for customer contacts and customer understanding than the Product Owner. He might be talking to tens or hundreds of customers. The Product Manager can act as a guide to show the direction where the product is being taken. He should help the Product Owner to get the necessary customer understanding and direct contacts.
Successful Product Owners interact with their related Product Managers on almost a daily basis.
Should I become a Product Owner?
Here we have only scratched the surface of product ownership, but already we can see that it is an important role with a vast impact on product development results and efficiency. Even so, in many situations, the role of Product Owner is given to someone who does not have any particular training for it or any prior experience in it.
The role of the Product Owner is at the center of agile development, and although it is not an exceedingly difficult role – on the contrary, it is usually a highly rewarding and educational role – it should be taken seriously, and enough time and capacity should be reserved for it. The role of Product Owner is quickly learned, but the best starting point for this new role is expert training.
Published: Sep 29, 2022
