Keywords

1 Introduction

The Product Owner role is a reasonably new role and comes from Agile software development. The name of the role refers to broad responsibility, for product ownership. According to the Scrum Guide [20] a Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. In addition, a Product Owner is accountable for effective Product Backlog management [20]. Yet, there are undocumented requirements and organizational pressures which also impact the work of the Product Owner. In a large-scale Agile set-up the role needs to be scaled when several teams work for the same product and one Product Owner is not enough [16]. In a large-scale context also many other roles and stakeholders exist and often bring requirements and pressure to the Product Owner. Thus, a question arises: How freely can Product Owners carry out their tasks and vision? Is the Product Owner role a fairytale?

The role of a Product Owner is more than taking care of the day-to-day running of the workday. According to Kelly [12], the role of the Product Owner brings little value if it is just backlog maintenance. The Product Owner should understand the technology and software development, as well as be able to say “no”, because the team cannot implement every idea [12].

Robert Frost was an American poet who once stated: “Freedom lies in being bold” [10]. Freedom speaks to philosophers, poets, and business creators. This study examines the freedom in the role of a Product Owner, especially how the Product Owner handles requirements and ideas coming from many directions in a large-scale Agile environment.

The Product Owner, who “owns” the product, can also be seen as a kind of entrepreneur. Our case organization hoped that Product Owners could lead their products with an entrepreneurial mindset. Therefore, this research explores how an entrepreneurial mindset is realized among Product Owners in the large-scale agile set-up of our case organization.

2 The Product Owner Role

The role of the Product Owner was introduced in the Scrum software development framework in 1995 [20]. Originally, Scrum was designed originally for one development team, with which one Product Owner would work. Nowadays, Agile is used also in large companies and projects. In large-scale agile, there are often many other stakeholders involved, and one product or service may have several Product Owners. Besides, working with the development team, the Product Owner may gather the requirements, communicate with the customers and even market the product, at least within the company, while the external marketing of a product is usually handled by marketing experts.

A symphony orchestra is a metaphor for how the Product Owner operates: a symphony is conducted by a conductor. Software developers can be thought of as symphony musicians. A symphony orchestra will certainly be able to play without a conductor. However, while musicians can play without leadership, they need to be in sync with others. The musicians make the choice to follow the conductor. The conductor helps to synchronize and makes the performance consistent. The conductor does not direct but orchestrates the symphony [22]. The Product Owner has a similar role as the symphony conductor: The Product Owner orchestrates the software development team. The developers (i.e. musicians), act independently, but the Product Owner takes the development forward in the direction which benefits the product (i.e. the music experience), which the whole team provides.

A Product Owner must have the mandate to play his or her role. A Product Owner collaborates within a network. Scrum does not place supervisory roles above the Product Owner. However, companies have their own internal organizational structures, and there may be more than one organizational model in use. Kelly’s [12] statement is a good starting point for considering how to own a product: “In the real world, managers report to owners. So surely Product Managers should report to Product Owners?”.

The financial sector, where the case organization operates, is controlled, e.g., by regulations and social responsibility. Therefore its’ operations are monitored by external agencies. The organization creates the boundaries for the Product Owner’s role, and the level of freedom for the Product Owner, e.g., what the Product Owner can decide on his or her own, and when he or she can say “yes” to new requirements. For example, an entrepreneur is free to decide how to spend his or her time. This study investigates when the Product Owner feels free to say “no”.

A Product Owner should not be a committee, she or he is one person [20]. Although, in the end, Product Owners are accountable, they may share the responsibility. For a Product Owner to succeed in work, an organization must respect the decisions made by the person in this role. The Product Owner role is also used by companies that may use a software development method other than Scrum, such as Kanban. Many of the Agile scaling frameworks, like the Scaled Agile Framework (SAFe) [19] and Large-Scale Scrum (LeSS) [21] have the Product Owner role. However, the role of a Product Owner is still largely implemented as Scrum states it.

