What Makes A Good Product Owner?

This post is part of our “in-depth” series. Each post discusses scientific research that is relevant to our work with Scrum and Agile teams. With this series, we hope to contribute to more evidence-based conversations in our community and a stronger reliance on robust research over (only) personal opinions.

What makes a good Product Owner? How much time should they spend with their team or with stakeholders? Or writing items for the Product Backlog? Do Product Owners require a full mandate in order to be effective? What strategies make them more — or less — effective?

There are many opinions about this in our community. For example, there are supposedly eight stances for Product Owners. Others argue that Product Owners are great when their team doesn’t need them. A common opinion is that Product Owners should actively experiment and test hypotheses. I gladly support these opinions. At the same time, I wonder what a scientific perspective has to offer.

From our own quantitative research with 1.200 Scrum Teams, we know that teams are more effective when they are more aware of the needs of their stakeholders. And Product Owners certainly seem to play a role there. But as Unger-Windeler and her colleagues write (2019): “While [the] role is supposed to maximize the value of the product under development, there seemed to be several scattered results on how the Product Owner achieve this, as well as what actually constitutes this role in practice.”

In this post, I explore scientific research that addresses the role of the Product Owner. So I opened Google Scholar and searched for all academic publications containing the word “Product Owner”.

Insight #1: Theory Is Different From Practice

The Scrum Guide seems pretty clear about what Product Owners are accountable for. They should develop and communicate the Product Goal, manage items and their ordering on the Product Backlog, and ensure that the Product Backlog is understood by stakeholders and team members. But is this also what Product Owners do in practice?

One consistent pattern in studies about Product Owners is that there is a gap between the theory of the Scrum framework and how it is practiced. 

• Sverrisdottir, Ingason & Jonasson (2014) interviewed Product Owners from different organizations that there are often multiple Product Owners for the same product, even though the Scrum Guide prescribes against this. 
• What distinguishes Product Owners from other roles in organizations is also understood differently. Van Waardenburg & Van Vliet (2013) offer a case study in a large organization and conclude that “The Project Manager focuses on the ’how’ of a project, the Product Owner focuses on the ’what’”. Furthermore, Sverrisdottir, Ingason & Jonasson (2014) observe that some Product Owners expect Scrum Masters to maintain the Product Backlog, although this contradicts the Scrum Guide.
• Sverrisdottir, Ingason & Jonasson (2014) also found no standard for how much time Product Owners spend with teams. This ranged between 5% and 70% of the available time. Some Product Owners are highly involved with their teams, whereas others consider their work done when the product “is defined”.
• The Product Owners that were interviewed agreed that Scrum had increased project success. They also agreed that unrestricted autonomy was necessary with regard to product-level decisions.
• Maybe more so than even the other roles in the Scrum Framework, how Product Owners fulfill their roles is highly contextualized. Unger-Windeler and her colleagues (2019) also investigated what Product Owners do in many different organizations and concluded that “no Product Owner role is like another”.

My experience with Scrum teams is that the role of the Product Owner is both the most critical and the most difficult role to fulfill well just because the role is so contextual. Unless Product Ownership is shared within a team (see further down), even a great Scrum team will struggle when their Product Owner is unable to maximize the work done by the team.

We can take these findings in two ways. We can become more prescriptive and hammer on what is expected of Product Owners according to the Scrum Guide. Or we can take a more flexible approach. As Sverrisdottir, Ingason & Jonasson (2014) conclude: “the role of the product owner is a very difficult role. The reason is that success depends on so many factors; organizational culture, type of project, management approach, and last but not least, the interaction within the team that is developing the product”. However, the following insights offer evidence-based suggestions for Product Owners to focus on.

“Unless Product Ownership is shared within a team, even a great Scrum team will struggle when their Product Owner is unable to maximize the work done by the team.”

Insight #2: Eight Core Activities, Each Requiring Mandate

Julian Bass and his colleagues (2018) investigated which core activities Product Owners spent their time on in ten multinationals. They interviewed 55 practitioners and observed hundreds of Scrum events to categorize the activities that Product Owners spend their time on. They identified eight core activities:

