It all starts with doing the right thing. Agile has not changed the old computer wisdom of “garbage in, garbage out”. This is why Allan Kelly last book is dedicated to the art of Agile product ownership. As he wrote: “If a Scrum Master performs badly, the team simply fails to perform well. If the Product Owner performs badly, the whole product is in jeopardy”.
The Art of Agile Product Ownership book focuses on the diversity of the Product Owner role and explains the differences of this position compared to the business analyst, product manager, project manager or subject matter expert roles. An important distinction is made between what the Product Owners do “onstage”, that is with the team, and “offstage”, that is when they are not working directly with the team when they are doing research and analysis to make sure the team will create the highest possible value for instance.
My favorite part is the chapter 11 where Allan Kelly explains what the Product Owner shouldn’t do so that she can focus on her most important tasks. This book is clearly written and mixed pleasantly concepts, use cases and anecdotes from the author experience as an Agile coach. The book ends with two pages of a nice reading list for every Product Owner.
I will recommend this book naturally to everybody that will have the responsibility of being a Product Owner in a Scrum project. Other member of Agile teams will also benefits of having a better understanding of what being a Product Owner means.
Reference: The Art of Agile Product Ownership: A Guide for Product Managers, Business Analysts, and Entrepreneurs; Allan Kelly, Apress
Quotes
Product Owners do not work in isolation; they are the first and foremost members of a team charged with creating and delivering products and/or services—typically software development teams. They will be members of other groups too: Product Owner groups, strategy groups, and occasionally members of the management cadre.
As a member of the delivery team, they have particular responsibility for “what is being delivered.” The responsibility is not exclusive; other team members have views and with encouragement should share them. Still, Product Owners are first among equals when it comes to nominating what to build, and what to build next. Their skills, experience, time spent with customers (and users), research, analysis, and more mean they are (or at least should be) the best-informed people to make such decisions.
Importantly the Product Owner will need to say “No” to requests. Technology teams are usually full of good product enhancement ideas. Senior people, outside the team, will often make “suggestions” too. No team could implement every idea, and someone needs to be able to say “No.”
Using a Product Owner as a central request hub (Figure 2-4) does not mean the development team do not speak to customers. Direct contact between developers and customers is to be encouraged. Having a PO in place creates a mechanism to arbitrate between diverse requests and see them in relation to one another.
The perfect Product Owner probably doesn’t exist. The role is hard to fill at the best of times. Frequently things are made more difficult by the constraints and extra demands organizations impose. That does not mean that one should give up trying, nor does it mean that one cannot be a good Product Owner.