Agility needs to be defined at an early stage in the organization so that all parties implementing it understand and are motivated by the goals. Developers’ autonomy is one challenge as autonomy is difficult to maintain when the scale gets larger [4]. Software development is a people-to-people collaboration that seeks the same direction. This is one of the reasons why companies try new frameworks and customize them to their own needs. The Product Owner is not sitting in an ivory tower, but the role needs to collaborate [18]. An entrepreneur can make many decisions independently, however, the Product Owner is a role within the organization, and thus it does not have the same operating environment. The Product Owner acts as an interface between the stakeholders and the development team; the Product Owner represents stakeholders and communicates their needs in software development, and product creation [9]. Manifesto for Agile Software Development emphasizes responding to change, rather than complying with the plan [1]. Thus, the work of a Product Owner is expected to include elements that allow this role and the whole team to respond to changes.

Usually, Agile teams are small, five to nine-person teams [11]. When Agile is implemented in software development organizations with at least six teams or 50 or more people working on the same product, it can be called large-scale Agile [7]. This large-scale set-up causes complications, as often the basic Scrum set-up with one team working with one product guided by one Product Owner does not exist, but also the Product Owner role needs to be scaled and Product Owners need to collaborate inside the same product [16], which might impact on the experienced freedom and the entrepreneurial mindset of a Product Owner. The rest of the paper explores the experienced freedom and the entrepreneurial mindset of Product Owners in large-scale Agile.

3 Research Method

We chose case study [24] as the research method for this study, as it is suitable for exploring a new phenomenon. Interviewees from the case organization were chosen by purposeful sampling [17], which resulted in a diverse sample of Product Owners.

3.1 Research Questions

As a Product Owner is accountable for effective Product Backlog management [20], one of the crucial aspects of the work is the prioritization of requirements. The first research question (RQ1) explores the freedom Product Owners experience in their work, and how they can control their operating environment by saying “no” while prioritizing requirements and giving direction for product development.

In our case company, there is a desire for the Product Owners to have an entrepreneurial mindset while striving for the success of their products. The second research question (RQ2) delves deep into whether the Product Owners feel that an entrepreneurial mindset is a good goal and how they themselves perceive their work from that viewpoint.

  • RQ1: How does the Product Owner say no?

  • RQ2: What is the entrepreneurial mindset of the Product Owner?

3.2 Case Organisation

The case company is a Finnish financial company that has development units in a few large cities in Finland. 4500 ICT professionals work indirectly in the Development & Technologies organization of the case company, of which 1100 are directly employed. Some of the interviewees belong to the Business organization of the case company. In the past, the company’s software development worked largely according to the Scaled Agile Framework (SAFe) with a very large-scale Agile set-up. In early 2019, the entire company reshaped its organization to become more Agile by creating a new Agile culture. The case company sought to learn from Spotify’s tribal model and use it as a template. The financial sector has much stricter regulations than Spotify, an audio streaming provider, which has much more freedom to implement its platform. Thus, the case company modified its organization based on ideas from the Spotify model, and adopted, e.g., tribes.

In the case company, software development is mainly internal: development of new products, channels, and systems (e.g., applications, SaaS, interfaces, and core systems), or integration of purchased products. The developed systems are used for internal needs or by their customers. The portfolio is extensive, with accounts, payments, and insurance being its core business. The team size for the interviewed Product Owners in the case company was typically around 10 people, the smallest team size being four people and the largest thirty. Inter-team shared resources increased team size by an average of about three people. Usually, one Product Owner worked with one team. For those Product Owners, who had multiple teams, the total number of people in teams was several dozen.

3.3 Data Collection and Analysis

This case study explores a current phenomenon with empirical qualitative methods. Answering questions of how is a known strength of qualitative interviewing [2].

An advantage of interviews as a source of evidence is that they can focus directly on the research questions. Interviews are also useful for finding cause-and-effect relationships [23]. Semi-structured interviews were chosen as the main data collection method as it was desired to dive deep and explore a new topic.

