1 Introduction

In an increasingly more complex environment, companies need a holistic product strategy to develop products. When products must adapt to constantly changing user needs and new products should be launched, there is an increasing need to establish an end-to-end flow between customer demand and the fast delivery of a product or service. In agile software development (e.g., Scrum), the Product Owners (PO) are responsible for this flow. POs translate business needs into practical software requirements, elicit and prioritize requirements, approve software produced for release to customers [1] and make sure the product is profitable [2]. In this way, POs represent the customer demand. However, as described and practiced in Scrum, the Product Owner role may not be sufficient. What is needed is a product analytics capability to constantly evaluate the current value of the products and adjust them. A dedicated manager should systematically discover features that maximize the product value and quickly experiment with the delivery of those features, the cost of their delivery, the usage by customers, and the actual return on investment from these features, as argued by Fitzgerald and Stol [3]. This is similar to what the Lean Startup approach [4] and dual-track agile [5] aim to achieve through a continuous build-measure-learn loop and experimentation with users. To achieve this, one needs a continuous end-to-end flow between customer demand, business strategy, and software development [3].

Product management is a discipline that can achieve such flow. The role of a product manager is to continuously develop product portfolios and sustain their link to the customer demand [6]. The adoption of product management is now standard in companies like Google, Facebook, Amazon, and Microsoft and has been increasingly popular after the success of Marty Cagan’s Inspired [6], which provides guidance on product management based on the experience of the most advanced technological companies. The academic literature has also been investigating product management for decades. We now have detailed descriptions of the activities that product managers are supposed to perform towards software development [7], the impact of these activities [8], and how they manifest in practice [9]. However, these descriptions seem to be based on a plan-driven approach, making it unclear whether they can guide product managers in agile companies.

Although we see that product managers clearly have an important role in today’s agile companies, we do not fully understand how this role is practiced. While the role of the Product Owner has been extensively researched during the last two decades, the role of a product manager has been disregarded by the agile academic community, possibly for being too conservative and plan-driven [10]. Nevertheless, we know from the research on large-scale agile that the PM role is indeed being utilized in agile projects [10,11,12], but not which activities they perform, how, and why. The answer to these questions may be a way to guide product managers into more agile ways of working. We are therefore asking the following research question: How is the product manager role practiced in agile companies?

To answer the research question, we conducted a multiple case study based on data from four agile companies with the product manager role. The paper is structured in the following way. The next chapter gives an overview of the roles responsible for product development (product owner and product manager). Section 3 describes our research approach and the case contexts. We present the findings in Sect. 4 and discuss them in Sect. 5.

2 Background

There are no extensive studies on product management in the agile academic literature. However, a product manager role is similar to that of a Product Owner because both roles represent customer demand. We will thus begin our literature review by describing PO. Then we will draw on the management literature to describe what we mean by a product manager.

2.1 The Product Owner Role

The customer relationship is key in agile, where the customer should be on-site and co-located with the development teams [13]. In Scrum, the PO is defined as a person who gathers and prioritizes features, interacts with the customer [1] and communicates the customer’s business needs to the development team [13]. The PO also decides on release dates and content and is responsible for the profitability of the product [2]. During the planning meeting (usually every second or fourth week), the product owner presents a prioritized product backlog. The highest priority items from the backlog are then detailed in a sprint backlog by the developers. The development team is responsible for designing, testing, and deploying systems. In Kanban and XP, the PO role is not defined but similar activities are performed. In addition to these practices, Sverrisdottir et al. [14] found in their survey that POs use several additional project management practices.

When there are several teams in an organization (e.g., large-scale agile), POs often form PO teams to gather and prioritize inter-team requirements to solve conflicting and competing business needs [13]. The POs on these teams can either share the responsibility or be responsible for a subset of product features [15]. Bass [13] described the PO role in large-scale as a complex one with a broad set of responsibilities and identified nine different functions: architectural coordination, assessing risk, and ensuring project compliance with corporate guidelines and policies. Further, Berntzen et al. [16] found that there are differences in coordination both amongst POs and between POs and their teams. This may be due to differences in coordination preferences among the POs, different routines in a team, and different understandings of goals. Berntzen et al. [16] also argue the POs need to invest in building good relationships for effective coordination among them. They suggest regular knowledge-sharing activities and retrospectives focusing on improving coordination, strengthening shared knowledge and goals, and reinforcing mutual respect and trust within the PO group.

