Keywords

1 Introduction

Already at the large-scale workshop at XP2013 [9], how to manage complex and large development efforts with many teams was much debated. The topic is still very trendy as agile methods have become the de facto standard for product development in large companies. Some argue that a common large-scale agile framework like SAFe [18] and LeSS [17], is needed to define the roles, processes and artifacts. Others argue that context-based agile tailoring is vital to capture and address each organization’s unique coordination context [6] and changes in coordination needs over time [3, 7], therefore introducing frameworks has a limited effect. Others again say that the most critical success factors are cross-functional teams that take responsibility for their work and coordinate, communicate, and align their actions with others. Spotify serves as an example of this [25]. A recent trend is to design teams to match the software architecture and give these teams a defined topology to reduce their cognitive load [24].

Regardless of the large-scale agile approach chosen, there needs to be a function that is responsible for defining and prioritizing what goes into the product, and that handles all the conflicting priorities [20] that exist in a large-scale context. If the teams do not have an up-to-date understanding of what to deliver and why, reducing cognitive load, increasing autonomy, or applying a framework does not help. In such cases, there may be a need for Software Product Management (SPM). SPM can be defined as the “organization and coordination of all activities important for a software product in order to achieve product success“ [32]. In a recent study, Berntzen et al. [2] found the use of seventeen coordination mechanisms in a product area with 8 teams. Therefore, we argue that SPM plays a critical role in large-scale agile. SPM involves understanding market needs, defining product vision, and working closely with cross-functional teams to ensure successful development, launch, and ongoing management of the product [27]. SPM ensures a balance between technical and business perspectives and involves coordination between product stakeholders [11, 13]. The idea of SPM also fits well with the agile approach because a core SPM activity is to ensure the interest of the customers and clients of the product [27].

Product management means being responsible for a defined product [11]. In large organizations, such as a bank, a product can be a customer onboarding experience, a credit line, advisory services, or a banking account. When handling a small product, the product owner can handle SPM. When the product grows, a team of product owners can take on this job [23], often in combination with one or several product managers. Different products require different expertise and team configurations and, therefore, a different organizational setup, i.e., different product management configurations. However, research on how product managers’ roles and practices are configured in large-scale agile settings is limited. There is a distinct lack of comprehensive understanding of the specific organizational and team structures that support effective product management, particularly in organizations with many thousand employees that deliver both B2B and B2C products.

This study seeks to address this knowledge gap by investigating the challenges and configurations of product management within a large-scale agile organization. Specifically, we aim to answer the following research questions:

  • RQ1: Which challenges do product management roles face in large-scale agile?

  • RQ2: What types of product management configurations exist in large-scale agile?

To investigate these questions, we conducted a case study of DNB - a Nordic agile fintech organization with 10,000 employees where 130 people hold product management roles such as product managers and product owners. Through this inquiry, we aim to shed light on the organizational and team setups that facilitate effective product management, contributing to a more nuanced understanding of agile practices at scale.

2 Background

2.1 Large-Scale Agile and Product Management

In very large-scale agile companies, the complexity of the software development effort is enormous as many stakeholders are involved, often with conflicting interests. As a result, the need for inter-team coordination increases significantly [14]. Further, the products must adapt to constantly changing user needs, which requires an end-to-end flow between customer demand and the fast delivery of a product or service [12], which is challenging. Mikalsen et al. [20] found that agile product teams in a bank needed to negotiate with other teams, business units, and key management stakeholders to ensure that the digital offerings made sense in terms of both users’ needs and company revenue. Therefore, SPM needs to scale outside of the software development department and link to other functions such as marketing, sales, and operations.

Despite the importance of SPM, few empirical studies are focusing on SPM in large-scale agile [15, 16]. The current literature, including studies by Ebert [10], Tkalich et al. [31], and Springer et al. [27], have explored various facets of software product management, from role definitions to acquiring development resources and technical debt. Paasivaara et al. [23], highlights several challenges related to product management configurations and roles in a company during an agile transformation, such as challenges with defining the product owner (PO) role. Scaling the PO role is a common SPM practice. However, the PO role is often not enough, and additional SPM roles and configurations are often needed. Sometimes there is a team of POs [4], or product managers (PM) that lead the products, and that balance software development, people and politics [11]. Ebert and Brinkkemper [11] highlight the risks of operating without a dedicated PM, pointing to issues such as diluted leadership, suboptimal performance, increased rework, and delays. This underscores the critical need for focused product management to overcome the complexities of large-scale software development.