Table 1. Interviewees
Full size table

All 18 interviewsFootnote 1 were conducted in Finnish and transcribed, while citations were translated into English. The average interview duration was 61 min. The identifiers and the durations are reported in Table 1. Three interviews out of 18 were initial interviews, which were organized with managers and directors in Aug 2021. These interviews collected a deeper understanding of the case company and focused our research. The rest of the interviews with Product Owners and similar roles took place from September to October 2021.

Twelve of the interviewees were Product Owners and Senior Product Owners, two directors, one Expert Product Owner, one Business Developer, one Business Lead, and one Competence Lead. Senior Product Owners differ from Product Owners in the amount of experience. Expert Product Owners have even additional expertise according to the company’s internal criteria, while Business Developers are entirely business oriented and often seen as equal to Product Owners. Of the 18 persons interviewed, half had technology as their educational background, while the remaining nine had business education. The interviewees were collected from two different internal organizations and mainly from two different tribes. We sought persons with solid expertise of product ownership, Agile or long experience in the case company. There were interviewees from several tribes, but some of the interviewees were sought from a certain tribe, because it was known that the tribe had expressed more challenges related to the Product Owner role and organization’s practices for product ownership. Seven interviewees were from Tribe 1, four interviewees from Tribe 2, and seven interviews were conducted from case company’s other tribes.

Traditional case study researchers have not sought a tabula rasa as a basis but have given room for analysis to evolve. A distinguishing feature has been the focus on the context and rich description of the phenomenon [8]. The ambition of this research was to allow room for an increase in perceptions of the role of Product Owners.

A benefit of online interviews is an efficient use of human resources, when participants are located geologically apart [14], as in this study. The interviews were conducted remotely as video meetings in Microsoft Teams. In three out of the 18 interviews, the call was conducted without a video image due to the wish of the interviewee.

The transcribed interviews were coded and themedFootnote 2 by the first author using a qualitative data analysis tool, Nvivo. With open coding, the codes emerged from the data and were grouped under higher-level themes. A total of 927 mentions were coded. For example, under the theme “entrepreneurship”, with 59 mentions, were the codes: pros of entrepreneurship, cons of entrepreneurship, mindset, and rewards. The coded excerpts were carefully read and analyzed, and the main points were extracted as the results.

The results were validated by presenting them in a feedback meeting organized within the case company. An invitation to the feedback discussion was sent to over two hundred people, including all interviewees, and 28 persons participated.

4 Results

4.1 RQ1: How Does the Product Owner Say No?

In an entrepreneur’s own company, the entrepreneur exercises supreme decision-making power, which offers freedom. This study deepens understanding of the concept of freedom by examining how a Product Owner can control the focus of product development by saying “no”. The prioritized desires are usually new functionalities. When it comes to a large company that uses large-scale agile, like this case company, requests come to the Product Owner from many directions, and sometimes it is difficult for the Product Owner to say “no”.

Production Problems: There are situations concerning the operation and the future of the entire company, such as sudden production problems, which require quick prioritization of the repairing work. For example, a production problem that stops payment traffic is always prioritized above everything else. In these cases, the Product Owner serves the best possible way, and freedom is not exercised in any other way than prioritizing quick repairs.

“If there is no production disruption... So to speak, to it [production problem] the Product Owner cannot say “no”. If it is in our context, the fact that services are up, so of course, that is always at the top of the list. But then to other parties or demands, the Product Owner can say “no” if there is a reason for it.”                   —H4

Company-Wide Objectives: There are company-wide objectives with a lot of dependencies, over which the Product Owners do not have full influencing power. The highest objectives concerning the entire case company do not come as prioritized. Thus Product Owners feel that decisions trickle down too low in the organization: Sometimes the Agile model was felt unnecessarily decentralizing decision-making.