2.2 The Product Manager Role

Product manager is a role uniting technical and business perspectives in developing software products to provide value to the customer [9]. Product management has been existing since its adoption at Procter &Gamble in the 1930s [17] but did not become popular in software organizations until the late 1990s (aka software product management) [7]. The academic and industrial knowledge on the topic is summarized in the software product management body of knowledge (SPMBoK) described, for example, in [7]. This framework encompasses 38 activities within seven functional areas that product managers are said to be involved in. PMs participate in strategic management, are responsible for product strategy and product planning, and orchestrate development, market, sales, distribution, and service and support. Based on this framework, Maglyas et al. [9] identified 12 activities that product managers are engaged in practice, where vision creation, product lifecycle management, roadmapping, release planning, and product requirements engineering are described as core activities (see Table 1 for the definitions). In addition to the core activities, the authors describe other activities that the product manager may be involved in but that can, in practice be delegated to other functions. These are portfolio management, product analysis, product launches, product support, and product (software) development. Finally, Springer and Miller [18] compared product managers across several companies and summarized responsibilities that were the same regardless of context: defining goals, proposing solutions, prioritizing projects or tasks, user research, analysis of requirements, market analysis, stakeholder management, cooperation with the development team.

Table 1. Core product management activities with definitions from [9]
Full size table

This review shows that the product manager’s responsibilities described in the academic literature do not necessarily reflect how product managers act in agile companies (e.g. described in Inspired [6]). Specifically, it does not explain how to integrate product discovery and delivery, which is crucial for creating the desired products [5]. Further, the product manager responsibilities described by the academic literature so far are quite broad and may overlap with other roles. For example, some authors consider product manager and Product Owner to be similar role roles [19]. On the other hand, it is argued that while a Product Owner is a role within the Scrum framework, whereas product manager can be adopted regardless of the framework, and that covers a much broader range of responsibilities [20]. A product manager can sometimes assume a Product Owner role, but this may hinder her from fulfilling other obligations (such as market analysis and product strategy) because PO tasks require intensive interaction with the development team [20]. In large-scale agile, there is no agreement on how and whether a product manager role should be applied. On the one hand, SAFe recommends that PMs be responsible for vision, roadmap, and features to meet customer needs [12]. On the other hand, LeSS outlines the necessity of the product owner to look more outward than just managing the backlog, thus essentially recommending expanding the Product Owner to being a product manager [21]. Nevertheless, the research on large-scale agile has not looked into the particulars of the PM role but focused more on the challenges and success factors of the introduction of the frameworks [10, 11]. For example, it has been documented that product managers can overrun POs when it comes to prioritizing new features [15]. We have thus conducted our own study to examine how the PM role is practiced agile.

3 Methods and Case Description

Our overall research strategy is a multiple case study. We chose this strategy because we were following up the companies for several years and had access to various data sources that allowed for deep insight into the company contexts. We collected and analyzed data in four Norwegian companies that applied agile practices (see Table 2 for an overview of the practices). Company A is a large, globally distributed company focusing on maritime services. Company B is a technology and investment company in digital product development. Company C is a financial services company that offers pension, savings, insurance, and banking products to both the private and the business markets. Company D is a leading app developer and content platform focusing on mobile phone personalization and entertainment.

Table 2. Overview of agile practices and data collected in the case companies
Full size table

The primary data sources for this study were interviews with product managers (Table 3) triangulated with other data sources (see Table 2). Interviews ranged between 40 and 90 min and were recorded and subsequently transcribed. All PMs were asked to describe their products, areas of responsibility, work routines, and challenges.

Table 3. Overview of the informants.
Full size table

The data were analyzed by the first and the second authors using NVivo version 1.6.1. The analysis approach was thematic analysis. The authors first coded all the transcripts in searching for the instances that had to do with the activities of product managers, which resulted in 748 initial codes. The codes were subsequently grouped into higher-order sub-categories (e.g., leading product teams, product monitoring, and adjustment). Finally, we grouped the sub-categories to achieve a logical structure and formulate the overarching categories of activities.

4 Results

Our data analysis resulted in three overarching categories of PM activities: 1) those related to the products, 2) related to the product teams, and what we coined 3) supporting activities. We will now describe all the product management activities with the respective quotes in detail (see Table 4 for the total number of quotes per category).

4.1 Product-Related Activities

This category encompasses activities related to developing new products, improving the existing products, and formulating the product strategy.

