Keywords

1 Introduction

Traditional project management approaches for software development, like the waterfall approach, have been challenged by Agile approaches in recent years [2]. Agile is an umbrella term for project management approaches such as Scrum, XP, and Kanban [21], where Scrum is the most widely adopted Agile approach [25].

Scrum is an approach with a few ceremonies, roles and artefacts. The roles are called: Product Owner (PO), Scrum Master (SM) and Team Member (TM) [20]. Management responsibilities are divided among these three roles [19]. Pichler describes the PO role as a new, multi-faced role that unites authority and responsibility that traditionally, in the traditional processes was scattered across separate roles such as customer, product manager and project manager [15]. Hence, when using Agile approaches the PO role in some aspects replaces the role of various stakeholders. The PO has the authority to set goals and shape the vision of a product and therefore the PO has other responsibilities than the project manager that mainly writes requirements and does prioritization for the team [15]. For example, the POs in Scrum projects in Iceland had various responsibilities [23]. The proportion of the POs time collaborating with the team varied from 5 % to 70 % of their total working time. Furthermore, the POs used from 10 % to 50 % of their working time collaborating with customers, users and other stakeholders [23].

The Product Owner role has not had much focus in academic research; the main focus has been on productivity, teamwork and collaborative decision-making in Agile teams rather than studying specific Agile roles. Additionally, more attention has been on examining factors that drive organizations to initially adopt Agile approaches than on those that affect their continued usage [16]. Still, the use of Agile approaches is constantly increasing in software development [3, 25], thus the Product Owner role is interesting and important since this role is often the link between business and development departments of an organization. One of the fundamental principles of Agile approaches is to aim at satisfying the customers by producing valuable pieces of the final product early in the development lifecycle [14].

This paper is an exploratory case study conducted at the software development company Spotify at the end of February 2014. It is a description of the PO role at this point in time and the main focus of the research is to study how POs identify customers for their teams, how they measure value of their teams’ work, how they form vision and communicate that to their teams, what their challenges are and how they deal with those.

The research questions in this study are:

  1. 1.

    What are the main responsibilities of the Product Owners? Particularly:

    1. (a)

      How do Product Owners identify customers for their teams?

    2. (b)

      How do they measure the value of their teams’ work?

    3. (c)

      How do they form the product vision for their teams?

  2. 2.

    What are the challenges of a Product Owner, and how does he or she cope with them?

The structure of the paper is that first we describe some of the background literature on Agile approaches and Scrum. We particularly describe the definitions of the POs role. Then we describe the data gathering methods used in the study, followed by a section describing the results. Finally we discuss the findings and give concluding remarks.

2 Background

This section describes Agile approaches and Scrum, the teamwork of Agile teams and the PO role.

2.1 Agile Approaches and Scrum

The origin of Agile project management (Agile) was first described in a paper by Takeuchi and Nonaka in 1986 [24], but Agile as a methodology gained attraction when Sutherland and Schwaber [22] discussed the first Agile process (also called Agile approach) for software development in the 1995 OOPSLA conference. They had analysed common software development processes and found that traditional development approaches were not suitable for empirical, unpredictable and non-repeatable processes such as development of software. The fundamental values and principles behind Agile are described in the Agile manifesto [1].

Six obstacles in decision making in Agile have been analysed, which are: (a) unwillingness to commit to decisions; (b) conflicting priorities; (c) unstable resource availability; and lack of: (d) implementation; (e) ownership; (f) empowerment [6]. The effect of these obstacles is a lack of longer term, strategic focus for decisions, an ever-growing list of delayed work from previous iterations, and a lack of team engagement.

In Scrum, the most common Agile process [25], the projects should be split up into two to four week long iterations called sprints, each aiming to end up with a potentially shippable product. In Scrum, self-organizing and strongly united teams are heavily emphasized, typically with six to eight interdisciplinary team members. One of the benefits of using Agile was claimed to be that customers’ needs are taken more into account than when developing software using sequential processes [18]. The Scrum team is self-organising and works independently during the sprints. Daily Scrum meetings are prescribed where the Scrum team meets and plans the work during the day, and where the tasks are distributed in the group. The work in the Scrum team should be guided by collaboration and communication. Demos of the outcome are made at the end of every sprint. Agile teams should have a common focus, mutual trust and the ability to reorganize repeatedly to meet new challenges. IT professionals appreciate the inherent values in Scrum, which are speed and communication internal to the Scrum team. Also, working in teams and focusing on a small number of tasks at a time is valued. The main challenges are that including specialists in the teams is hard and Scrum does not always match with external requirements for the organizations [13].