“It is a bit like that, maybe the kind of Achilles heel of such an Agile, self-steering model, that it can kind of trickle down unnecessarily low the decisions about what to do and what not to do. Yes, there could be such optimization of resources at a higher level, and then giving more clearly that this is what we want.”                  —H15

To Whom Can the Product Owner Say “No”? When the interviewed Product Owners were asked, who they can say “no” to, then seven out of 15 interviewees (excluding the first three initial interviews) replied that they can say “no” to anyone, but the answer came with laughter. The physical reaction was similar for each interviewee. 47% of interviewed Product Owners said, accompanied by laughter, that they can say “no” to anyone in the organization. However, the Product Owner’s own disbelief was manifested in the stir of laughter. Thus, they were not quite behind this opinion. They especially felt that when a superior, higher in the organization’s hierarchy, has greater decision-making power, it is difficult to give a negative or opposite opinion.

“Not really to anyone. To the supervisor, you can’t really say “no”, it must be expressed differently in that situation.”.”                  —H17

“I tried to say “no” to my supervisor in some project, but the supervisor stated that it just has to be done. And then we did it [says the interviewee with a resentful sneer]. I think we would need to be able to say “no” if it is justified.”                  —H6

Some of the interviewed Product Owners felt that they had a set of peers, e.g., other Product Owners, with whom they can have an equal say.

Organizational Hierarchy: The Product Owner has people above him or her in the organizational hierarchy. If the Product Owner wants to make changes, in the current model, the message must be taken up one step at a time. In this case, the next step in advancing a cause or a vision may be a business owner, followed by tribal leadership, one or two higher superiors, and finally the leader of the entire company. At every step, a new role takes the message forward. In this case, each step acts as an interpreter. The risk is that the perception of a product’s needs or capabilities will shape along the way. Technical issues are interpreted in the business language in different ways by different people. Misunderstandings or message-modifying summaries are generated. Although the Product Owner takes the message up a certain hierarchy, the common supervisor of the people on these stairs, and the Product Owner, may be far away from each other in the organization’s hierarchy. That is, not everyone above the Product Owner in the organization chart is superior to each other.

Saying “no” can be equally difficult for the superiors of the Product Owners. However, it does not help if the next step in the organization is facing the same dilemma.

“Basically, the higher you go in an organization, the harder it gets, in a way you’ll have a sort of view, that you always have to respect and think about the position of the supervisor and his supervisor and his supervisor. But under certain conditions, you can say “no” to them. It is basically [a situation] where you can at least ask why you say that.”                  —H15

“In a way that... ”This kind of functionality has to be done right now”. It may be that the Product Owner sees that it has no value. But since the Product Owner can’t directly tell it to him or her, and then the person above the Product Owner doesn’t dare to say it up there, then it kind of doesn’t help anything.”                  —H8

The companies have intentionally created hierarchies, but hierarchies should also be viewed in terms of how those could be enabling factors of product development.

Fig. 1.
figure 1

Ways for the Product Owner to say no.

Full size image

The Ways “No” is Said: Figure 1 shows the ways in which the interviewees felt that the Product Owner could say “no”. Usually, the Product Owner handled the situations through discussion. To a certain point, the way to say “no” is to discuss. Communication skills are strongly emphasized in the work of the Product Owner. Although progress in the negotiation also depends on the goals of the participants of the discussion.

“[When visions are at intersection] I feel that I have been able to communicate quite well the direction where we are going here [...] Sometimes there has been something smaller [requests], that has been said to be really important to get. Then I have pointed out that okay we will deliver, but please understand that this will then cause a delay in these other features.”                  —H15

After discussion, the item might be taken into the backlog and prioritized according to its necessity or urgency. Some of the interviewees felt that they were under pressure from the business side, that the tasks had to be taken into the backlog, even though the Product Owner did not think they were reasonable choices for the product as a whole, and thus might prioritize the items low. There is a risk that the item may be left in the backlog for a long time. While negotiating, a Product Owner sometimes has to say “yes” instead of “no”, so that the negotiation partner treats the ideas with an open mind and returns the favor by also saying “yes”. However, not all decisions can be traded.