SPM has been found to have different setups in large-scale agile. It is common to organize into product areas where teams work with a common product or sub-product. A typical set-up within a product area can be one or more development teams, one or several POs and a PM that all work with the same product(s). Berntzen et al. [4] studied the development of a public transportation platform with 13 teams and 9 POs. Seven of the POs had one team, whereas two had three teams each. The weekly PO coordination meeting and quarterly workshops were facilitated by a PM. A much more complex setup was found by Smite et al. [26]. They describe a Telecom product at Ericsson developed by seventeen self-managing cross-functional feature teams; five teams in Sweden, ten teams in China, as well as two Korean teams. The teams were supported by technical experts, line managers, product owners, operative product owners, system managers, configuration managers, testing framework experts, continuous integration experts, agile coaches, and integration leaders. SPM becomes complex in such a setup. The authors conclude that networking is the primary mechanism when solving complex tasks in large-scale product development.

2.2 Challenges with Software Product Management

Introducing and succeeding with SPM takes time because of the many challenges that are associated with software product development. The larger the organizations and the longer the product life cycles, the more challenging. Ebert and Brinkkemper [11] studied a business unit producing components used in communication networks. The unit operated in North America, Europe and Asia, and developed platform products that are customized for contract projects. They found that results from introducing SPM were first available for the business unit after 12–18 months of working with a new SPM scheme. Therefore, to succeed with SPM it is necessary to be aware of the main problems that affect SPM and to provide solutions for dealing with them. Springer et al. [27] organized 15 focus groups with 47 software product managers to understand their challenges. The 5 most common problems were:

  • Determining the true value of the product that the customer needs.

  • Product managers must work iteratively with teams to understand the customer needs and scaling opportunities of the product.

  • Strategy and priorities are changing frequently, which makes product managers and their teams struggle with prioritization.

  • Technical debt slows down the product development process and makes it difficult to prioritize the product roadmap.

  • Working in silos. Initiatives that run across different departments require the need to align teams around common goals and synchronize them.

  • Balancing reactive and proactive work. Mature products struggle to prioritize innovation and new customer value against bug fixing and maintenance work.

Agile methods might mitigate many of these problems. However, Springer et al. [28] found that a core challenge is that teams are not agile, they just follow rules and do not use experimentation and learning, which is essential for succeeding with SPM.

3 Research Method

We chose a case study approach [29] to study SPM in DNB, which is a fintech organization in the Nordics. A case study provides in-depth and detailed knowledge, which is fitting for this study as there is little research-based knowledge about product management in large-scale agile. For five years, the first and fourth authors collaborated with one of the organization’s business units on team autonomy, product development onboarding, and distributed work [21]. The results of this previous collaboration were why DNB wanted a research-based approach to improving their SPM. In particular, there was a need to understand challenges, various configurations, and responsibilities. We interviewed people involved in product management from five business areas to understand the challenges of product management in large-scale agile and to understand which product management configurations exist. The three first authors conducted the interviews, authors two and three were responsible for the analysis, and all authors participated in meetings with the company.

3.1 Case Description

DNB has 10,000 employees mainly distributed over three cities. Out of these, over 130 people are involved in core product management activities and most hold a product manager or product owner role. DNB can thus be classified as very large-scale agile [8]. DNB did not subscribe to any specific scaling framework with pre-defined roles. All teams could choose their own agile practices, which allowed for flexibility in practices like sprints, stand-ups, and retrospectives. The organizational environment is characterized by both structural and technological changes. Over 70% of the POs and PMs had more than 5 years of experience in the company. They all had varied backgrounds; some had a technical (e.g., engineering) background and had been working in the product domain for several years, while others came from the business side. A few also came from other industries. The company introduced the PO role in 2017.

3.2 Data Collection

