# Responsibilities and Challenges of Product Owners at Spotify - An Exploratory Case Study

Sigurhanna Kristinsdottir, Marta Larusdottir, Åsa Cajander

► To cite this version:

Sigurhanna Kristinsdottir, Marta Larusdottir, Åsa Cajander. Responsibilities and Challenges of Product Owners at Spotify - An Exploratory Case Study. 6th International Conference on Human-Centred Software Engineering (HCSE) / 8th International Conference on Human Error, Safety, and System Development (HESSD), Aug 2016, Stockholm, Sweden. pp.3-16, 10.1007/978-3-319-44902-9_1. hal-01647723

HAL Id: hal-01647723

https://inria.hal.science/hal-01647723

Submitted on 24 Nov 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Responsibilities and Challenges of Product Owners at Spotify - An Exploratory Case Study

Sigurhanna Kristinsdottir, Marta Larusdottir and Åsa Cajander

1) Kolibri, Iceland, sigurhanna@gmail.com

2) Reykjavik University, Iceland, marta@ru.is

3) Uppsala University, Sweden, asa.cajander@it.uu.se

**Abstract.** In Scrum, the Product Owner (PO) role is crucial for the team to be successful in developing useful and usable software. The PO has many responsibilities and challenges, including being the link between customers, other stakeholders and their development teams. This exploratory case study conducted at the software development company Spotify focuses on POs three responsibilities: a) Identification of customers, b) Estimation of value of their teams' work and c) Forming a vision for the product. Additionally, challenges perceived by the POs are studied. Data was gathered through five interviews and on site observations. Results show that the POs activities are divided between daily work, such as making sure that their teams are functional and long-term activities such as making a vision for the product. The main challenge of the POs is to inspire and encourage team members to collaborate and communicate within the team and with stakeholders.

**Keywords:** Project Management, Product Management, Agile, Agile Methods, Scrum, Product Owner (PO), Software Development

## 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 ap-
proaches the PO role in some aspects replaces the role of various stake-
holders. 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. Further-
more, 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 de-
cision-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 con-
stantly 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 de-
velopment company Spotify at the end of February 2014. It is a descrip-
tion 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. What are the main responsibilities of the Product Owners? Particularly:

a) How do Product Owners identify customers for their teams?

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

c) How do they form the product vision for their teams?

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 back-
ground literature on Agile approaches and Scrum. We particularly de-
scribe the definitions of the POs role. Then we describe the data gather-
ing methods used in the study, followed by a section describing the re-
sults. 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 distrib-
uted in the group. The work in the Scrum team should be guided by col-
laboration 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 subsec-
tion, definitions of the responsibilities of POs are described.

## 2.2 Definitions of the POs Role