Gathering opinions behind the Product Owner’s opinion is another way of saying “no”. The Product Owner gathers a few agreeing experts to a meeting to justify his or her own opinion. In this case, the Product Owner’s opinion was perceived to have more power, and a stigmatizing choice to oppose did not apply to the Product Owner anymore.

“If you’re in a situation, where you can’t really get ahead between the two of you, then maybe you can take a few people or the issue owner, and look at the whole thing together. Then it will always be easier to make that decision and the big lines when more than one opinion agrees. ”                  —H4

Dictating Culture and Not Understanding Agile: Some interviewees felt that saying “no” is not constructive because the Product Owner does not have enough to say and the role is walked all over. In that case, the Product Owner would need help from the roles higher up in the hierarchy to say “no”, but these higher roles might not take a position on behalf of the Product Owner for their own reasons, e.g., because of conflicting goals or opinions.

“ We have such a culture, that top management can dictate. That “this is done like this” and no one can say anything about it. No one dares to say to top management. If we talk about that top management, the Product Owner is so far away from that, that he or she has no chance of saying anything up there. It would require that in a way our Business Leads and tribal leadership, would say “no”.”                  —H8

“If I would want to take a position on the orders which are coming from Business Leads and question that model, then yes, I feel like I can say “no”. But I know it is not far-reaching, because there are such strong personalities, that it comes back pretty quickly as a boomerang. It is not constructive, at least in that tribe. That kind of conversation cannot be discussed in a constructive spirit. Although I can say “no”, it doesn’t make sense in that environment.”                  —H9

Some interviewees had unpleasant experiences of how opinions and know-how can be walked over. Shouting at meetings crosses boundaries that would not generally be wanted to be crossed. When the Product Owner’s role is not understood, some may abuse their power and customers might not get the best possible version of the product.

“It should not be this HiPPO-style: that the Highest Paid Person decides. We make these products for customers. Through it, we reflect on those outcomes. But that’s it. This is often a matter of making compromises.”                  —H11

Several Product Owners felt that there are situations when the business has not understood the Agile way of operating and walks all over the Product Owner.

“If you say “no” too many times, and even if you justify it by the fact of moving to this Agile model, when you say enough “no”, you will be blacklisted. If you say once or two say so, you may not be blacklisted. It sometimes resembles some junior high school frankly. There, really, in some group meetings, the volumes may rise, and swear words are thrown. You don’t want to go along with that intentionally when you know what will follow. I prefer to swallow my disappointment and say that this is how it is done here.”                  —H9

The Product Owner Role Needs Clarification: Several interviewees felt that Agile was not fully understood and the Agile roles would need clarification from a higher level of management. While transitioning to large-scale Agile the roles were defined in the internal intranet. However, this was felt insufficient. Especially the Product Owner role would need clarification: how the role is seen, how it is positioned, and what kind of power and freedom the Product Owner has. If the Product Owner is to lead the product, then he or she should be able to make decisions and show the direction.

“There must also be decision-making ability and not everything can be discussed in the Swedish style until the end or endlessly. But it is good to go through things. Then, if there are differences of opinion on which direction to take, then, of course, the role of the Product Owner is to make decisions and, in a way, show direction.”                  —H4

The interviewees felt that it is difficult to be responsible for the success of a product if its direction is not determined by the person responsible for it. It emerged also from the director-level interviews that, the Product Owner is expected to resist by saying “no”, to hold the side of the product and that way make it better, but in practice that turned out to be difficult. Finally, a clarification was wanted on how IT and business should work together, in an Agile way.

4.2 RQ2: What is the Entrepreneurial Mindset of the Product Owner?

The case company emphasized how an entrepreneurial mindset could benefit the work of Product Owners. Any small and large company can create its own products. An entrepreneur “owns” his or her own company’s products and takes them forward so that it will be a reasonable business, justified by its technological solutions and created customer value.

