The Product Owner role is regularly debated and discussed in many online forums and blogs. The challenges of the role and the variety of responsabilities encompased by it are a frequent source of discussion and advice.
Recently there has been some discussion about common aspects of the role and the important activities a product owner needs to ensure happen on an agile project.
Mary Poppendiek wrote about “The Product Owner Problem” and states:
Discovery of the right thing to build is the most important step in creating a good product. Get that wrong and you have achieved 100% waste. Delegating decisions about what to build to a single Product Owner is outsourcing the most important work of the development team to a person who is unlikely to have the skills or knowledge to make really good decisions. The flaw in many Product Owner implementations is the idea that the Product Owner prepares detailed stories for the team to implement. This does not allow team members to be partners and collaborators in designing the product.
She discusses the varying aspects of the product owner role, and how the role encompasses a variety of responsibilities:
The Scrum Product Owner might be a role, but it should not be a job title. Product Owners wear many hats: Product Manager, Systems Engineer, User Interaction Designer, Software Architect, Business Analyst, Quality Assurance Expert, even Technical Writer. We would do well to use these well-known job titles, rather than invent a new, ambiguous title that tends to create a choke point and often removes from the development team its most important role – that of product design.
In a similar vein John Mansour talks about the confusion and overlap between the product owner and product manager role. In a blog entry titled “Agile Product Owner – New Name, Same Old Problem” he says that there are two important roles that teams need to have covered:
1. The “what & why” role – responsible for determining “what” functionality should go into a product and “why” from a market and business perspective. The “what and why” role serves as the conduit for all inputs both internal and external. The end game of this role is to grow revenue by aligning product direction with market dynamics and customer needs. The “what & why” function is typically the responsibility of the product manager. Traditional or agile, it’s necessary regardless of who does it, their title or how it gets done.He says that many agile teams make the mistake of combining the two roles into a single product owner, which often results in lack of clear direction and confusion:
2. The “how” role – responsible for determining “how” product features should work to support the things users do. In its most basic form, this role is a surrogate user responsible for explaining in verbal, written and illustrated forms and in excruciating detail, what users do, how they do it and how software must work “functionally” to support the users. They spend most of their time with developers and they test functionality to make sure it works as designed, along with a host of other responsibilities. And yes, the best people for this role are former users or those who have worked intimately with a variety of users in multiple environments
In my humble opinion, the confusion lies in two areas. First, software companies have been trying to combine responsibilities of the product manager and functional product designer for years and it’s a nightmare in every single case I’ve ever seen, and I’ve seen a lot. Plus it creates the same identity crisis as the product manager vs. the product owner in an agile world.
Regardless of development methodology, combining these roles is a recipe for failure because the skill sets and personality types required are distinctly different for each, not to mention the time commitment. When combined, the end result is either the right functionality with poor usability or highly usable features no one cares about. A dilemma on par with, “would you like to lose an arm or a leg today?”
There are also some commentators offering advice, suggestions and ideas for getting the best out of the product owner role
Monica Yap has started posting a series of posts on the theme “Product Owner Anti-patterns”. She identifies the following anti-patterns:
• The Absent Product Owner
• Copy The Last One
• The Churning Backlog
• The Waffling Definition of Done
• No Single Product Owner
• Not Enough Stakeholders
Jack Milunsky provides advice on the top 10 activities of a product owner:
1. Creates and MAINTAINS the Product Backlog
2. Prioritizes and sequences the Backlog according to business value or ROI
3. Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single sprint
4. Conveys the Vision and Goals at the beginning of every Release and Sprint
5. Represents the customer, interfaces and engages the customer
6. Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives
7. Inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done
8. Can change the course of the project at the end of every Sprint
9. Communicates status externally
10. Terminates a Sprint if it is determined that a drastic change in direction is required
What advice can you offer product owners and is the role the same as the product manager?