Being self-organised does not mean leaderless, uncontrolled teams but that the leadership is meant to be light-touch and adaptive, providing feedback and subtle direction. Leaders of Agile teams are responsible for setting direction, aligning people, obtaining resources and motivating the team [9]. The leader can be anyone with influence or authority over the team and can include managers, POs and the SM [4]. In the next subsection, definitions of the responsibilities of POs are described.

2.2 Definitions of the POs Role

Schwaber [19; pp. 6–7] defines the PO role as follows:

“The Product Owner is responsible for representing the interests of everyone with a stake in the project and its resulting system. The Product Owner achieves initial and ongoing funding for the project by creating the project’s initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog. The Product Owner is responsible for using the Product Backlog to ensure the most valuable functionality is produced first and built upon; this is achieved by frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration.”

Both the developing team and the people driving the business need to collaborate to develop the final required product [14]. The PO is the link between the customer and the user side of an organization and the development team. The team and the PO should constantly collaborate and plan together how to produce the most value for the business [19]. The primary duties of the POs are making sure that all team members are pursuing a common vision for the project, establishing priorities so that the highest-valued functionality is always being worked on and making decisions that lead to a good return on the investment in the project or for the product [5, 11]. The responsibility of the PO is to prioritize the work to be done by the team, but he or she should not be involved with how the team does their work [10]. In commercial software development, the PO is often someone from the marketing or production management side of an organization [5].

Picher describes that the PO should lead the development team to create a product that generates the desired benefits for the customer and the user [15]. This includes creating the product vision, prioritizing the product backlog, planning the releases, involving stakeholders, managing the budget, preparing the product launch, attending meetings, collaborating with the team and many other tasks.

Cohn [5] states that the PO role is challenging because the PO needs to address both inward and outward facing needs simultaneously. The inward facing responsibilities being participating in daily stand-up meetings, reviews, retrospectives as well as management meetings, managing the product backlog, answering questions from the team and being available to the team as much as possible. Outward facing responsibilities are to attend to user’s needs, manage stakeholder expectations, prioritize the product backlog and develop a product strategy and vision. Furthermore Cohn [5] states that the PO should provide just enough boundaries for the project so that the team is motivated to solve the difficult problems but not providing so many boundaries that solving the problems becomes impossible. In that way the role is more of an art than science.

Galen [8] states that the PO role is the most difficult one within the Agile or Scrum team. A PO needs to be a highly skilled individual who understands the nuances of the role and is enabled by the organization to take the time necessary to fully engage the teams in value-based delivery. A skilled PO is a member of his team and should consider the team as his or her primary customer. PO is a distinct member of the team in which overall success or failure is a joint endeavour. The PO needs to give the team the right things to do and make sure they do everything possible to qualify the work [8]. The PO role can be difficult to staff with a single individual because the competences are so broad and intimidating that it is hard to find an individual having all these skills [8].

In summary, Cohn, Galen and Pichler describe four aspects of the PO role, which are: involving customers, focusing on value, creating a vision and that it is a challenging role. Schwaber has a bit more focused definition, emphasising customer involvement and value of the product as the main aspects. We therefore analyse the results according to four themes in the paper: (1) customer involvement, (2) focusing on value, (3) making a vision and (4) challenges of the PO role.

3 Method

Little research exists on the Product Owner role, and this study is exploratory in nature and examines the role of Product Owners. The research is a qualitative case study conducted at Spotify at the end of February 2014. This study was first presented as a master thesis study and has been rewritten for the purpose of this publication.

3.1 Context of the Study and Participants

Spotify was founded in 2006 in Sweden and in 2008 they released their core product, a music player named Spotify that can be used online or downloaded as an app on desktop or mobile. Its users have access to one of the fastest growing catalogues of licensed music in the world [17]. It has grown tremendously since it was founded, has a good track record of product delivery and its products are loved by users and artists [12] Active users are growing fast, they were over 20 million at the beginning of 2013 and paying subscribers around 5 million [12]. At the time of this case study Spotify’s employees were around 1.000 with software development taking place in three locations: Stockholm, Gothenburg and New York.

Spotify has used Agile approaches in one form or another since it was founded in 2006. Their teams, which are called squads, used Scrum in the past but when they started delivering all tasks ahead of the end of each three-week sprint they decided that each team could be completely autonomous in the way they work. Some teams use Scrum today but that is a minority of all the development teams. Most of the teams use Kanban or some form of that. But each team still has a Product Owner and a Scrum Master. At the time of the study, the product that was being developed was quite mature. The Agile teams had been working on the product for years, and their way of working had matured a lot, since the company was established.