The decision-makers of the case company expressed in the interviews that they wanted to encourage the Product Owners to have an entrepreneurial mindset. They hoped that the Product Owners would take ownership of the product, that the entrepreneurial mindset would help them to outline and plan the product, and finally, by taking responsibility the Product Owners would have also more freedom. This mindset was expected to benefit the company.

Our interviews revealed that there were still many blockers on the way and room for improvement in the support structures enabling the entrepreneurial mindset. The case company could benefit from giving more opportunities and freedom so that the Product Owners would get to show their full capability and skills. The aspects of an entrepreneurial mindset in the case company are described in Fig. 2.

Fig. 2.
figure 2

Pros and blockers of an entrepreneurial mindset.

Full size image

Attitude Towards the Entrepreneurial Mindset: The interviewed Product Owners were motivated and committed to their work and felt that they could use their skills in this role. 39% of the interviewees raised positive issues about the entrepreneurial mindset, while 56% raised negative issues.

Entrepreneurship was felt to be largely about being able to build something new from scratch.

“As an entrepreneur, if and when you get to build a completely new service from scratch, I think that is more entrepreneurial”                  —H6

Even when the interviewees felt that the case company had not given Product Owners an opportunity to be entrepreneurial, an entrepreneurial mindset was perceived as a good goal within the company.

“I don’t know how to rationalize [entrepreneurship as a goal], but yes you have to be truly independent and forward-looking in the best possible way relative to your own product or area.”                  —H7

“Absolutely! And this [entrepreneurial attitude] is one element that I personally love above everything else.”                  —H1

“I see that those are my stuff, I own those, and I have to take that forward. And that’s clear. But I think it is a pretty natural pattern of thought. That’s how it should be for everyone, though. [...] When it comes to entrepreneurship, I might feel it is a little different than what it really is in a bigger company like this. It is more of a sphere of thought that you need to be entrepreneurial here maybe, but the activities might be a little different nonetheless.”                  —H13

Regarding the Product Owner’s motivation and goals, an interviewee presented an analogy of a sports hobby. An entrepreneurial mindset can mean the same as taking responsibility in a sports team or in a goal-oriented sport. The athlete is always able to invest in his or her own development with independent decisions.

“I find the analogy more from the world of team sports, than from entrepreneurship. And yet the goal in both is the same, that we are just super committed and striving to achieve the goals.”                  —H18

Challenges Regarding the Entrepreneurial Mindset: Although the requirements of an entrepreneurial mindset were understood, our interviewees reported many factors why a Product Owner could not be entrepreneurial in our case company: 1) The Product Owners could not create their own vision for the product but had to implement what the business wanted. 2) In a large-scale Agile setup there were a lot of dependencies across the organization, thus decisions could not be independent. 3) The budget and resources were decided elsewhere in the organization and the Product Owners did not even have much to say on how to use the budget. Next, each of these challenges is discussed.

Implementing What Business Wants: An entrepreneur creates a vision for his or her product, which the interviewed Product Owners felt they did not have a possibility to do. Instead, new features came from elsewhere, from the business side, thus it was felt that the Product Owner was losing the opportunity for an entrepreneurial mindset. Instead, the Product Owner was just implementing what the business wanted. Whereas an entrepreneur would own the product and could decide the direction.

“I feel like I work as an IT team coordinator and a responsible person, but not as an entrepreneur. I feel that an entrepreneur should be creating that vision, and there should be possibilities to make an impact vertically, not just horizontally. It [the work of Product Owners] completely lacks the aspect of effect vertically. That’s why I don’t think there’s anything left of entrepreneurship in it, just crumbs.”                  —H9

“When it comes to just queuing up what comes from business as an input, that is not entrepreneurial. Or I don’t know, ditch excavation can also be entrepreneurial, you can start a business for that too.”                  —H2

If the Product Owner is seen more as a performer of tasks than as an orchestrator of the whole, then product ownership and thus entrepreneurship will not materialize.