We interviewed 19 people involved in product management activities (Table 1). Each interview was held on Microsoft Teams and was recorded and automatically transcribed based on participants’ consent. Most interviews were conducted by two of the researchers, while two were conducted by the first author only. The interviews lasted from 46 to 70 min (55 min on average). We used an interview guide to steer the conversations and make sure we touched upon topics of interest but allowed the conversations to develop naturally. Core questions were: “Describe the technical and business aspects of the product”, “What works well/not well in your job?”, “How are decisions made?” and “What competence is important in your role?”.

In addition, we organized meetings with additional managers to understand the history of product management in the company and the context that the interviews were part of, e.g. department structure, the relationship between departments, products handled by each business unit, important company milestones, technical platform, and so on. We wrote minutes from these meetings. We also presented the results back to the organization in several meetings to verify our findings and to clarify misunderstandings.

Table 1. Data sources.
Full size table

3.3 Data Analysis

We used a thematic analytical framework [5] to analyze the data, which has been extensively described for software engineering research [1]. Thematic analysis proceeds through six iterative phases, where it is possible to move back and forth as the analysis develops [1, 5]. First, we divided the interviews among the authors, and read through each of them using open coding techniques to familiarise ourselves with the data and generate initial codes. From this, themes started to form, such as tasks and role descriptions, and challenges with product management at DNB. Next, we reviewed the theme by discussing each interview together to reach an agreement on categories and themes in the data. As part of reviewing the themes, we performed a second analysis, digging deeper into the data to better understand the challenges product managers and product owners experienced at DNB. The challenges identified from each interview were coded first at a lower-level category before similar codes were grouped together as themes. During this phase, we discovered that there were different product management configurations across the product areas. We therefore performed a second round of coding where we focused on understanding the different configurations present in the data. In the last phases of the analysis, we focused on refining themes by defining naming and mapping the different configurations to reach a coherent set of findings presented in the next section.

4 Findings

4.1 Software Product Management in DNB

In DNB, a ‘product’ was defined as something that delivers value, at the intersection of customer needs, business objectives and technology enablement. This meant that most things that deliver value to the customers could be defined as a product, e.g., a customer onboarding experience, a credit line, advisory services, or a banking account. Product management meant working closely with the cross-functional agile team, being accountable for the long-term business value of the product, and management of the product (including strategy, design, technology, risk, pricing, compliance, etc.) through the whole product lifecycle.

We found three key product management roles. First, the PM was described as “the CEO of the product”. This meant being responsible for vision and strategy, roadmap and high-level priorities, and business outcomes throughout the product lifecycle. Second, the PO focused on hands-on work with engineers and designers, transformed the high-level vision of the PM into epics and an updated backlog and enabled agile ways of working. The third role, often called ‘product lead’ (the role was not yet formally named) was used when there was a need to facilitate portfolio alignment across product teams or alignment between product areas where one PM was not enough.

When investigating how to succeed with product management across these roles, three characteristics stood out: 1) Having a large network and knowing who knows what, 2) working closely with the team, and 3) working as an internal diplomat in the organization. This included focusing on setting aside time to listen, discuss, and find solutions through informal meetings. One explained the importance of knowing the company and stakeholders in order to succeed in the role: “My biggest, what do you call it, badge is the fact that I know how the organization is built. I know who to go to, and who not to go to. And DNB is complex in that regard” [I15]. Another continued: “There are lots of experts and good people everywhere. You just have to know where to ask” [I08]. One interesting observation was that teams seemed to change often, and many did not know exactly how big their product team was. One PM said: “I haven't counted, but I think we're around maybe currently seven or eight” [I13].

Next, we present the main challenges with product management. Then we report on the software product management configurations that we found in the interviews.

4.2 Challenges with SPM in Large-Scale Agile Organizations

We found 10 challenges reported by more than five of the 19 respondents (Table 2). Some of the challenges were related to the very large-scale nature of the organization. A PM explained challenges caused by the size (10,000 employees) (C4): “The way we are set up is a bit… It is not easy to get the end-to-end value chain responsibility carried out. Because there are so many areas that play their part in the value chain. And perhaps they must do that. Because there are such complex systems and such complex value chains involved” [I06]. A department manager explained that the prioritization challenges (C2) were also related to the company size: “You get different steering signals, which means you don't necessarily get the speed you want. Or that there are an awful lot of people you must talk to before you can get anything done” [I08].

