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.