Does this scenario sound familiar? A new development team comes together to build the latest feature which is suddenly priority number #1. Grand visions are presented, slick prototypes produced, and graphs showing hockey-stick shaped growth begin to build excitement around what is to be delivered. The nicely ordered backlog is transferred from post-it notes to JIRA, and with a wave of enthusiasm the first sprint kicks off.
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 crucial customer segment? How will you meet compliance rules? Won’t this be competing with our other products?”. On top of this, different stakeholders are wanting their features and requirements addressed — and suddenly the backlog is getting out of control.
This is Agile without a product owner. A bit like a boat without a rudder, progress is being made but there is no guarantee that it’ll 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 product owner role 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 maximising 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 this disclaimer:
“How this is done may vary widely across organisations, Scrum teams and individuals.”
This raises the question… 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, it’s limitations and their impacts.
The product owner should be able to speak with authority on any of the product features, 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 they should have a broad understanding of the technology stack, and changes in the technology landscape which present opportunities or challenges to product performance.
The difference between a product owner role and a product manager are part of an ongoing debate (a subject for another blog maybe…) but regardless both are experts within the context of the product. Even more important than product knowledge, is the expertise in executing the steps in bringing new products to life, and managing the product 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 their customers are and understands their needs and motivation, so as to ascertain what is most important to them and why. Having empathy for the customer is critical for a product owner — the ability to determine the value of potential new features by assessing these from the customer’s perspective, and then prioritising in the backlog accordingly.
Constantly seeking, gathering and interpreting feedback is critical for product owners who need to be listening to what their customers are saying via multiple channels1, whether this be 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 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 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 they have the autonomy to bring their own creativity and insights to the problem to create better solutions. 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 prioritises (then re-prioritises)
Maximising the value of the product is the main responsibility of 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-prioritising 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 first completed, which provides no immediate customer value.
It’s the product owner who needs to either de-prioritise the functionality or prioritise 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.
On first glance it would be easy to assume that as the decision maker and a 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 organisation, 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 group2.
Plans the product 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 realised through the plan to build and then release new features, as well as the functionality for customers (and as how this value will be measured).
In answer to your question…
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 responsibilities and skill-set are broad and will vary widely across organisations, 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.
Learn how you can play your part in identifying and creating real value — in Elabor8’s ICAgile certified Agile Product Ownership training course.
- Generate deeper customer insights from within your organisation
- Why the user experience of your UX stakeholders matters