Further, there appeared to be a connection between some challenges and some types of SPM configurations. For example, a PM who did not have a PO in the team reported having too diverse work tasks, taking on PO tasks, and spending too much time in meetings (C1): “One moment you are working with risk management, with deadlines and set timeframes. In the next, you are working with the team as part of a creative and problem-solving task force. Then, you need to follow up on things that should be discussed [with stakeholders] and get a decision. It is a very wide task range” [I02]. In a related manner, a PO who did not have a PM on their team and who was dependent on another part of the organization for technical resources (i.e., developers) explained that the shortage of resources limited their freedom to act (C6): “Capacity is always a thing. It can be difficult to coordinate when you lack the resources” [I05].

Another interesting challenge (C3) was related to insufficient user data management, that is the collection and analysis of data generated from DNB internal and external users. Codes within this challenge included a lack of focus on working with data-driven insights in SPM: “That demand has never been on our plate. I would say nobody has asked us to, you know, take on this task” [I17], and not having the resources or opportunity to fully utilize the value of data-driven insights: “I have access to a system, but I have never had the time to fully understand how I can use it to get the data I actually need to make a proper analysis” [I06].

As described above, a key point to succeeding with SPM in DNB was the ability to network and get others to follow. Moreover, the many prioritizations to be managed (C2) and at times challenging organizational structure (C4) as well as the need to involve top management in many decisions (C7) made stakeholder management (C9) a challenge in DNB. We found that those who struggled with stakeholder management often lacked a large internal network or struggled to understand the inner workings of the organization: “I have underestimated the importance of understanding how big our organization is, and how important the stakeholder part is. You can come from a smaller company, […] and know the [product management] theories very well. But that does not mean that it works in DNB” [I14].

Table 2. Challenges with product management in the case organization
Full size table

4.3 Product Management Configurations

We found a range of SPM configurations, and the set-up of product roles and teams depended on the nature and lifecycle of the product. As there were conflicting priorities (C1, C2, C10), not all products had an ideal team set-up or SPM role configuration to match their specific product needs. Figure 1 shows the configurations described.

Configuration A: The PM and the PO is the Same Person, Part of One Team

This configuration was found in several products with different characteristics, often when the product was small in terms of the number of developers and stakeholders involved, or when the product was in the early phases (before scaling). One PM who worked on a new product relating to customer programs and covered both the PM and PO roles for her team, at least for the time being, described: “Now that it's so early [in the product phase], I have both roles. But I see that the more we develop… That is, in the initial phase, when you start things up, then it works. But the more you get into the operational side, there will be a need to get a product owner, too” [I11].

In other cases, this configuration was described as not having a PO, and that the PM also performed the PO tasks. For example, in a large cross-functional team that worked with a product that allowed customers to gain an overview and insight into their personal finances, one PM said: “I have long felt that I do not need [a product owner]. But it depends a lot on the team’s structure, maturity, and tech stack. In some cases, it is necessary to be closer and coordinate on a lower level to get the details right.” [I09]. However, also in this configuration, PO tasks had to be performed: “Now that the product must be both maintained and further developed, I am feeling the need to have a product owner […] Perhaps I have been a product owner myself the past few years without reflecting on it” [I09].

One PM who worked with a platform with both internal and external users explained that working on a complex product that involved a lot of strategic work was challenging and that therefore, there was a need for a PO to be more involved in the operational work. He explained: “In my team, we only have me as a senior product manager. Optimally, I think we would have two, one senior and one that is more junior, which then we could split – some teams do it, though, split responsibilities, right? So, one is more operational, the other one is more strategic”.

Fig. 1.
figure 1

Six SPM configurations with teams and SPM roles.

Full size image

Configuration B: One PM and One PO are Part of One Product Team

