I strangely often come across a situation in which a team lacks an actual named Product Owner despite having a Scrum Master (which is usually a job “done on the side”). In some cases, a Product Owner has been named, but they cannot perform the duties of this role in practice due to not having either the skills or the time to perform them – or the individual is simply not near and available to the team.

The role of Product Owner is sometimes played by the Scrum Master and sometimes by the team’s Line Manager. The role occasionally falls to the Project Manager and sometimes the Product Manager. I also often encounter a situation in which several people simultaneously think that they are performing the tasks of the Product Owner.

Does the Organization Understand How Much the Product Owner Influences the End Result?

I sometimes feel that organizations fail to fully understand the impact of product ownership on the end result. It may be difficult to justify why someone who is not a developer should be attached to the team on a full-time basis. If this is something that is difficult to justify to others in your organization, I hope that this blog entry will give you some thoughts, as I intend to tell you here why product ownership has a major impact. The great power of the Product Owner can be understood when you realize how an agile product development team works.

Image 1: the team’s backlog and the product development team.

The Output Can Only Be as Good as the Input Offered to the Team

The Product Owner is the most important individual who decides within the organization what is included in the backlog funnel that provides work to the team and in what form the work is provided to the team from there. No matter how good the team is, the end result, i.e., the output, can be poor if the input (usually user stories) is of poor quality, less prioritized, or incorrectly chosen.

The Most Important Decision Is What NOT to Do

The Product Owner must learn to honestly say NO.

The first and perhaps most important decision of a good Product Owner is to assess the continuous stream of ideas and pick the ones with most potential for further development – and then throw the rest in the trash or leave them to mature on a wishlist somewhere. So the first decision is to decide what NOT to do. The Product Owner must learn to honestly say NO. It is extremely common, or you could even say the “zeroth law” of product development, that the number of ideas proposed to the development team is always greater than what is possible for the development team to achieve in practice. Even a new team very quickly finds itself in a situation in which the items in the backlog, even if they are listed in an order of priority, would take over a year to implement.

“I Will Put It in the Backlog”

I confess – I myself have been guilty of this 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”. When we say that we put something in the backlog, it means that the item will go directly to the end of the backlog, which means that it will practically never be implemented.

Length of the Backlog – Keep It at a Maximum of 3–6 months

Sometimes a backlog includes many years worth of work. It is clear that this type of backlog is not functional in practice, as the team will continuously take on new work and place it “in the middle” of the backlog, so that the work will be completed within a few months. However, it would be better if you did not allow an artificially long backlog to accumulate in the first place and if the Product Owner were able to filter the stream of ideas and only pick the truly valuable ideas for the backlog.

Efficient management of the backlog would be easier if it were only 3–6 months long. Other ideas could then be kept on separate wishlists or somewhere else not on the to-do list, but the stream of ideas is usually not a problem in companies. Any truly important items will come up again and again. Transparency is also important in this aspect, as the entire organization should understand how you, as the Product Owner, seek to manage the backlog, i.e., where you keep the ideas, user stories, and epics.

“Let’s Put It in the Idea Drawer”

A better approach would be to have two storage places: an idea drawer and the actual backlog.

Perhaps a better approach would be to have two storage places: an idea drawer and the actual backlog. Just like the actual backlog is groomed, the idea drawer could also be groomed by a slightly different group of people to identify items to be added to the backlog. This is starting to resemble Kanban in the product management process.

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.

Valuation of user stories is very difficult and perhaps warrants the creation of your own blog. Sometimes, a user story involves a direct customer order, which makes valuation easy. However, in many cases it is pure guesswork.

Writing Stories Together Is Important

When the work to be performed has been chosen, the next task of the Product Owner is to ensure that the stories allow the right things to be completed and the team is able to work efficiently with the stories without any wasted effort. In other words, the stories should be sufficiently brief, clear, and independent of each other, and they should 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.

Let the Team Take Care of the Technical Implementation and Quality Issues

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 finetune the story to be even more valuable.

Customer Understanding and Discussions With Everyone Are Part of a Product Owner’s Daily Life – Take Enough Time for Them

A Product Owner’s work mostly entails making “educated guesses” – guesses about which stories are the most valuable right now, or which stories simply have to be abandoned because they do not deliver enough added value, or are difficult to sell or too laborious. Perhaps 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 guess in these situations that are encountered on a daily basis. The value of customer contacts and continuous discussion is very high to a Product Owner, and an adequate number of working hours should be reserved for it.

Remember to Sometimes Treat the Product Managers to Cookies!

Cooperation between the Product Manager and Product Owner is usually one of the success factors of well-functioning product development organizations.

In organizations, the Product Manager is usually someone with even more responsibility for customer contacts and customer understanding than the Product Owner. As such, cooperation between the Product Manager and Product Owner is usually one of the success factors of well-functioning product development organizations. If you have not yet read my previous blog entry about the differences between the roles of Product Manager and Product Owner, read it now! 

Should I Become a Product Owner?

I have only scratched the surface of product ownership in this blog entry, but doesn’t it already seem funny how important a role it is and how often we still encounter situations in which product ownership is a somewhat unclear role within the organization? Or how often we encounter a situation in which 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 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.

Contribyte is the leading product development assistant in Finland. We have experienced Product Owner trainers, and we also offer many other services for developing your company!