Product Owner, Not Agile Project Manager

The Product Owner in Scrum is accountable for the value delivered. Besides the fact that value is a very different  driver than volume is, that accountability can hardly be  demonstrated without a clearly identified ‘product’. Product is  the vehicle to deliver value. Neither can a Product Owner be  accountable and effective without a mandate to make decisions. 

Organizations often introduce Scrum by constructing teams within  existing departments and silo structures. The ‘Product Backlogs’ that  they work off may be fascinating collections of work, but they are rarely  for a…product. Although ‘product’ determines the scope, span and  depth of Scrum, it is one of the most ignored considerations when  Scrum is introduced. But…how can you then know what the Product  Owner actually owns? What purpose serves Product Backlog if not the  single source of work to optimize the value the product delivers? What is it  that releasable Increments are being created of when not of a well-defined  product? Without a clearly identified ‘product’ optimizing for value is  hardly possible and Scrum is hardly used effectively. 

When teams work within the confines of a traditional line organization,  the highest achievable definition of product is often a part of a system,  a component, a module or ‘something’ to be shipped to ‘someone’.  Teams deliver work to other teams that in turn combine it with their work or the (system) parts, components or modules they create. And  other teams again depend on the work to be received from them. As  the diverse teams often operate under different line management, it  ends up with nobody minding the synergies across them, with nobody  minding the actual…product and the value delivered to end-users. The  effective use of Scrum is impeded by mapping it to the old delivery  structures and keep producing the same parts and modules for the  same sub-products. 

The challenge is to know your product or service so you can start  organizing your Scrum to best serve the people consuming it! 

Following knowing the product, the mandate and autonomy for a  Product Owner is the next tactical challenge to tackle. Is your Product  Owner the best placed person to make business decisions or is your  Product Owner a proxy, a distant representative, a temp like a project  manager or some other intermediary? Are the decisions by your Product  Owner fully supported or does your Product Owner have to check in with  managers, directors or the steering committee before making a decision?  Any decision? 

Regardless, the minimal purpose of the Product Owner role in the  Scrum framework is to inject and uphold the business perspective in  the product development work. The Product Owner connects the  worlds of (1) product management and the business side of the organization (think: market research, sales, finance, legal, marketing), (2)  the user and customer base and (3) the delivery or development parts  of the organization. 

Connecting those worlds includes engaging with them to be assure that  all product management aspects and the wider business perspective  are integrated into the actual development. In the other direction it  allows the Product Owner to keep stakeholders and product  management people up to date on the actual development progress, so  they can organize or re-organize their work accordingly. Being a  connector is not the same as being a bottleneck. Product Owner, not  information barrier. 

Still, the Product Owner is the one person making the final call on the  order of the work in the Product Backlog. Product Backlog shows all  the work currently envisioned for the product, all work that potentially  increases the value that the product delivers. Smart Product Owners  show openness for great ideas whatever their source or origin and they  gracefully employ skills of development people to convert product  ideas and business solutions into requirements. Product Owner, not  product dictator. 

The Product Owner manages Product Backlog based on the product  vision as a longer-term view of the road ahead. A product vision  captures why the product is being built and why the product is  worthwhile investing in. A product vision helps the Product Owner set  or reset specific goals, hopes and dreams, express the expectations and  ideas captured in the Product Backlog better and better order the items  in the Product Backlog for value. 

If anybody wants to know what work is identified and planned for the  product, it suffices to look at the Product Backlog, at one artifact only.  If they want to understand what is planned for or what is in the  product, and why, it suffices to ask the Product Owner, one person  only. 

Sprint Review is a great opportunity for a Product Owner to learn about  the assumed or actual value that the product delivers. At the Sprint  Review (key) stakeholders, the team and (potentially) consumers or (key) users collaborate over what got done and what didn’t get done,  what influenced the work and what was the purpose of that work. But  value as the overall purpose is a very different driver than volume is  (the amount of tasks executed and features implemented). The purpose  of Sprint Review is not reporting or justification but to share  relevant information on usage, competition or market trends that will  help optimizing for value in the next Sprint(s). The goal is to  collaboratively identify what is the most valuable work to do next for  the Product. This is evidently captured in the living artifact that  Product Backlog is. 

Being a Product Owner certainly implies expectations, skills and traits  that go beyond those for a traditional requirements engineer, a  requirements provider or similar. Product Owner, ideally, is the owner  of the product. Such ownership of a product implies strong  organizational adoption of the role. It allows a Product Owner to act  like a product-CEO (again, not a product dictator). That accountability  of the Product Owner cannot be mapped on existing roles or functions,  deliverables and meetings. The role simply did not exist in the industrial  paradigm. 

Note. This article is based on texts that are taken from my current book-in progress “Views from the House of Scrum” (to be released in 2021).