In this configuration, a PM and a PO were together responsible for one product team. For example, in a product team developing a system that enabled customers to invest money in companies. The PM of this team explained that he collaborated frequently with his manager, the PO, and the team (of which all six developers were located in another city) through daily meetings. The PM explained [I16]: “We have digital tools and we have Teams and cameras, it is just like sitting next to each other.” Working with a small data-driven agile team was an enabler for development speed. He explained: “Instead of spending a lot of time on planning and doing months of interactions [with customers] before we release a new product, we think that it is better to do the groundwork and get the product out and then rather make adjustments based on customer feedback”. However, the setup was not ideal: “we have two backend developers and four frontends, so maybe the team is not balanced enough. Because we often see that things stop because you are waiting for the backend. It's something we've addressed above [to management] as well”. The PM’s line manager played an important role. The PM explained: “He had the same role as I have now before I came in, but he has very broad and long experience. He is a person I can go to and discuss with if there is anything I wonder about”.

Configuration C: One PM, One PO, Several Product Teams

In this configuration, one PM and one PO share responsibility for two or more teams. There were several variants of this configuration depending on the product, as well as the different business units. One PO explained his situation: “I work as the PO for three teams in our product and I am primarily responsible for the [removed for anonymity] solutions for DNB. … I don't think it's ideal for a PO to run three teams. That's the challenging part. Some days it's very difficult to work on anything productive apart from being a chat support person.” He continued: “I have a PM whom I'm closely working with. … And I am more responsible for short-term [initiatives], like the next four months. That's my cup of tea, I would say. When it comes to what is going to be delivered this year, I expect a PM to plan that” [I17].

A PO who worked with loans and credit explained that he made most of the product decisions: “I also drive it as a PM as well…. If I need to get some clarifications or maybe push it, my escalation point for something else would be the PM. But apart from that, it's almost single-handedly driven” [I15]. Further, he explained that the two development teams he was responsible for were in other business areas: “They [IT department] have the Amazon Web Services developers, they have the UX designers, they have the mobile developers, they have the server-side developers, these are IT terms. They don't report to me, but they are part of the team that I am a PO for. Because there's no IT or tech resources or capability in my division.” He continued: “Once I give them a priority, they know what to pick up”.

Configuration D: Several PMs, POs, and Teams, With a Product Lead

When there were several PM, PO, and teams, we found an additional SPM role, often referred to as the product lead. One product lead explained that he started as a PM with one team, but when they scaled from 15 to 60 people, they needed a new structure [I14]: “I am responsible for the product managers, who in turn are responsible for product owners.” The group of nine PMs, POs, and the product leads all had different roles and tasks, but they had shared responsibility for the yearly roadmap. He continued: “Whether it is a product owner who helps prepare that year, or whether it is a product lead who prepares that year, does not matter that much. The most important thing is that everyone has ownership of it” [I14]. Every quarter, the group updated the roadmap and the high-level priorities, which then were presented at a meeting with all 60 people. After this meeting, the discussions continued in the teams: “The product owner primarily facilitated discussions in his own team” [I14].

A similar setup was found in a product area with 13 teams in three sub-areas. One PM reported that in his sub-area he had three POs (out of eight in the whole area), each working in one team with a specific responsibility: “Two teams are working on moving the existing solution up into the cloud. … so, it is only one of the three teams that I can work with on new development” [I06]. The job of migrating products to the cloud had a big priority in the whole organization as reported in the context description.

Configuration E: No PM, One PO, Several Teams

A similar configuration as the one described in Configuration A (except that there was no PM) was found in a product being migrated into the cloud (AWS). The customers would get a new customer experience, but no new functionality, which meant that there was less need for a PM at this stage, as the work was clearly defined and there was no need for strategy work. One PO who was responsible for three teams working on renewing a product described how there was to date no PM working with his teams: “What I do is that I map today's functionality. And set the requirements for how the new functionality should be… And then I get to check it out with the businesspeople. The other thing I do is coordinate with UX. And the next step after that is to coordinate that we still have a value chain that works. So, we can go all the way from the customer down to the core system” [I12].

Configuration F: One PM, One PO, the Team is External to the Organization

In one case, we found that although DNB set directions for the product, the product development was done off-site, by an external provider. “We have a special structure compared to other DNB products, as we have a ‘white label’ service where we don’t develop anything ourselves. So, I don’t have any developers” [I05]. In this set-up, there was “a PM who handles the administrative […] like compliance and vulnerability analyses and such while my main task is at the product level, the development progress and what we are to focus on in the time to come” [I05]. Interestingly, DNB collaborated with other financial institutions in a product council, where they instead of acting like competitors together set directions and requirements for the development team.