1. Prioritizer: The selection and ordering of the Product Backlog so that the highest value is delivered first.
2. Groom: The breakdown and clarification of work on the Product Backlog, as well as their acceptance criteria. Note that Bass calls this “Groom” in reference to “Product Backlog Grooming”. The term has since been changed to “Refinement” because “Grooming” has negative connotations.
3. Release Master: The management and approval of plans to release new versions to stakeholders.
4. Communicator: The transfer of knowledge between different sites, as well as from and to the team.
5. Traveler: The process of building an understanding of stakeholders by visiting them and spending time with them.
6. Intermediary: Acting as an interface between management and the team and the process of disseminating domain knowledge.
7. Gatekeeper: Approving completed items for a release.
8. Customer Relationship Manager: Supporting stakeholders in their use of a product. This includes training, technical support, and preparation for new releases.

I suspect that most of these activities are not surprising for experienced Scrum practitioners. The last is perhaps the most surprising from the perspective of the Scrum framework, but less surprising when you consider that most Product Owners are probably obvious points of contact for stakeholders, also in the case of issues and support.

It's also interesting to consider what isn’t on the list. I would’ve expected more activities relating to product discovery, product vision, and other forward-looking activities. We will investigate this deeper under Insight #3, below.

This list of core activities is quite diverse. It is no surprise that the researchers conclude that “Product Owners perform a wide range of challenging activities which require experience and high-status in order to be able to exert influence”. More importantly, they conclude that each core activity requires “experience and high-status in order to be able to exert influence over other project stakeholders”.

“Product Owners perform a wide range of challenging activities which require experience and high-status in order to be able to exert influence.”

How to use these insights in practice

1. The core activities are helpful to reflect on your own practice as a Product Owner. In particular, it is useful to explore if you have indeed sufficient mandate in these areas. Otherwise, it will be difficult to be effective.
2. The Scrum Guide emphasizes that Product Owners can delegate tasks to the team. As we will discuss in more detail below, this is a great way to create a shared sense of product ownership. Which activities can be fulfilled by others in the team, and what is needed for that?

Insight #3: Product Discovery Is Missing?

One of the reviewers of this article, Maarten Dalmijn, noted that he missed “product discovery” as a core activity in the work by Bass (2018). Maarten, who is an experienced Product Owner, added that he spends a lot of time on this with his teams. This allows him and his team to better understand their product now and what it could become, and this makes it easier to order items on the Product Backlog, decline or accept items, and make tough decisions. I too missed product discovery, as well as other forward-looking activities. Most of the Product Owners interviewed by Bass were seemed more focused on managing the present than exploring the future of their product. Where does this discrepancy come from?

Data from our Scrum Team Survey may shed a light on this. Of all the product-related activities that Scrum teams spend their time on, “Product Discovery” and “Sprint Review Quality” score lowest, closely followed by “Stakeholder Collaboration”:

The size of teams or organizations does not particularly seem to matter, as results are lower both for small and large organizations. A pattern that may connect these lowest-scoring themes is the availability of stakeholders (e.g. customers, users, and internal stakeholders). Indeed, these themes also correlate more strongly with each other than with the other themes (between r = .55 and r = .66). This means that their scores tend to go together most of the time. We also know that product discovery impacts team effectiveness. Together with Daniel Russo, Ph.D., I analyzed 1.200 Scrum teams and found that teams that purposefully invest time in this activity (along with others) have more satisfied stakeholders and higher morale. So there is a measurable positive impact of these forward-looking activities.

This insight may reflect that the Scrum Guide indeed does not offer enough guidance on how to maximize the value of the product. The accountabilities listed there do feel more administrative than imaginative, even though the latter is emphasized in popular articles and books on Product Ownership. It makes me wonder how we can do better.

How to use these insights in practice

1. Because many Product Owners and their teams struggle with Product Discovery, we created two do-it-yourself workshops. One is free and the other costs a cup of coffee. Both workshops use Liberating Structures to engage with your stakeholders in highly interactive ways and tap into the wisdom of your crowd.
2. The Sprint Review is an excellent opportunity to engage in product discovery. Share working increments with stakeholders and let them actively try and suggest features. Although you may not be able to implement all requests, this is a great first step to more active product discovery.

