The role of Product Owner is sometimes played by the Scrum Master and sometimes by the team\u2019s 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n 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.<\/span><\/p>\n <\/p>\n Image 1: the team\u2019s backlog and the product development team.<\/i><\/span><\/p>\n \u00a0<\/span><\/p>\n 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n The Product Owner must learn to honestly say NO.<\/p><\/blockquote>\n 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 \u2013 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 \u201czeroth law\u201d 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n I confess \u2013 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 \u201cI will put it in the backlog\u201d than \u201cmaybe we won\u2019t do this in the near future,\u201d or, more frankly, \u201cthis does NOT sound sensible\u201d. 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n 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 \u201cin the middle\u201d 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.<\/span><\/p>\n Efficient management of the backlog would be easier if it were only 3\u20136 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n A better approach would be to have two storage places: an idea drawer and the actual backlog.<\/p><\/blockquote>\n 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n 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\u2019 implementation.<\/span><\/p>\n \u00a0<\/span><\/p>\n 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n A Product Owner\u2019s work mostly entails making \u201ceducated guesses\u201d \u2013 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\u2019s 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n Cooperation between the Product Manager and Product Owner is usually one of the success factors of well-functioning product development organizations.<\/p><\/blockquote>\n 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<\/span><\/a>, read it now!\u00a0<\/span><\/p>\n \u00a0<\/span><\/p>\n I have only scratched the surface of product ownership in this blog entry, but doesn\u2019t 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 \u2013 on the contrary, it is usually a highly rewarding and educational role \u2013 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.<\/span><\/p>\n \u00a0<\/span><\/p>\n Contribyte is the leading product development assistant in Finland. We have experienced <\/i>Product Owner<\/i><\/span><\/a> trainers, and we also offer many other <\/i>services<\/i><\/span><\/a> for developing your company!<\/i><\/span><\/p>\nDoes the Organization Understand How Much the Product Owner Influences the End Result?<\/b><\/span><\/h3>\n
![\"product](\"https:\/\/b845811.smushcdn.com\/845811\/wp-content\/uploads\/2018\/05\/Na\u0308ytto\u0308kuva-2018-5-29-kello-20.15.31-300x154.jpg?lossy=1&strip=1&webp=1\")
<\/p>\nThe Output Can Only Be as Good as the Input Offered to the Team<\/b><\/span><\/h3>\n
The Most Important Decision Is What NOT to Do<\/b><\/span><\/h3>\n
\u201cI Will Put It in the Backlog\u201d<\/b><\/span><\/h3>\n
Length of the Backlog \u2013 Keep It at a Maximum of 3\u20136 months<\/b><\/span><\/h3>\n
\u201cLet\u2019s Put It in the Idea Drawer\u201d<\/b><\/span><\/h3>\n
Everything Has Its Place in the Order of Priority. If You Do Not Know It, Guess!<\/b><\/span><\/h3>\n
Writing Stories Together Is Important<\/b><\/span><\/h3>\n
Let the Team Take Care of the Technical Implementation and Quality Issues<\/b><\/span><\/h3>\n
Customer Understanding and Discussions With Everyone Are Part of a Product Owner\u2019s Daily Life \u2013 Take Enough Time for Them<\/b><\/span><\/h3>\n
Remember to Sometimes Treat the Product Managers to Cookies!<\/b><\/span><\/h3>\n
Should I Become a Product Owner?<\/b><\/span><\/h3>\n