Product Discovery.

A significant aspect of product management was related to exploring new products and business models, something we labeled product discovery. Activities in this category could be further grouped into product ideation and idea evaluation. Product ideation concerned formulating and/or collecting new ideas for products (companies A, B) or features (D). In companies A and B, the product managers came up with new ideas and pitched them internally to receive feedback and potential opportunity for subsequent idea evaluation. In company B, the product manager shared his idea to attract internal support: “I came up with an idea and presented it at an internal forum receive feedback” (I5).

Table 4. Number of codes per product management activity in the case companies
Full size table

Idea evaluation comprised examining the market fit for new ideas typically through the use of minimal viable products (MVP) at different stages (e.g., mock-up, working prototype, pilot version of the product). Exemplar activities in this sub-category are gathering user feedback on the MVP with the purpose of evaluating whether there exists the need for the product and whether the product can create revenue. A PM from company A described: “We build something that is cheap to build, which is fast to build, and then we will test our assumptions that it will give value for the customers and that they are really willing to pay for this” (I4). Idea evaluation is happening hand in hand with the product team (e.g., UX designers and software engineers) that collaborates with a PM to develop a first working prototype and then incrementally adjust it according to user feedback.

Product Monitoring and Adjustment.

If product discovery relates to exploring new products and features, product monitoring and adjustment encompasses activities directed to the existing products and product portfolios. These activities were characteristic of companies C and D, where PMs worked primarily on improving the existing products. Typical examples from this category were participating in joint planning and coordinating events to evaluate the current state of the products and set priorities and product goals for the subsequent period. KPIs were often used to track the product performance and report on the planning events. In terms of formulating and communicating priorities, roadmaps were often-applied. PMs in the large company C felt bounded by the roadmaps they committed to because they needed to “please” all internal stakeholders who influenced the prioritization. At the same time, PMs in a much smaller company D were more flexible in the ways they applied their roadmaps. Product manager I9 said: “It’s really unlikely to get through that roadmap exactly as it is, then you’re doing something wrong. So, it’s nice to have ideas and to have a plan on what you want to work with, and to be able to present that to the rest of the company. But it’s on the premise that this will change” (I9).

Strategic Vision Creation.

For the product managers to guide their product discovery and monitoring and adjustment activities, they need to outline the strategic vision for their product. These activities were typical for companies A, C, and D as they had established business goals. In companies A and C, the product managers utilized higher order business goals to create the strategic vision for their products. In contrast, product managers in company D were part of the business goals for the whole company. The output of this activity is typically formulated using Objectives and key-results, and KPIs. The frequency of this activity varies from company to company (from annually in C and D to a 5-year horizon at A). A PM from company C outlined: Our company has some fluffy overarching business goals. We are using those to formulate our objectives based on those goals. The objectives are set on a one to two-year basis. We then define measurable key results for the next quarter” (I7).

4.2 Activities Related to the Product Teams

The work of the product managers did not stop when UX designers and developers worked on the product. The PMs took on multiple leadership responsibilities to ensure that the development of the product was on track. We identified four areas of the team leadership activities across the case companies: Coordination activities, process lead, support teams delivery, and individual follow-up.

Support Team Delivery.

The PMs took an active role in supporting the teams throughout the various stages of product development. PMs in all companies were involved in discussions and dialogs with the UX designers and developers, ensuring that the business, design, and technology aspects were considered. Product managers also communicated goals by presenting them to the product teams. Some PMs were also collecting feedback on the goals and how to measure their success (e.g., key results) from the team members. They did not only monitor the development progress but worked together with the teams. In companies C and D, the PMs collaborated with the product owners on the backlog and formulating acceptance criteria. I9 described: “I work really closely with the product owner and try to bring him in quite early to the discovery process. Once something goes into development, he’s the one who’s responsible for keeping on track”. However, one PM from company D was clearly acting like a Product Owner and took full responsibility for the product backlog. She explained: “As a product manager, I am not doing anything different from when I was a PO. Because it’s the same; your main goal is to ensure that your product goal as planned” (I10).

Process Lead.