Insight #4: Product Owners Are Communicators

Caroline Unger-Windeler and her colleagues (2019) explored existing studies about Product Owners and also observed Product Owners in a large organization themselves. A clear pattern from their research is that Product Owners are, first and foremost, communicators. Product Owners spend around 65% of their time in meetings and Scrum events, and during that time they interact with 15 different roles:

 

So what do they communicate about? Kristinsdottir, Larusdottir & Cajander (2017) followed and interviewed Product Owners at Spotify. They observed that Product Owners in this organization spend most of their communicating with stakeholders, with the team, and departments around the team. Much of this revolves around the product vision, strategy, and purpose of the work. This makes the Product Owner clearly a leadership role. But contrary to traditional views on leadership, Product Owners at Spotify facilitate rather than create the vision. The researchers quote one Product Owner as saying: “I get a very fluffy high-level overview but the team has very concrete details so I facilitate the vision but they provide most of it”.

“Contrary to traditional views on leadership, Product Owners may facilitate rather than create the vision.”

What is interesting about these findings is that they challenge the notion of the Product Owner as the person who brings a brilliant vision, strategy, and clear goals to the team, and then makes sure that the team does the right work — simply because they “own the product”. The Product Owners that were studied clearly take a more collaborative approach and treat their team as peers in the discovery process. Being a good Product Owner may be more about developing a shared sense of Product Ownership than simply setting clear goals. This connects well with our next insight.

How to use these insights in practice

• Scrum teams may find it valuable to explore with their Product Owner how vision, strategy, and purpose are communicated. Who communicates this more than others?
• The examples from Spotify show that Product Owners do not have to fit in the stereotypical mold of the “Product Owner as a visionary”. As the Product Owners who reviewed this post also noted; “you are more effective when you create a vision, strategy, and purpose together — rather than on your own”.

Insight #5: Product Ownership May Be More Important Than Product Owners

Who is responsible for maximizing the value of the product? The Scrum Guide assigns this responsibility to one person; the Product Owner. They are responsible for setting priorities, defining goals, and clarifying which work needs to be done. How these responsibilities are put into practice varies greatly between Product Owners. But it seems clear that it certainly isn’t effective when Product Owners keep this work strictly to themselves and don’t involve the team.

Judy & Krumin-Beens (2008) offer an interesting perspective on this in a case study. They distinguish between “bounded” and “unbounded collaboration”. In the first case, Product Owners don’t engage developers in understanding the business outcomes of their work. In the second case, Product Owners actively involve developers in understanding business outcomes and developing strategies to achieve them. Bounded collaboration can be the result of deeply held beliefs (i.e. “technical staff doesn’t need to know”). It can come from good intentions, such as a Product Owner who doesn’t want to burden already stressed-out developers. But despite those good intentions, research does suggest that unbounded collaboration — or collective Product Ownership — is more effective. Judy & Krumins-Beens (2008) define collective Product Ownership as: “the development team is passionate about the product they are building, connected to business goals and empathetic to their end-users. They feel on the hook if the product does not succeed”.

We see this pattern too in the data from the Scrum Team Survey. Together with Daniel Russo, Ph.D., I analyzed data from 1.200 Scrum Teams (Verwijs & Russo, 2021) and found that Scrum teams are more effective when there is a shared concern for the needs of stakeholders in the team. We asked team members to rate questions like “Members of this team frequently meet with users or customers of what this team creates”, “Everyone in this team is familiar with the vision for the product” and “This team often explores what would make the product more valuable for users”. We found that teams that score high on such questions are also more effective in terms of stakeholder satisfaction and team morale.

Together, this evidence supports the idea of shared Product Ownership. A Product Owner does well not to keep their cards close to their chests. A collaborative approach — where the team is fully involved with decisions, strategizing, and prioritizing — seems to be more effective.

How to use these insights in practice

• If you’re struggling where to start with shared Product Ownership, you may want to explore our do-it-yourself workshops for Product Owners.

Conclusions

