Does this sound familiar? A new development team comes together to build the latest feature which is suddenly the ‘number #1’ priority. Grand visions are presented, slick prototypes produced and graphs showing ‘hockey-stick’ shaped growth and benefits build excitement around what is to be delivered. The backlog is transferred from post-its to JIRA, nicely ordered, and with a wave of enthusiasm, the first sprints commence.
Agile Cockpit offers training and consulting services in Product Ownership
Everything is clear and makes sense, but as showcases are delivered and stakeholders can see the product coming together questions start being asked. ‘How will this work with our other products?’. ‘What about this priority customer segment?’. ‘How will you meet compliance rules?’. ‘Won’t this be competing with our other products?’. Different stakeholders begin wanting their features and requirements addressed and the backlog begins to get out of control. Prioritization is difficult as everyone’s requirement is priority
#1 and progress beings to slow as gaining consensus requires a decision by committee and no one will agree. The team beings to complain that they are overloaded with side-projects and other work that they keep being asked to contribute to.
What was once clear and easy is no longer. Stories are completed but the direct link to value is not evident. Eventually, the team begins to wonder “Why are we building this?”, “Who even asked for this feature?”.
This is agile without a Product Owner. A bit like a boat without a rudder, progress is made but there is no guarantee that this will be in the direction of the desired destination. The boat might just go around in circles or even worse begin to sink once it loses enough momentum.
Enter the Product Owner
The role of the Product Owner was introduced in the Scrum Guide to essentially avoid this scenario. Some of the key principles from this are:
- “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team”;
- “The Product Owner is one person, not a committee”;
- “The Product Owner may represent the desires of a committee, but those wanting to change a Product Backlog item’s priority must address the Product Owner”; and
- “No one can force the Development Team to work from a different set of requirements”
However, so as not to be too prescriptive (and unfortunately for those looking for the detailed role description) the Scrum Guide also includes the disclaimer “How this is done may vary widely across organizations, Scrum Teams, and individuals”.
So… what does a Product Owner actually do?
Knows the Product (…like really knows the Product)
The Product Owner is primarily a ‘Products Person’, quite different from a Project Manager or Delivery Manager who is primarily responsible for the delivery of an outcome.
The Product Owner lives and breathes the product, knows how it works, who uses it, when they use it, why they use it, and most importantly what doesn’t work and the impact this has. The Product Owner should be able to speak with authority on any of the features of their product, the value these deliver, and the business rules which drive them.
They may need to defer detailed technical questions to members of the Development Team but should have a broad understanding of their technology stack and changes in the technology landscape which present opportunities or challenges to their product.
Whether there is any difference between a Product Owner and a Product Manager is an ongoing debate (a subject for another blog maybe…) but regardless both are experts within the context of the product that they are responsible for. Even more important than the product knowledge is the expertise in executing the process to bring a new product to life and manage this through the complete lifecycle to deliver ongoing, incremental business value. In this way, a Product Owner is much more than just a Subject Matter Expert.
Has Empathy for the Customer
The Product Owner knows who its customers are and understands their motivations and requirements. Having empathy for the customer is critical for a Product Owner to be able to determine business value from potential new features by assessing these from the customer’s perspective and then prioritize in the backlog accordingly. As such the Product Owner needs to be able to understand the motivations of their customer so as to determine what is most important to them and why.
Constantly seeking, gathering, and interpreting feedback is critical for Product Owners who need to be listening to what their customers are saying via multiple channels, whether this is through formal customer testing, social media, or informal feedback from colleagues, friends, or others in their network. A good Product Owner is data-driven in their approach, validating assumptions and identifying opportunities based on patterns in data for how their product is actually being used by customers.
Sets the vision and goal for the team
The Product Owner fills a key role in defining the purpose for the Development Team by describing the vision and setting the goal that they are striving towards. Essentially it is up to the Product Owner to be able to confidently answer the question “Why are we building this?”. The Product Owner understands the problem being addressed in great depth and needs to use this understanding to inspire the team.
A team that is motivated around a shared goal and purpose will take ownership and pride in what they are delivering and feel like they have the autonomy to bring their own creativity and insights to the problem to create a better solution. A team without this motivation and depth of understanding will just be completing work, delivering stories in the backlog as these have been defined. It is the Product Owner who has the responsibility to get the team working according to the former and avoiding the latter.
Defines the backlog and prioritizes (then re-prioritises)
Maximizing the value of the product is the major responsibility for the Product Owner. All new products or features commence as an initial idea or concept of something that could be delivered. Defining business value and then quantifying this against a concept is a key task for the Product Owner, as is translating this from an idea to a backlog of requirements that are ready for development. This inception process may draw on a range of stakeholders (for example UX designers, technology leads, operations support, legal, etc.) and techniques (e.g. customer journey mapping, storyboarding, personas, prototyping, etc.). It won’t necessarily be the Product Owner who has the skills to facilitate this entire process, but it will be the Product Owner who ensures that the process is effective, delivers the required outcomes, and involves all of the right people.
In line with the core agile principle of responding to change rather than avoiding it, once the backlog is defined the Product Owner will need to be constantly re-prioritizing based on everything the Development Team learns as they commence building out the feature. For example, certain functionality may prove to be much more difficult to build than first thought or it may now require significant foundational technical work to be completed first which provides no immediate customer value. It’s the Product Owner who needs to either de-prioritize the functionality or prioritize the foundational work to enable this (and then repeat this over and over as the build cycle progresses). Understanding the trade-offs in remediating ‘tech-debt’ to ensure that a product is maintainable versus devoting one hundred percent of the team’s effort to building new features is a core trait of a skilled Product Owner.
At first glance, it would be easy to assume that as the decision-maker and single point of contact for the product, the Product Owner is the person with all the answers, the subject matter expert in all areas. In reality, it is quite the opposite. It is their responsibility to be connected with all the right people, both within and external to the organization, to ensure that they are informed to make decisions which represent and take into account the views and opinions of all relevant stakeholders. In this way, it is the Product Owner who shields the Development Team from all of the external noise such that they see only a single backlog and a clear view of the priority of items within this. Behind the scenes though, the Product Owner needs to be constantly collaborating, negotiating, and influencing across this stakeholder group.
Plans the roadmap
The Product Owner is able to see the bigger picture in terms of where their product sits and where this is headed. This is beyond just the vision for the latest feature but for where the product needs to be and the competitive landscape within which it exists. Is it trying to enable the best possible customer experience, or provide the largest possible range of features? The Product Owner is who can most clearly articulate this vision and link this back to the value which this will deliver. Along with the roadmap for the product, the Product Owner also needs to understand how the value will be realized through the plan to build and then release new features and functionality to customers (as well as how this value will be measured).
So part Product Designer, part Business Analyst, part Project Manager, part Marketing Analyst, part Delivery Lead as well as several other roles. The Product Owner skill-set and accountabilities are broad and (as outlined in the Scrum Guide) will vary widely across organizations, teams, and individuals although the main activities will be similar to what has been described here. Regardless of the scenario, the core attributes of being the ‘voice of the customer’ and the greatest advocate for the product should always hold true.
Interested in a career as a product owner? Check out AgileCockpit certified Agile Product Management training course.