PMs in all case companies took on a process lead role by structuring the work process of the product teams (e.g., running agile meetings (company C), arranging kick-offs for new products and features (company D), helping to find better ways to collaborate (company C), coaching (company C) and setting up and leading new teams (company B and C). PMs in company D had the team lead responsibilities ensuring the team was motivated and worked on improving the development process. She said: “I work on the process and how we can improve it” (I10). As shown in Table 4, activities in this sub-category did not occur equally frequently across the case companies. In companies C and D, the process lead aspect of the product management role was more prominent. For example, in C, the PMs took responsibility for finding the best way for teams to come back from the home office at the end of the COVID-19 pandemic. PM I8 said: “We chose Wednesday as an office day based on a team survey. On Tuesday, we have a mix of work from home and office” (I8).

Individual Follow-Up.

In cross-functional product teams, members are highly specialized in their tasks, from designers to backend developers. PMs took responsibility for following up with individual team members by running one-on-ones (company C and A), supporting new team members (C), and even monitoring the members’ emotional state (company D). For example, a product manager in D set up a tool for tracking the team’s health. She explained: “You have like battery pictures, and every team member should indicate if he feels fully charged or empty” (I10).

4.3 Supporting Activities

Apart from being responsible for the products and product teams, the PMs engaged in activities that helped them successfully fulfill their other tasks, which we called supporting activities.

Acquiring Resources.

Many PMs took responsibility for acquiring both financial and human resources to fulfill the product goals. In company B, product managers were actively acquiring external financing for their new products. They were also competing with other PMs and functions in the company to attract the software developers and convince them to work on their products. In big companies, PMs were also attracting resources, normally by contacting internal stakeholders (A7) to allocate additional budgets or software workforce. In A and C, which were large-scale organizations with independent software units, the competition for developers was even stronger. One product manager described how he had to “fight” for the software developers: “I had just to threaten that I would go extremely high in the organization if they did not give me the software resources, so I received them at the end (laughs)” (I4).

Collaborating with Other Product Managers.

Such activities played an essential role for the product managers who relied on each other to coordinate, exchange knowledge and experience, and sometimes solve the problems together. PMs in companies C and D coordinated their collective effort through regular steering meetings. The product managers expressed several challenges regarding their roles and how to perform their tasks. They believed that discussing with other PMs could help. Companies A and C had formalized communities of practice for the product managers where topics related to the role were discussed. In contrast, D had an informal CoP that did not have a specific structure or agenda. A product manager from C said, “Lean coffee is a place to discuss methods and how we work together. We nominate topics before the meetings and arrange it every other week” (I7).

Engaging Internal Stakeholders.

Product managers often link the product teams and other functions (e.g., finance, legal, sales, and marketing) or members of multiple product teams. In companies C and D, it was crucial to consider the stakeholders’ interests because they partly constituted an input to what the product teams were supposed to deliver. For example, I4 from company A took charge of multiple delivery teams to develop and integrate the new product into the existing ecosystem. He arranged coordination meetings twice a week where three different teams met for 15 min. Multiple products in company A were based on internal and external data for both the data scientist and the product managers to understand how the data should be contextualized. A product manager explained: “The data scientist had competence on the things I did not know. And a fantastic ability to understand the business context, not only the technical data parts” (I3).

4.4 Activities Across the Companies

We have observed that the frequency of product managers mentioning the activities varied from company to company which can partly validate our findings. As can be seen in Table 4, Product discovery (A1) was often mentioned in A, B, and D, but not in company C. This corresponded well to our observations and collected documents from the companies, as both A, B, and D were heavily focusing on new products and services, whereas company C mainly was concerned with the evolution of the existing services. This is also supported by the frequent mentioning of A2 (Product monitoring and adjustment) in company C. At the same time, A2 was not so frequent in companies A and B, indicating that the product managers were not involved in working with the existing products (because the company did not have a holistic product approach to the current portfolio). In company B, all products were relatively new since it was a venture builder; thus, there were no activities identified as product monitoring and adjustment (A2). Another striking difference is that A7 (engaging internal stakeholders) was mentioned more often in company A than in all other companies. Although this can partly be explained by the high number of interviews in that company, it is also worth noting that company A is very large and has only a short history of product management, where the product managers were very new to their tasks. Therefore, PMs had to engage internal stakeholders (A7) for collaboration, validation, coaching, and, not the least, for acquiring resources (A9). Finally, acquiring resources (A9) was described as a PM activity in all companies except D probably because, in that company, the product teams were fully dedicated to their respective products, which was not always the case for the other cases. In A and C, software developers could sometimes be moved from team to team because the software resources were insufficient. In B, PMs were competing for the interest of the developers, who could be involved in the products part-time.

The relationships between the three categories are visualized in Fig. 1. Product discovery is at the center of what a PM does. Product discovery iterates between product ideation and idea evaluation, which happens in close collaboration with the product team (arrows toward the team activities). Product discovery contributes to strategic vision creation and is also defined by it. Finally, product discovery creates the need for supporting activities (e.g., acquiring resources), which mobilize organizational resources to achieve optimal product outcomes.

Fig. 1.
figure 1

Product manager activities

Full size image

5 Discussion

The adoption of product management is growing, and the practice is used by companies like Google, Amazon, Facebook, and Microsoft. However, there is a lack of research on how the product manager role is practiced in agile organizations. Therefore, we have described what activities the product managers performed in four agile companies. We will now answer our research question, “How is the product manager role practiced in agile companies?” by discussing the three groups of activities described in the Results section: product-related, team-related, and supporting activities.

5.1 Product-Related Activities

The core activities of the product managers in our study were related to discovering and developing the products (activities A1, A2 in Table 4). While the PO role in Scrum is about gathering and prioritizing features [1], the product managers in our cases focused primarily on formulating the hypotheses on which features should be developed and then testing these hypotheses to provide a further direction and insight for the product teams. Instead of believing that the customer requirements exist upfront and should only be gathered, as POs would do, our PM would first ask whether the features are needed in the first place (Activity A1.2). Thus a lot of the effort of product managers in our study was dedicated to hypothesis formulation and testing in close collaboration with both the users and the product team, which is the essence of the Lean Startup [4] and dual-track agile [5]. These PM activities also remind what is described by the SAFe-framework, where the PMs are responsible for “defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle” [12] The PMs were working in this way both when it comes to new (A1) and existing products (A2) in the companies of different scale. This highlights that product discovery can be applied in most organizational contexts.

In addition to discovering and developing the products, product managers in most companies were involved in formulating the strategic vision for their products/product areas and even overall business strategies of their companies (A3: Strategic vision creation). This is in line with the concept of BizDev and the idea that integration between business strategy and software development is needed in the same way as between development and deployment [3]. A model for continuous experimentation [22] also suggests that product and business strategy should be informed by the results of systematically testing the product assumptions.

Earlier research on product management described roadmapping, release planning, and product requirement engineering as separated activities [9]. In contrast, we found that these activities are not always possible to differentiate in the agile context because they are all part of product discovery. This is in line with Fabijan et al. [23] who highlight the importance of evolving the continuous experimentation approach from the ad-hoc approach in new products to a more targeted experimentation for established products. In the same way, development of the existing products (A2: Product monitoring and adjustment) required both portfolio management, product lifecycle management, and roadmapping that are all part of the same activity (e.g., planning events and product steering forums in companies C and D). Therefore, we believe our description of product manager activities better fits the PM practice in agile firms compared to the earlier frameworks (e.g., described in [7]).

5.2 Team-Related Activities

We found that product managers had several responsibilities toward the product teams, including supporting their delivery (A4), following-up individual team members (A6), and being process leads (A7). These activities are somewhat similar to those of a Product Owner. POs are typically involved in steering the delivery of the teams by deciding on the release date and content and prioritizing the product backlog [2]. We found that in one case (informant I10) a PM who earlier was a PO, continued to identify herself as PO and was assuming PO responsibilities (e.g., managing the backlog, formulating the requirements). However, another PM, who had not had experience with agile before, was clearly distinguishing herself from a Product Owner. She talked about a PO as her partner whose responsibility was to make sure that the tasks were “on track.” This shows that some PMs can confuse these two roles because many agile practitioners are less familiar with the PM-role. While some companies introduce the role due to its increasing popularity, the content of the PM and the PO-roles may overlap. The inconsistency of how much the PM role is similar to that of a PO can be explained by the size of the company. Earlier findings suggest that product managers can assume a PO-role in small companies because they have fewer responsibilities around steering the product [20]. However, other sources describe PO and PM as two distinct roles that sometimes even compete with each other [15]. We can conclude that the PM-role can partly overlap with that of a PO, but that the PM-role is much broader, as we have identified a plethora of PM activities that a typical PO does not cover.

An example of such activities of PM is functioning as process leads (A7) and even following-up team members (A6). We were surprised to find out that all PMs were so attentive to their teams given that earlier literature on product management argues that a PM should not have responsibilities toward teams [7, 20]. In contrast to this, PMs in our study reminded us of Scrum Masters or agile coaches [24] in that they took responsibility for the team goals, climate, and process structure.

We found that many product managers defined goals for the product teams (A4). These findings correspond well to what had earlier been described by both managements literature [7, 18] and agile practitioners (e.g., the SAFe-framework [12]). However, the fact that only certain PMs involved product teams in the goal-setting (e.g., by formulating Key results) is alarming. Moe et al. found that if a process lead does not involve teams in goal setting, team autonomy may be reduced [25], which jeopardizes the agile principles. Autonomy is also crucial when new products are developed inside established companies [26, 27]. We can thus recommend that product managers in agile companies collect the teams’ feedback on the team goals.

5.3 Supporting Activities

While the PO collaborates with customers and other POs, in our case, the product managers acted more as negotiators that took into account the ideas and interests of various internal stakeholders (A7) and sometimes convinced them to allocate additional resources (A9). We found that engaging internal stakeholders was especially important in the large established company A. When developing new digital products in such companies, many functions can be involved in the product development (e.g., legal, marketing, sales, etc.) [28]. Therefore, the PMs need to collect their input on the new products. Our findings are in line with [18], who highlights a PM’s responsibility as a stakeholder manager. This is also consistent with what was described by Mikalsen et al. [29] that an agile product team needs to negotiate with several other departments and stakeholders to reduce dependencies. We thus highlight the role of a product manager as a negotiator in agile organizations.

We also found that product managers worked together and that many of them saw value in communities of practice (A8). Just as product managers in our study, Product Owners also tend to team up when they need to solve competing business requirements (e.g., in large-scale agile) [13]. Communities of practice are often introduced in large-scale agile [11], and internal software startups [30] to improve learning and knowledge-sharing. However, neither academic nor practical literature on product management (such as Inspired [6]) described such interaction with other PMs as crucial to their job. Therefore, we suggest that product managers working in agile firms allocate sufficient time to collaborate with other product managers.

6 Practical Implications

Based on our results, we can summarize some recommendations for those working as product managers. First, a PM should serve as a continuous link between business needs and software development. Our results show that this is the essence of product management regardless of the company context. Thus, we believe that all PM practices should be chosen based on whether they contribute to achieving this goal. We also see that both internally and externally communities of practice across product managers is one way to learn and teach such practices. Our next advice is for the PMs working in large companies facing organizational inertia in product development. Most likely, such inertia is what you as a product manager will and should deal with. Our findings show that successful PMs actively involve internal stakeholders and collaborate with them to achieve a more seamless product development. This implies that PMs should have a good network within their company and have solid negotiator skills. Finally, we recommend that product managers in agile companies invite their product teams to set goals for themselves (e.g., by facilitating the formulation of the so-called “key results”). Many PMs were asking the teams to formulate their own goals, which had been shown to increase teams’ autonomy and hence agility.

7 Conclusions, Limitations, and Further Work

Despite the increasing popularity of product managers in agile companies, little research exists on how this role is performed in practice. We have thus conducted a multiple case study of product managers to find out how the product manager role is practiced in agile companies. Given today’s increasing rate of PM-role adoption, our findings can provide guidance for how product managers should work. The paper’s contribution is a summary of the PM activities toward products, teams, and organizations, which is a step toward a theoretical understanding of agile product management. We found that the essence of the PM’s role in agile is to make sure that the products are continuously linked with market demand, which is in line with the concept of BizDev. The main goal of a product manager is to set up experiments that will help the product teams decide which features are needed for the new or the existing products. Besides, PMs are highly dedicated to their teams, supporting their delivery, individual members, and their overall autonomy. In this sense, the role is sometimes practiced in a similar fashion as the Product Owner (e.g., managing backlog, keeping things on track). However, the PM role involves responsibilities that a typical PO does not cover (e.g., contributing to the organizational strategy and acquiring additional resources).

This was the first academic attempt to holistically describe the role of product managers in agile companies, which is not without limitations. First of all, the study relied on a specific sample (companies based in Norway), which may reduce the generalizability of the results. We thus encourage researchers to investigate agile product management in other countries further. Second, we provided only a preliminary description of how organizational context (large- vs. small-scale, B2B vs. B2C) influences PM practices. Further investigations are needed for more conclusive results. Finally, we need to know more about how exactly the product manager role differs from that of a Product Owner. We also need to understand how these two roles may collaborate to achieve optimal product outcomes.