The studies we discussed in this post all conclude that every Product Owner is different. Despite the concise description in the Scrum framework, what makes a good Product Owner seems even more dependent on the context than the other roles. As a professional community, we should emphasize that diversity in our opinions about what makes a good Product Owner. Silver bullets and one-size-fits-all solutions are certainly not helpful.

The second conclusion is that Product Owners are leaders, but not in a traditional sense where they set the goals. Rather, good Product Owners are highly collaborative in their approach and work with their team to clarify the vision, purpose, and strategy for their product — to develop a shared sense of ownership. This is clearly different from the notion of the Product Owner as “the requirements writer” or “the product architect”. Organizations are well-advised to emphasize facilitative (soft) skills for Product Owners over technical, directive skills.

“I wonder if the Scrum Guide sufficiently captures these scientific insights in how it describes the role. Is it really helpful to talk about a “Product Owner” when shared Product Ownership seems more fruitful in practice?”

Finally, I wonder if the Scrum Guide sufficiently captures these scientific insights in how it describes the role. Is it really helpful to talk about a “Product Owner” when shared Product Ownership seems fruitful in practice? The way in which the accountabilities are described also suggests that it is the Product Owner who performs them (e.g. “Developing and explicitly communicating the Product Goal” or “Creating and clearly communicating Product Backlog items”). Does the current Scrum Guide offer enough direction for Product Owners on how to develop shared Product Ownership, and thereby motivate and empower teams to maximize the value of their work?

A big thanks to Justyna Pindel, Maryse Meinen, and Maarten Dalmijn for bringing their own experiences as Product Owners in while reviewing this article. 

 

References

Academic publishers unfortunately publish most academic work behind paywalls. So I am unable to share the papers here. Some original Pdfs can be Googled. Or you can try https://sci-hub.se, which I’ve heard can work really well.

• Bass, J. M., Beecham, S., Noll, J., & Razzak, M. A. (2016). All Hands to the Pumps: The Product Owner Role in Small Companies Lero Technical Report: 2017.
• Bass, J. M., Beecham, S., Razzak, M. A., Canna, C. N., & Noll, J. (2018, May). An empirical study of the product owner role in scrum. In Proceedings of the 40th International Conference on Software Engineering: Companion Proceedings (pp. 123–124).
• Kristinsdottir, S., Larusdottir, M., & Cajander, Å. (2016). Responsibilities and challenges of product owners at spotify-an exploratory case study. In Human-Centered and Error-Resilient Systems Development (pp. 3–16). Springer, Cham.
• Judy, K. H., & Krumins-Beens, I. (2008, January). Great scrums need great product owners: Unbounded collaboration and collective product ownership. In Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008) (pp. 462–462). IEEE.
• Sverrisdottir, H. S., Ingason, H. T., & Jonasson, H. I. (2014). The role of the product owner in scrum-comparison between theory and practices. Procedia-Social and Behavioral Sciences, 119, 257–267.
• Unger‐Windeler, C., Klünder, J. A. C., Reuscher, T., & Schneider, K. (2021). Are Product Owners communicators? A multi‐method research approach to provide a more comprehensive picture of Product Owners in practice. Journal of Software: Evolution and Process, 33(1), e2311.
• Van Waardenburg, G., & Van Vliet, H. (2013). When agile meets the enterprise. Information and software technology, 55(12), 2154–2171.
• Verwijs, C., & Russo, D. (2021). A Theory of Scrum Team Effectiveness. arXiv preprint arXiv:2105.12439.

Limitations of the studies

All scientific studies have limitations and it is good to be aware of them. The studies we discussed in this post are almost exclusively based on case studies where researchers interviewed a handful of Product Owners. Case studies are a great way to understand what Product Owners do in practice. But it is hard to generalize those findings to all Product Owners. I tried to alleviate that limitation by looking for patterns across case studies.

There is unfortunately a lack of quantitative research in this field. I have been unable to find studies that use large samples of Product Owners to draw firmer conclusions across cases. Perhaps we can open our work environments more to academics to perform such research with us?

It is also important to note that most of the studies I was able to find have been published in fairly low-impact academic journals. High-impact journals generally have a higher bar for quality and a more rigorous peer-review process. This does not mean that the studies included here are of low quality, but the impact rating of a journal is an (imperfect) indicator of quality.