As this is a case study the participants were selected in consultation with a professional from Spotify. The participants were spread across the organization to insure that they did not have the same background and were working in different projects and with different parts of the product.

Five interviews were conducted. Three Product Owners were interviewed, one director of Product Development, that was previously a Product Owner and one Scrum Master, called Agile Coach at Spotify, to receive a better view on the Product Owner role and his challenges. One of the Product Owners also had the role of an Agile Coach at the time of the interview. The participants had various backgrounds; most of them started as developers but had changed roles, two participants said it was because they like to speak their opinion on the way things are done so they were asked to take the Product Owner role on a team. The participants all had a good understanding of agile processes and the business of Spotify.

The others happened to take on this role when the teams were set up according to Scrum. The Product Owners work in different parts of the organization, which might explain differences in their opinions.

3.2 Research Method

Case studies are the preferred method when how or why questions are being posed, when the investigator has little control over events and the focus is on a contemporary phenomenon within a real-life context [26]. The case study method allows the investigator to retain the holistic and meaningful characteristics of real-live events, such as organizational and managerial processes.

As one of the researchers had the chance of conducting a research of the Product Owner role at Spotify’s headquarters in Stockholm this research method was chosen. Knowledge gained from this study is transferable to other settings through the interpretations of the reader.

In this exploratory case study we have used a mixed methods approach. The primary data collection method was in-depth, face-to-face semi-structured interviews with five employees at Spotify. The first step in data gathering was to prepare the interview protocol and pilot test it prior to the study. After the pilot test there were minor changes to the protocol. The protocol had: 7 questions on the background and experience of the participants, 2 questions on the stakeholder focus, 2 questions focusing on value, 3 questions on the vision, 5 questions on teamwork, 4 questions on the challenges for POs and 9 questions on the PO role in general.

The interviews were audio-recorded with the permission of the participants and then transcribed verbatim. Their length was between 50–65 min. The quotations in the results chapter are not always verbatim but slightly rephrased to be more readable.

Observation on site were also made through shadowing a Product Owner for a day to observe his daily role. The shadowing included being present in all meetings the Product Owner had that day: stand-up meetings with his teams, one-on-one meetings with his team members and managerial meetings. Additionally informal conversation was performed people in various roles around the organization.

Source data hence included field notes from the observations, transcripts from the interviews, documents and photographs taken at site. The researcher spent three days at Spotify finishing each day by documenting the observations as field notes and then used the next day to seek clarification and gather more data.

3.3 Analysis of the Data

In the analysis we identified and coded the results into the four themes: (1) customer involvement, (2) focusing on value, (3) making a vision and (4) challenges of the PO role. When analysing customer involvement, both statements about the customers (the person paying) and end users (the person using the software) are analysed, since the users for the Spotify service are also customers.

The source documents were grouped by each participant and then analysed by the use of the themes according the theme analysis [7]. Conclusions were finally drawn from the data collected. Emphasis was put on understanding the participants’ lived experiences in the Product Owner role and their different views. In order to answer the research questions, the transcripts and field notes were read several times to obtain insight into each case.

4 Results

In this section the research results are divided into two sections, the first subsection presents results from the interviews when it comes to the POs experience of the three responsibilities. The second subsection presents the challenges the POs described that they have had in practice.

4.1 Responsibilities of the Product Owners

In this subsection the Product Owners experiences regarding the three responsibilities that are connected to their role in literature are described: (1) customer involvement, (2) focusing on value and (3) making a vision.

4.1.1 Customer Involvement

The Product Owners that participated in the research worked with different kinds of teams, those that develop new features and those that work on infrastructure or measurements that other teams then use to build their features on. The Product Owners did agree that the teams should know who their customer is but they did not all find it their responsibility to identify those customers and their needs and communicate those needs to their team so that the teams are working on the most valuable tasks for the customer at any given time. Some felt strongly about it being their responsibility while others found it to be a team effort and not even something they should think about in their role. Some said that the PO should make sure that discussing the customer needs should take place within their team. Some of the Product Owners also tried to bring end user focus to their teams by pointing out that even though their team was working on a platform for an internal customer the team members still have to think of the end users as their customers.