Dependencies: In the large-scale setup of the case company the team of each Product Owner was seen as just part of a puzzle - it had a lot of dependencies on other teams and other parts of the organization. Thus, the Product Owner did not have the possibility to make decisions independently.

“But on the other hand, then, you can’t just be an entrepreneur [in this role] who makes decisions completely independently, but there are a lot of dependencies, which, in a way, then drops away the other side of the entrepreneurship, that is, the maneuver space.”                  —H14

In addition, the Product Owner was not responsible for the whole, but just part of the work done for the product. For example, the maintenance did not belong to the Product Owner’s area. Thus, the current model was not seen as supporting the entrepreneurial mindset.

“Everyone probably wants to act like that [with an entrepreneurial mindset], and everyone wants to look like it works. But an entrepreneurial attitude means that you really own your product and are serious about getting that better and more profitable. We have thrown out maintenance from products elsewhere. And then things related to the user experience are in pretty bad shape overall. And then we are required to do 120% of the work time new features, so try to be entrepreneurial there! [...] It may be that people are like fooling themselves with it, but in this model where we are now, it does not work. We don’t really have product ownership, we don’t have product management. Then when we have them, then we can be entrepreneurial.”                   —H2

One of the dependencies mentioned was house-level policies posed for all employees. As an example, an interviewee gave the remote work policy. It was hoped that Product Owners would be able to influence the amount of remote work they do. It would be difficult to see the environment as entrepreneurial if the employer dictates how much the employee or team is allowed to work remotely.

“But then there are still certain house-level policies, in terms of practices or others, so that for example, I am looking forward with great interest to how strict the policies will be for us to come back to the office [after the pandemic]. [...] When you have the freedom to choose where you work, then you will have a certain responsibility to do the work. Because then there’s kind of no one watching all the time. In my opinion, entrepreneurship is based on that. That you have that freedom, but then you also have that responsibility.”                  —H8

Budget and Resources Coming Elsewhere: It was felt that when the budget and resources come from elsewhere, it is difficult for the Product Owner to be entrepreneurial. Although an entrepreneur may not have even the same budget available as a Product Owner in a large-scale Agile company, at least entrepreneurs have more freedom to decide how to use the budget.

“For that operation to be entrepreneurial here [in my team], in a way, this little team would be my own boutique... We are not there. Yes, it would take quite a few things. One would be the budget. Also, I also really should have an influence on things like resourcing.”                  —H10

Monthly Salary Creates Safety: Several of the interviewed Product Owners from the case company felt that they are employees in a large-scale Agile environment with a monthly salary, which creates job security that they liked.

“And in this context, that work is done for the employer.”                  —H4

Making the environment more entrepreneurial would run the risk that employees would no longer feel so safe, and the focus would be on the potential negative aspects of entrepreneurship, such as job and salary insecurity.

“I’ve always thought I wouldn’t want to be an entrepreneur, in a way, that safe job is a pretty important thing to me.”                  —H17

“Entrepreneurship means that you are a 24/7 entrepreneur, and, in a way, the workday does not end. Even though I personally feel that my workday does not end when I end the day, I’m still available after that if needed. But it’s kind of like I’m not responsible for being available 24/7.”                  —H18

Thus secure job was seen as a positive aspect of the current situation in the case company.

4.3 Validation

A feedback meeting was held at the case company to validate the results of the analysis. The participants shared their opinions on the results, i.e. their views on the validity of the results. Eight participants (commenter IDs V1-V8) gave comments: they recognized the areas for development and the problems. The only concern raised in the discussion was that if the tribes of the interviewees are very different from each other, then the results of the study might be bundled together into a too-generic outcome. However, the purpose of this study was to obtain versatile data from different parts of the company. The results that this research underlined were perceived as identifiable.