Schwaber [19; p. 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 devel-
opment 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
minutes. 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 meet-
ings 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, tran-
scripts from the interviews, documents and photographs taken at site.
The researcher spent three days at Spotify finishing each day by docu-
menting 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 an-
alysed by the use of the themes according the theme analysis [7]. Con-
clusions 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 differ-
ent 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 some-
thing 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 cus-
tomers' 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 invest-
ment in any way but verbal feedback from his internal customer was
what he focuses on. His gut feeling was therefore his main form of meas-
urement.

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 often 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.

# 7 Acknowledgement

The authors would like to thank the participants and people at Spotify for the opportunity to do this research at their offices in Stockholm. Special thanks to Anders Ivarson who helped with arrangements and gave valuable comments on a draft of a thesis that this paper is based on.

# 8 References

1. Beck, K. et, al., (2001). *The Agile Manifesto*. Retrieved January 13, 2014 from: http://www.Agilealliance.org/the-alliance/the-Agile-manifesto/

2. Cervone, H. F. (2010). *Understanding Agile Project Management Methods using Scrum*. *Managing Digital Libraries: the view from 30,000 feet*. OCLC systems & services, 27 (1), 18-22.

3. Cooper, R. G. (2014). *What's Next? Research Technology Management, Jan/Feb 2014: 20-31.*

4. Cohn, M. (2010a). *Agile estimating and planning*. Upper Saddle River, NJ: Prentice Hall.

5. Cohn, M. (2010b). *Succeeding with Agile: Software development using Scrum* (Addison-Wesley Signature Series). Upper Saddle River, NJ: Addison-Wesley, Pearson Education Inc.
6. Drury, M., Conboy, K. & Power, K. (2012). *Obstacles to decision making in Agile Software development teams*. The Journal of Systems and Software, 85, 1239-1254.

7. Ezzy, D. (2002). Qualitative analysis: Practice and innovation, Psychology Press, (2002).

8. Galen, R. (2013). *SCRUM Product Ownership: Balancing Value from the Inside Out* (2nd ed.). Cary, NC: RGCG, LLC.

9. Hoda, R., Noble, J. & Marshall, S. (2011). *The impact of inadequate customer collaboration on self-organizing Agile teams*. Information and Software Technology, 53, 521-534.

10. Ivarsson, A. & Kniberg, H. (2012). *Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds*. Retrieved January 13, 2014 from: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf

11. Kniberg, H. (2007). *Scrum and XP from the Trenches: How we do scrum*. Retrieved January 7, 2014 from http://infoq.com/minibooks/ scrum-xp- from-the-trenches

12. Kniberg, H. (2013). *How Spotify Builds Products*. Retrieved January 13, 2014 from: http://dl.dropboxusercontent.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf

13. Larusdottir, M. K., Cajander, A., Erlingsdottir, G., Lind, T., Gulliksen, J. (2016): *Challenges from Integrating Usability Activities in Scrum - Why is Scrum so Fashionable?* in Cockton, G., Larusdottir, M.K., Gregory, P. and Cajander, A, (Eds.) in Integrating User Centred Design in Agile Development, Springer London.

14. Misra, S. (2011). *Agile Software Development Practices: Evaluation, Principles, and Criticism*. International Journal of Quality and Reliability Management. 29 (9), 972-980.

15. Pichler, R. (2010). *Agile Product Management with Scrum: Creating Products that Customers Love* (Addison-Wesley Signature Series). Upper Saddle River, NJ: Addison-Wesley, Pearson Education Inc.

16. Senapathi, M., Srinivasan, A. (2012). *Understanding post-adoptive Agile usage: An exploratory cross-case analysis*. The Journal of Systems and Software 85, 1255-1268.

17. Spotify (n.d.) Labels and artists. Retrieved January 15, 2014 from: https://www.spotify.com/se/about-us/labels/

18. Schwaber, K., (1995): Scrum development process. In *Business Object Design and Implementation* (pp. 117-134). Springer London.

19. Schwaber, K. (2004). *Agile Project Management with Scrum*. Redmond, WA: Microsoft Press.

20. Schwaber, K., & Beedle, M. (2002): Software Development with Scrum.

21. Strode, D.E., Hope, B., Huff, S.L., & Link, S. (2012). *Coordination in clocated Agile software development projects*. The Journal of Systems and Software 85, 1222-1238.

22. Sutherland, J. V., & Schwaber, K. (1995). The SCRUM Methodology. In *Business object design and implementation: OOPSLA workshop*.

23. Sverrisdottir, H.S., Ingason, H.T., & Jonasson, H.I. (2014). *The role of the product owner in Scrum – comparison between theory and practices*. Proceidia – Social and Behavioural Science 119, 257-267.

24. Takeuchi, H. og Nonaka, I. (1986). *The new new product development game*. Harvard Business Review, 64(1), 137–146.

25. VersionOne (2015): The 10th State of Agile Survey. Online at: https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf

26. Yin, R.K. (2009). *Case study research: design and methods* (4th ed.). Thousand Oaks, CA: SAGE Publications.