The Product Owner. Partner of Stakeholders & Team,
and Responsible for the Product Backlog and Product Goal.
What role does a Product Owner play, and what’s needed for them to perform it?
The Product Owner. Partner of Stakeholders & Team,
1
2
3
4
5
In agile development methodology, the responsibilities of a Product Owner (PO) are large and clear. They should represent the interests of the stakeholders, develop the product vision, define the product characteristics and the product goal, communicate priorities, as well as ensuring the traceability between a product backlog and vision.
In practice, the duties of a Product Owner are a bit more ambiguous. Sometimes a PO doesn’t have any decision-making authority and is tasked solely with communicating the requirements of stakeholders to the Scrum team. Other times a PO might be an acting business sponsor, who makes product-related and financial decisions based on their assessment of a product proposal or a business case. The question it seems then is whether a PO primarily performs operational activities or highly responsible management tasks?
The Product Owner: An Accountability According to Scrum
Definition from the 2020 Scrum Guide:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is also accountable for effective Product Backlog management, which includes: developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering Product Backlog items; and, ensuring that the Product Backlog is transparent, visible and understood. (Scrum Guide 2020)
What Does a Product Owner Work On?
A central aspect of a PO’s job is the Product Backlog. The components of a backlog, called the Product Backlog Items (PBIs), reflect the decisions made by a PO in the sense that it is the PO that determine the content and the priorities afforded to each item. The consequences of these decisions come under subsequent scrutiny during Sprint or Increment reviews.
One prerequisite for the successful performance of any PO is for their decisions not only to be accepted by all involved in a project but also to be respected. Another necessity is that anyone involved in a project who wishes to change something a Product Backlog must first contact the PO. Naturally, the person responsible for the Product Backlog should also be the person that decides on whether or not it needs changes. If a PO does decide that substantial changes need to be made to a Product Backlog, they are also able to cancel or abort a Sprint.
Why Is There Only One Product Owner?
During the course of a project, perhaps a stakeholder asks “who do I contact if I have a new, very specific requirement?”, or a developer enquires “who can tell me the purpose of this backlog item?”. Answer: the PO. This can only work, however, when the PO is only one person. A team of PO’s risks different opinions being communicated when a stakeholder or developer has a question, as well as the transparency and coherency of product decisions.
The Product Owner has the authority to decide what gets built. This ties the fate of the PO’s work to the overall success of the product.
What’s a Proxy Product Owner?
In a nutshell, a Proxy PO is a mediator between a development team and a PO.
In larger projects being worked on by multiple teams and departments, the limitations in manpower that come from the PO only being one person get compounded. With maybe only a couple of hours a week to spend with each team, the benefits of clarity and a direct line of communication that a sole PO brings are outweighed by the dangers of the PO losing their perspective and therefore their ability to make the right decisions. When this happens, a Proxy PO is introduced to perform the following tasks:
- To ensure that the developers understand the elements they are working on at the required level.
- Alongside the PO, maintain the backlog and formulate PBIs.
- Check on acceptance criteria and approve stories.
- Lead demonstrations and reviews.
Just like the PO, the success of a Proxy PO’s work is tied directly to the value of the product. To successfully perform their role, a Proxy PO needs to know how to translate business and customer interests into a valuable and worthwhile product.
The obvious disadvantage with a Proxy PO is that the direct line of communication developers and stakeholders have with the sole decision-making body is lost. Nevertheless, even when Proxy PO’s are required, the actual PO still bears the ultimate responsibility for the product. As stated in the Scrum Guide:
“The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.”
Follow a manual added linkYour free trial of
Your free trial of
objectiF RPM
The perfect Product Backlog management tool
Follow a manual added link
Agile Project Management
Knowledge to go
Agile Project Management
and Scrum at a glance
to Download
What Skills Does a Product Owner Need?
To create value for an organisation or customer, a PO always needs to have an overview of the context of the respective business they are dealing with, and the solutions that might be needed. This means that a PO must possess the ability to think analytically. A PO needs to be able to think like the customer they are working with, envisioning the problems the customers might face and knowing what solutions will please them.
At the same time, a PO needs to be agile in the sense that they need to find new and inventive ways of creating product value. This involves a sober approach to strategy and the feasibility of requirements. At the same time, a PO needs to minimize the waste of human resources by making sure that nothing from the development team ends up in the recycling bin.
8 Product Owner Skills
1
2
3
4
5
6
7
8
Product Owner Techniques
The more multifaceted the tasks a PO has to manage, the more expansive their toolbelt needs to be. Among the tools at a PO’s disposal are techniques for agile working and planning, leadership, communication, as well as being able to come up with new ideas, solutions and a dynamic approach to decision-making. What forges these tools is, among other things, an adherence to the disciplines of agile methodology, business analysis, requirements engineering, product management and UX design.
Here is a list of just some of the necessary techniques and methods a PO will benefit from:
| Business Case | A Business Case evaluates the benefits, costs and risks of a project. A Business Case serves as the basis upon which a project is accepted or rejected.. |
| Business Model Canvas | A Business Model Canvas is a planning template that is split into nine segments: key partners, key activities, key resources, value proposition, channels, customer segments, cost structure, revenue streams. It’s used to create a structured and interactive mode of development for a team working on a business model. |
| Collaborative Games | Collaborative Games foster a sense of togetherness and collective responsibility within a team, which in turn helps create a collective understanding and approach to problem-solving. |
| Customer Journey Map | A Customer Journey Map depicts the interactions, concerns and positive experiences a customer might have with a product. It helps a project team empathize with prospective and existing customers and anticipate any points of improvement. |
| Elevator Pitch | An Elevator Pitch is a short presentation that details the advantages of a solution in the time it would take to take a trip in an elevator. |
| Human-Centred Design | Human-Centred Design is a problem-solving approach based on observations of human behaviour. |
| Kano Model | A Kano Model depicts the relationship between the realization of customer requirements and customer satisfaction. |
| Minimum Viable Product | A Minimum Viable Product (MVP) is the first functional version of a product. Its purpose is to gauge a response from the market and decide from there what improvements need to be made, what needs prioritizing, or even if it makes sense to carry on investing in and developing a product. |
| Personas | Personas represent user archetypes or prototypes for a group of users. It’s highly recommendable to develop Personas when a company don’t have direct access to prospective users. Even if Personas are predictions of user behaviour, they facilitate a development team in anticipating possible problems they might have to solve in the future. |
| Defining and Analysing Problems | Problem analysis identifies both the origins and effects of problems. Everyone involved working on a project, from stakeholders to the development team, should treat identifying problems as the first step towards forming a product vision. |
| Backlog Grooming / Refinement | Product Backlog Refinement, along Scrum lines, is a continuous process of refining backlog items until they are ready to be implemented in a sprint. |
| Product Roadmap | A Product Roadmap depicts the route along which a project team plans on realizing their vision. Usually covers a one-year period. |
| Product Vision Board | A Product Vision Board shares several similarities with a Business Model Canvas; they are both planning templates split into multiple components, as well as assist in the interactive development of a shared vision for the development of a product or the attainment of a goal. |
| Story Mapping | A User Story Map arranges user stories, derived from user experiences, into a structured model. This creates an overview of the big picture regarding requirements and the functionalities of the product under development. This enables more accurate planning for releases. |
| Stakeholder Analysis | Stakeholder Analysis is a technique that identifies, before a project begins, all those involved in a project, those who might have interests in a project, their relationships with one another, as well as their goals. |
| Value Stream Mapping | Value Stream Mapping (VSM) is a technique used to identify and optimize value flows within an organization. The objective here is to weed out any unnecessary work processes between and within organizational units. |