“It was very delightful to see that the experiences I have myself were reflected in this presentation. I think you have at least got into this presentation very well, how this world looks like from my point of view. [...] That is, there has been a slight debate in our tribe about who makes those decisions. One view there is that business tells us what to do, and the job of Development and Technologies is to do as we are told or do, i.e., what the business says.”                  —V2

The commenters felt that there were still difficulties in implementing an Agile culture. For example, features for products were ordered, rather than discussed and decided together.

“I feel like we are still pretty strong in there, what was being said, that features are being ordered.”                  —V4

When considering the freedom of the Product Owner, the interviewees felt that the current resourcing and budgeting model does not quite support Product Owners to try out new ideas. Instead, resources are devoted to what is planned from the business side.

5 Discussion and Conclusions

Central to the development of modern capitalism has been the idea of freedom [6]. In this paper, we studied the freedom of the Product Owner role in a large-scale Agile organization regarding two aspects: how a Product Owner can influence the direction of the product by saying ”no”, and whether Product Owners have an entrepreneurial mindset. To our knowledge, this is the first study exploring these topics.

An entrepreneurial mindset is perceived as important in engineering, and scholars emphasize the importance of creativity in science-oriented careers [5]. Prior knowledge is important for an entrepreneur to recognize an opportunity. An entrepreneur is able to create a venture when an opportunity has been identified [13]. The Product Owner creates products. An entrepreneurial mindset can be thought of as proactive and saying “no” as reactive. In this study, we found that the organization’s hierarchy and budget create boundaries within which the Product Owner can say “yes”. However, the Product Owner needs to set limits and make room in the backlog for new opportunities by saying “no”.

How Does the Product Owner Say No? The interviewed Product Owners claimed they can say “no” to anyone, but the results showed the uncertainty behind this claim: In reality, they were not able to freely scope their products in this large-scale Agile setup. Instead, their superiors and business people could walk all over the Product Owners’ vision. Results revealed that Product Owners preferred handling the conflicting scoping decisions through discussion, instead of directly saying “no”. This could result in taking items to the backlog against the Product Owner’s vision, and in that case, aiming to prioritize those items low. Gathering support from persons having the same scoping opinion was another option to keep unwanted items out of the product scope.

The role of the Product Owner and its’ decision-making power was unclear in this large-scale Agile setup and would need clarification. Many felt that the organization lacked a proper understanding of Agile. The findings showed that the Product Owner role in a large-scale Agile organization may not be realized according to the Scrum guide [20].

What is the Entrepreneurial Mindset of the Product Owner? The underlying human predisposition of entrepreneurship to try or pursue persistently entrepreneurship is determined by different models [3]. Giving freedom improves organizational agility, and freedom empowers employees to act independently and in a self-coordinated way, as entrepreneurs do [15]. Thus, our case organization encouraged the Product Owners to take responsibility by valuing an entrepreneurial mindset. The interviewed Product Owners found this goal understandable, however, they reported many blockers that prevented reaching the mindset: 1) The Product Owners could not create their own vision for the product but had to implement what the business wanted. 2) In a large-scale Agile setup there were a lot of dependencies across the organization, thus decisions could not be independent. 3) The budget and resources were decided elsewhere in the organization and the Product Owners did not even have much to say on how to use the budget.

Product Owners are expected to lead the product to success. This study shows that the Product Owners perceive the entrepreneurial mindset to some level as a utopia in a large-scale Agile setup. It was felt to be more important that the Product Owner could make independent decisions.

Limitations of this study include the following: We interviewed 18 persons from a large-scale organization, thus we could triangulate the answers among the interviewees. However, we could not cover all Product Owners in the company, thus, some viewpoints might be missing. This is a single case study. To increase generalizability to other similar organizations, we aimed to provide a rich context description. However, studying several case organizations would have provided better possibilities to generalize.

Future research could dig deeper into how the Product Owner’s freedom could be concretized in a large-scale Agile environment. We encourage researchers to perform similar case studies in other large-scale organizations to study how the freedom of the Product Owners is realized and what the implications are.