Additional Configurations

We found four additional configurations. Because of page limitations, they are only listed: G) Several PMs, no POs, one team, H) No PM, one PO, one team, I) One PM, no PO, several teams, and J) Several PMs, one PO, several teams.

5 Discussion

The adoption of SPM in large-scale agile companies is growing, and companies like Google, Facebook, Amazon, and Microsoft use the practice. However, adopting SPM is challenging [19, 27], and how the practice is adopted is different from company to company. Therefore, there is a need for research on SPM in large-scale agile. We have described how these practices are applied in DNB, a fintech organization with 10,000 employees. In DNB a ‘product’ was defined as something that delivers value, at the intersection of customer needs, business objectives, and technology enablement. We will now answer our two research questions: 1) Which challenges do product management roles face in large-scale agile? And 2) What types of product management configurations exist in large-scale agile?

5.1 SPM Challenges in Large-Scale Agile Organizations

First, we identified the top ten SPM challenges in large-scale agile in DNB (Table 2). The most common ones were challenges independent of a single product context, meaning that they were related to organizational features like company type and size. Further, we found that the organization was not set up to support products with long value chains that involved many complex subsystems where many organizational units needed to be involved (C4). Our findings are consistent with Maglyas’ [19], who found that when product development involves several departments, flow is hindered because each unit acts independently and focuses on its own work instead of thinking about the whole product. Further, per Springer et al. [27], we found that there was a lack of alignment between organizational units (C10). Companies will have challenges with delivering products across departments when there are silos and missing alignment. These underlying problems are related to communication and synchronization. Springer et al. [27] argues that while PMs cannot change the company structure, they can still minimize its impact on the teams and product development process. One solution to these challenges is having regular meetings between POs and PMs [27]. We found such a solution in Configuration D, where a group of 9 PMs, POs, and a product lead, interacted regularly, in addition, the product lead and the PMs were responsible for working on aligning decisions across the organization.

Second, we found a lack of a unified way of working with goals (C8), which is similar to the challenge reported by Maglyas et al. [19] that there should be one way of tracing goals in SPM. Unclear goals is also a barrier to team autonomy [22]. Springer et al. [27] supports the importance of working on goals and argues that there is a need to identify and trace goals to be able to balance reactive (bugs, technical debt) and proactive work (new development). In Configuration D we found a sub-area with three teams that had clear goals: Two teams working on the cloud migration and one team working on new ideas.

Third, we found that there were many tasks with urgent priorities (C1), that prioritizations came from many different parts of the organization, and that many were unclear (C2). This finding is consistent with Springer et al. [27] who argues that when the strategy for products is changing frequently or when dependencies between products are unclear, PMs and their teams struggle with prioritization, seeing the long-term picture and being able to achieve outcomes, as the direction is changing often. Smite et al. [25] found similar problems at Spotify; when product teams have too many diverse tasks with urgent priority, individual goals become more important, joint goals become blurry, and the team’s performance suffers. We have not had the opportunity to investigate why there were so many tasks with urgent priority and why the product strategy seems to shift frequently. However, Springer et al. [27] found that that if priorities change frequently, it is a signal that there might not be a strategy at all or the employers are simply not informed about the reasons behind priority changes, and how those decisions relate to product strategy. Our findings are also related to the problem of short-term thinking by Maglyas et al. [19]. But unlike the Maglyas et al., study from 2012, who argued that a one-year roadmap is too short, we did not find any problems with a one-year approach. This might be related to the fact that the market is more dynamic today than in 2012.

Fourth, we found that many product teams lacked a clear customer focus (C5), and put the business wants and needs first. Our findings are consistent with Maglyas et al. [19] that the decisions about new product development are often made internally in the company and not based on customer input. Fitting customer needs takes time and money. Springer et al. [27] argues that PMs have to run research and work iteratively to understand the customer needs, scaling opportunities, and customer willingness to pay for the product. The customer feedback loop is the key. In Configuration B, we describe a team with a data-driven culture [30] that focused on getting the product out before adjusting based on customer feedback, instead of doing customer research upfront.