As one participant said: “We [Product Owners] should represent the customers’ interest, we are here to deliver something that users want to use and will love. Our success should ultimately be customers who love the product.” But another one said: “I would say that both the Product Owner and the team have an input on what the users want, it might not be only the Product Owners responsibility to communicate that to the team but he should be the one seeing to that we know what are the customers’ needs.” One participant said that in a very broad sense this was his responsibility and in his daily work he talked to many people in the organization to find out where there are needs for his team to come in and work for other teams.

Some of the Product Owners mentioned customer services as being their main connection to the end user. They felt that if the users are not happy with the software or the changes the teams are doing to it they should see that in the number of complaints from users and ultimately the number of users and take action if they were going down. Spotify’s success should therefore be judged by numbers of users, if the numbers are going up the users are satisfied and vice versa: “Internally I play the devil’s advocate; I try to empathize with the users and make clear to the team that everyone depends on us by asking questions like: If we brake something who will that affect?”

One Product Owner mentioned that his team tried to write user stories to understand their user’s situation and figure out what their needs are. He believed that it is his responsibility to make the team focus on why the program or system is working on this specific task rather than another one but he said it can be a challenges as there are developers who are happy to continue writing software and not ship anything to the end user. He would like his developers to think of the end user and launch the software out to them as soon as possible: “For me the heart of agility is getting software to users and learning from them, listening to them and getting feedback fast and that’s all there is to it.”

4.1.2 Focusing on Value

Most of the Product Owners found it difficult to measure the value of the work their team was doing because often there was no transaction of money taking place. They tried to use measurements but the teams themselves did not always control those as they are mostly working for internal customers so it was hard to figure out what of the actual end value is generated from each team. As one Product Owner put it: “We see very little money here as Product Owners, it is strange but I don’t concern myself with money at all actually.”

Spotify tracks global user satisfaction usage for changes of the software but as the iterative changes to the software are so incremental it is difficult for the user to see them or know about them. So the Product Owners use the number of users as their main parameter of success. Then they try to build a dependency chain on metrics and work with hypothesis, for example if Spotify has more music they have more users, if users collect more music they will play more music, if users are able to find music easily they will collect more music and so on.

One participant said that it should be up to the team to deliver return on investment, not the Product Owner. He or she should just be the contact point for other parts of the organization to make it a bit easier for the team to work uninterrupted but in the best of teams the Product Owner is just another team member and the team as a whole sets the goals that then bring value to the organization. If the Product Owner tries to do it by himself chances are that the team will not buy into the goals: “You can usually see when the team has set the goals as a whole rather than the goals being delivered from someone else.”

One participant said that his team did not measure return on investment in any way but verbal feedback from his internal customer was what he focuses on. His gut feeling was therefore his main form of measurement.

4.1.3 Making a Vision

When the participants were asked if they lead the vision of the product development for their teams most of them agreed that it was a difficult responsibility that they struggled with. One participant said: “I think it’s important that the Product Owners sees to that the team has a vision, that they know what it is, but I don’t think it is solely the Product Owner who creates that vision, I think that the team does that together but the Product Owner is responsible for that they have it”.

The Product Owners do not always know what that vision is as the organization has been growing fast and the vision of a team tends to change relatively quickly: “Speaking completely openly it is something we are struggling with, this question of the vision and sharing it with the other teams because we are big and distributed. So how do you share that vision? I think we overcomplicate it at the moment and I think we just need an objective and should focus less on measurements.”

Each team is encouraged to come up with five measureable goals each quarter, but one of the participants said that he does not like that because he thinks that often metrics are gamed, especially if they come from the top down. He would rather have a vision set at the top and then trust the teams and let them prove to the organization that what they are doing is moving the whole organization in the right direction. Another participant agreed on this, the Product Owner should provide a vision but said that somebody had to provide them with the organizational vision so that he is able to do that, the Product Owner cannot come up with the vision on his own.

One participant said that he would like to think that he facilitates the visionary activities for his team. But he said that his team has a much better insight into the needs of the customers as the team is working much closer with them than he is. He does trust his team to have much input on the vision of the development: “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.”

Another participant said he had a clear vision of how his product should be developed but the organization as a whole did not have a shared vision for the end product. He said his team starts to converge of this unspoken vision every two or three months so they sit down and take a conversation about it but they never write it down, their world is changing so fast that they do not want to put it in a document that is obsolete in a few weeks. Another participant involves others in the visioning activities but then he communicates the vision: “High-level vision for the company takes place in broad hall meetings. That’s for the entire company and then I translate that into the reasons why we are doing the things we are doing now.”