5.2 SPM Configurations in Large-Scale Agile Organizations

Being able to succeed in delivering software frequently and iteratively requires work and knowledge coordination on different levels, i.e. at the portfolio, product, and team levels, and having access to the right resources. We found 10 different configurations of SPM (Fig. 1), and they were influenced by the following factors:

  • The maturity and size of the team. For an autonomous, small, and mature product team, there was no need for a PO, as the team handled the PO activities themselves by translating customer needs and prioritizing the backlog.

  • Product life cycle. In the startup phase, there was less need for a PO, and when migrating to the cloud (focus on technical issues) there was less need for a PM.

  • The availability of supporting roles such as line managers and previous PMs. These supporting roles helped POs and PMs in conducting SPM.

  • Where the team is located. If the team is located in a different department or in another organization, it might reduce interaction between PMs and the team, which again affects the SPM work.

We found that some configurations changed over time because of e.g., scaling (Configuration D), and some wanted to change as the setup was not optimal for the product development speed. These findings are consistent with Berntzen et al. [3], who found that scaling requires an adjustment in the coordination mechanism and in the organizational structure. Further, as resources are limited and prioritizations are sometimes conflicting, there is a need for SPM to negotiate [20] with other teams, business units and key stakeholders to ensure that the digital offerings make sense in terms of both users’ needs and company revenue. Moreover, the six different configurations described in detail underscore that there are several ways of doing SPM. Still, there are key differences between SPM roles, where PM tasks are typically outward-focused and PO tasks are more inward-focused.

During the interviews, it became clear that the SPM roles were not performed in a unified manner in the organization. Sometimes a PM can be a PO and the other way around. Unclear roles and responsibilities can cause frustration and misunderstanding. One could argue that the roles should be standardized. However, as each product context was different, standardizations could also be a threat to efficiency. There is also no guaranteed how-to recipe to foster alignment on roles, and the question is thus how much standardization and autonomy should be built into the SPM setup and roles. Like the tale of the sitar player asking Buddha how best to tune his instrument, we find the famous answer, “Not too tight, and not too loose,” as a good general rule on the degree of standardization of SPM roles.

5.3 Practical Implications

Based on our results, we can summarize some recommendations for those working with SPM. First, there does not exist one ideal SPM configuration. What constitutes an optimal configuration will vary over time, as the need for development resources of a product is not static. Further, as a product value chain changes over time, so does which part of the company will be involved in the product development. The larger the value chain, the more complex the SPM work and the more SPM resources are needed. Second, SPM should serve as a continuous link between customer needs, business needs and software development. Our results show that this is the essence of SPM regardless of the type and scale of the product, and the product life cycle. Third, independent of SPM configuration, the manager’s social network, negotiation skills, and company knowledge are prerequisites for success. The consequence is that to become successful in SPM, there is a need to spend time establishing and maintaining the network.

Above all, managers of software products in large-scale agile organizations need to work data-driven, meaning that they need to be in control of user data and understand how to analyze such data from the customer interaction to improve and shorten the feedback loops.

6 Concluding Remarks and Future Research

Despite the increasing popularity of software product management in large-scale agile companies, little research exists on how SPM is performed in practice and what challenges and configurations exist. We have therefore conducted a case study to explore these challenges and configurations. Given today’s increasing adoption rate of SPM in large-scale agile product companies, our findings can provide guidance for how SPM can work. The paper’s main contributions are an overview of ten common SPM challenges in a large-scale agile fintech organization and a description of six SPM configurations. The results of our study constitute a step towards a practical and theoretical understanding of SPM. We found that the essence of the SPM roles in large-scale agile development is to make sure that the products are continuously linked with customer and business demand and that product development is data-driven. Setting up experiments and analyzing customer data is key for effective product development. Besides, sometimes a PM can fill the role of a PO and the other way around, meaning that what software product managers actually do is more important than the name of their role. Therefore, future research should study the tasks of software product managers, find solutions to the ten SPM challenges, and explore the relationship between the SPM configuration, product life cycle, and supporting roles. Further, to provide better guidance on SPM in large-scale agile, future research should investigate the advantages and disadvantages of the identified product management configurations, and how POs and PMs delineate their responsibilities and collaborate.