One participant said that his team works a bit with story mapping to try to figure out what the big items for the future could be but as their goals changes so quickly it is extremely hard to work on a long-term basis: “The longest project I’ve seen so far has been about a year. And the business landscaped has typically changed so much over time that at the end the product might not be quite right, good examples are the download store and the iPod integration which were a good idea at the time but when they were finally released it wasn’t anymore. Over all we change the goals, what we prioritize, so often that it’s hard to have a longer term vision.”

4.2 Challenges of the PO Role

Part of this study was to gather information on the challenges a Product Owner faces at Spotify.

One participant described the role as a combination of a diplomat adviser and juggler because there are a lot of voices with different needs and the Product Owner needs to communicate with all of them. The best way to do this was to be transparent so people see for themselves why things are done this way and not the other: “Be transparent because you are not going to please everyone all the time. As long as you are transparent about how you are doing things, how you make decisions and why certain things need to be prioritized over other things you will succeed.”

It is the most challenging role on the team, said one participant, because there is ultimately more responsibility in the Product Owner role than in other roles in the team: “You have all those people wanting things from your team and for everyone what they want is very important and that is the diplomat part of the role. The team should be exposed to this pressure to an extent but the Product Owner should also protect the team from that. The developers need to know that they are not working in a vacuum, there are people who really care about what they are delivering but the Product Owner is also protecting them which makes it a more challenging role.“

One participant said that the Product Owner role is challenging because even though the team is responsible for their delivery the Product Owner is in the forefront of that, the one seeing to that the delivery happens and it is compatible to what was initially planned: “I think that is a tough thing to have on your shoulders.”

Being a Product Owner also means to align other people so that everyone has the information they need to do the right job at every given moment: “It’s all about alignment and knowing what others are doing, you should not be working in isolation, it’s very hard to do the right thing if you don’t know what others are doing so the Product Owners are the ones who just make sure that we don’t deviate on our own into what we think it is we should be doing.”

Every Product Owner found it extremely important to spend time with the team every day, as much as they physically could to but some struggled with that as they worked with more than one team and had to attend to various meetings. Teamwork and collaborative decision making seem to play a crucial role in the work the Product Owner does with their team. The Product Owner is often guided by the team in what is technically right, so he has to listen to the team and take their advice on how things should best be done: “I’m there to represent the teams interest, fight their corner and to make their case. Just this week we said we’re not going to make a release because the quality is not there yet. That message comes from me to the stakeholders but it is informed and guided by the voices of the team.”

The challenge is also that the Product Owner has to be an indirect leader of the team, he has some authority to make decisions for the team but he very rarely wants to act on that authority and be the only one making decisions that affect the whole team and their work: “Product Owners are indirect leaders and many of them are totally inexperienced when it comes to leading someone. Especially if it’s a junior team, so that is a big challenge for a lot of the Product Owners.” The Product Owner has to get people excited and aligned so that they know what is expected of them without actually telling them: “The Product Owner is supposed to lead the team, engage and inspire it, make sure that things are moving forward but it is very artificial to have just one person that does that, the team itself needs to be interested in these kind of topics and discussions.” And the challenge is also to see what is missing and add that to the mix: “I think the Product Owner role involves picking up the slack, so if something isn’t working then it’s clearly your Product Owners fault. Anything that is missing you’ll have to pitch in.”

Most of the Product Owners talked about the stakeholder side as being one of the most challenging parts of their role. It is difficult to motivate a team that does not know for whom it is working and lacks a purpose: “I think the special challenge is that we are not very often doing particularly exciting or glamorous parts of the development, we’re providing a platform and keeping developers motivated around that is a particular challenge here. And focusing on the user value and remembering that we’ve not just got internal customers, we’ve got users as well.” One participant said that his biggest challenge was to sell his vision of the development to the developers on his team: “The challenge is not only to sell the product to the end users but to sell the work that the team needs to do to the team. Both are important but if I have to order them it’s selling the work to the engineers that is more important.” Part of the role is to trust the team to do their job and leave them to do just that: “Part of our role is actually to back off, let people try things and trust them to do something interesting.”

Communication was also mentioned as being one of the Product Owners’ main challenge: “When the Product Owner is good at communication I see the teams do a really good job and when the Product Owner isn’t good at communication the teams seem to struggle with what they should be working on.” And it’s not enough that the Product Owner is a communicative person but he also has to make other people speak to each other and see the big picture instead of focusing on their own task: “The more people talk to each other the more they realize that teamwork is important and they get more humble as they know what others are doing instead of getting stuck in their own corner of the universe.”

All participants mentioned that they have come a long way and now find the role a bit easier than when taking the role. The challenges were often the same but in different situations and they feel they can use previous experience to handle them.

5 Discussion

The results show that all the participants are well aware of the responsibilities that are described in literature [5, 8, 15, 19] and all of them attend those in some way or another, although they have different approaches in their daily work to fulfil them. As described by both Cohn [5] and Pichler [15] the role is multi-faced, inward and outward facing and challenging. The results in this study show this quite clearly. Some respondents commented that they needed to have one foot in the daily work and one foot in the future and lead people to work on the right things at any given moment. Since Spotify has been growing during the past years it might be that the POs have had to focus more on their inward facing responsibilities as Cohn [5] describes them, dealing with their own team on daily basis to make sure they are functional. The results indicate that when these challenges have been met the POs can look ahead to the future and start to focus on customer involvement, the vision of the product and the value their team is delivering as these are among the outward facing needs [5].

At Spotify the role of the PO varies from one person to another. One aspect is that the POs have a very communicative role and the individuals in the PO role have different communication competences. An additional aspect is that the responsibilities of the POs are not necessarily the same in one part of the organization compared to another part of it.

The participants agreed that the PO role is often complicated and diverse and in some ways it can be hard to describe what the actual daily work is and should be. There are many tasks to juggle each day and the POs often felt that they were not delivering any visible work to the team or the organization.

The biggest risk for Spotify is building the wrong product, meaning that the product does not delight users or does not improve success metrics such as user acquisition or user retention [12]. This is what is called “product risk” at Spotify. To compensate for this, the POs make sure that the customers (end users) are represented when the teams plan their work. Within the teams that build infrastructure or internal tools, there seems to be a lack of understanding of whether the concept customer includes the end user or not, that is if the teams should be focusing on the system from the users point of view or focusing on the customer, which ofter are internal managers at Spotify or other teams they are developing for. The end user is not always in the developers’ mind when they are developing for infrastructure or measurement, we could say that the end user is somewhat invisible. There were examples of teams not knowing who their primary customer is. Helping the POs to identify their teams’ customers would give the teams a better vision for the reason for why they are doing what they are doing and hopefully empower team members and make them more involved in defining the vision for the product. As the organization has different teams working for each other and a few are developing directly for the end user, the visionary activities are blurred. There are indications that strategic work is strong for the organization as a whole but that does not seem to help the POs with their vision for their specific product development and the communication of that to their teams.

As Cohn [5] states the PO should establish priorities so that the highest-valued functionality is always being worked on to maximise return on investment. The POs did not think about the value of the tasks their teams are working on and did not prioritize them according to return on investment, mainly because they don’t have the right tools to measure the value of every task. It is also difficult to put a price on something you don’t know how much effort is needed to finish.

Leading visioning activities for the product and communicate that to the team like both Cohn [5] and Pichler [15] describe as one of the main responsibilities of the POs is what the POs all struggle with. It is difficult for the teams to focus on the big picture when they work on a limited amount of tasks each time.

This case study has contributed to the software development and project management literature by examining the PO role at Spotify. This is a complex role with both inward and outward facing responsibilities. Studying POs for three days might not give a generalizable picture of their duties, but the study gives an understanding of the POs responsibilities and challenges. The findings are interesting in regards to how the POs describe the complexity of the role, how it is much more of a leadership role than a manager role and how communication and people skills are crucial to the competences of a PO. The PO has to work closely with the team and as soon as the team feels that they don’t have a clear vision of where they are going they start to drift of and become dysfunctional.

6 Conclusion

It seems that the PO role is as diverse in practice as the literature describes it and the challenges a PO faces each day are many as the results indicate. The POs need to have one foot in the daily work and one foot in the future and lead people to work on the right things at any given moment. The POs do not want to use their authority to make decisions for the team but they want everyone to be involved in the work and in that way the team should be able more productive and develop valuable products.

The PO is not a person who knows it all, as one participant put it: “I don’t think the Product Owner is a magical person who has all the answers. You can give a steer on priority, you can help make sure we are focusing on customer value but you don’t have all the answers.”

In practice, the PO role seems to be much more of a leadership role than literature has indicated so far and it would be interesting to research the role in relation to the academic literature on leadership. The main challenge of the PO might therefore be to inspire and encourage team members communicate openly. If the team members are empowered and interested in their work the challenges seem to become much easier.