A Novel Software Product Manager’s Framework: A Systematic Literature Review ()
1. Introduction
The concept of product management originated in 1931 with Neil H. McElroy and was adopted in the manufacturing industry between 1940 and 1975. Product management later extended to technology companies in the 1990s with the introduction of different software development methodologies, such as Scrum, XP, Agile, and Lean (Eriksson, 2015) . The term software product management emerged in 1997, marking the beginning of its evolution (Fricker, 2012) . In Software Product Management, the product manager oversees software development, testing, deployment, maintenance, and updates. Rapid technological changes impacting software products require agility and adaptability to meet evolving customer needs and market trends.
Unlike marketing, which has a distinct curriculum in most business schools, there is no curriculum at universities for product management (Ebert, 2007) . The lack of a formal product management curriculum is a barrier to educating and selecting PMs compared to other roles. However, significant changes over the past decade in software product management and considerable research have resulted in reference sources, such as the Software Product Management Body of Knowledge (ISPMA, 2022) and the Product Management and Marketing Body of Knowledge (ProdBOK®; Geracie & Eppinger, 2013 ). ISPMA (2022) , created the Software Product Management body of knowledge based on primary research, is the most comprehensive knowledge source for software product management. On the other hand, Geracie & Eppinger (2013) provided more traditional and generic knowledge applicable to any industry, with a heavier focus on the Waterfall model and project management as a critical participant.
Product management is an essential function in every stage of the product life cycle; however, there is no common definition of the product life cycle. Levitt (1965) introduced a four-stage model of market development, growth, maturity, and decline. The model commences after the product launch in the target market. Cooper (2008) introduced the stage-gate process for ideation to launch. However, the stage-gate process does not address the post-launch phase. Stark (2020) defined product lifecycle management (PLM) as the management system for a company’s products that covers the entire product life cycle, from ideation to retirement. Haines (2014) defined the product life cycle from product strategy to post-launch performance management but did not define the retirement phase. Geracie & Eppinger (2013) provided the most comprehensive definition of the product life cycle. None of the aforementioned frameworks include a clear definition of the PM’s role in managing the product lifecycle. Instead, there are various frameworks and activities for the functions of product management. The purpose of this research was to identify the role of a software product manager throughout the product life cycle via systematic literature reviews, with the ProdBOK® product life cycle as the framework for the findings and conclusions.
Problem Statement
A top reason for product management failure is a lack of clarity in PMs’ roles and responsibilities (Springer & Miler, 2018, 2022; Zoric, 2020) . Zoric (2020) found that one of the reasons PMs quit their job was a lack of clarity in the role. A different understanding of the PM role has resulted in different job titles in organizations (e.g., PM, function manager, brand manager, product delivery manager). The different job titles have negatively impacted companies and products (Springer & Miler, 2018) . Springer & Miler’s (2022) latest research shows that the challenge still exists. As described, product managers have a cross-functional role. Therefore, it is crucial to study PMs’ activities with the traditional and proven RACI responsibility chart. The RACI chart indicates PMs’ responsibilities and accountabilities and whom to consult and inform (Smith et al., 2005) . The chart shows the complete product management role and interactions with cross-functional teams. Extant studies have focused on product management’s overall activities and NOT the product manager’s activities, resulting in confusion regarding who does what on the ground level. Hence, there is a need to conduct a systematic review to understand the extant studies in detail to fill the gap. The general product management problem is that many organizations cannot implement the product management discipline with distinct & clear PM roles. Therefore, PMs cannot work effectively and efficiently. The specific product management problem is that there is no well-defined role for software product managers working in various company environments. This study filled a gap in the literature on PMs’ roles and responsibilities in the software product lifecycle.
2. Relevant Study
The PM coordinates with the company’s cross-functional teams to align the product with organizational processes and activities (Fricker, 2012) . The PM ensures that the product and stakeholders’ activities align with the product strategy. The role involves close cooperation with marketing management for market success and with the product development team to successfully execute a product or incremental product feature for the product release. For the launch and delivery of a product release, the PM collaborates with the operations team. The PM also collaborates with sales to enable the customers to take advantage of the product’s values. In addition, the PM works with customer service and support to deliver user training, consultancy, maintenance service, and upgrades, and with legal, who provides advice regarding license use and protection and defense for the product against competitors and new market entrants.
Geracie & Eppinger (2013) identified functions for product management, quality, manufacturing, sales, marketing, legal, engineering, operations, implementation, and project management. However, this article focused on software product management and excludes the manufacturing department. This article preferred to use the Product Engineering function name over engineering, development, or product development as engineering or development may include nonproduct-related development, and product development is mixed up with the Ansoff matrix of product and market (Hague et al., 2004) . The Quality Engineering function is assumed to be part of the product engineering function. Also, operations lack a clear definition (e.g., mixed up with DevOps). The PM has a limited role in operations, service and support. Hence, customer service and support are combined for the purposes of the study. With that, there are five cross-functions considered in which the PM collaborates product engineering, legal, marketing, sales, and customer service and support.
According to Maglyas et al. (2017) , the reference frameworks (Ebert, 2009; Fricker, 2012; Kittlaus & Clough, 2009; Weerd et al., 2006) contributed to the ISPMA SPM framework. The ISPMA SPM framework is the latest perspective on the organization and development of software product management. The Kittlaus and Fricker (2017) and other sources (Steinhardt, 2017; Pragmatic Institute, 2022; Geracie & Eppinger, 2013) have focused on the entire product management framework, but they often mix roles and responsibilities with other functions, such as marketing, leaving PMs in a gray area. None of the aforementioned studies have a clearly defined framework for PMs that differs from the broader framework for product management.
The Agile Manifesto and the Scrum Guide focus on software development (Kittlaus, 2012) . The Agile Manifesto is an umbrella for several methods. The Scrum Guide is the most popular, with 56% adoption (COLLAB.NET VERSIONONE, 2018) . Another vertical, called the Scaled Agile, has the same Agile principles and values but focuses on large enterprises (LEs). SAFe is the most popular scaled Agile framework (CPRIME, 2017) . Agile does not have a defined PM role, but scaled Agile does. This study uses the SAFe framework to compare a traditional PM to an Agile PM due to its popularity. The product owner role differs from the product manager, as the product owner delivers Agile values with the PM.
Agile products impact the PM role, and the product owner role is often confused with the PM role (Tkalich et al., 2022) . Tkalich et al. found that PMs’ responsibilities in the academic literature did not align with how PMs functioned in Agile organizations. The authors identified three groups of activities in which PMs engage: product-related, team-related, and supporting. Tkalich et al. argued that PMs should be a continuous link between business needs and software development, which is the essence of product management, regardless of the company context. They suggested choosing product management practices based on their contribution to achieving this goal. However, Tkalich et al. did not clarify how these activities differ from traditional PM activities. Additionally, there is no implication defined in the extant body of knowledge, such as ISPMA or ProdBOK.
Product manager roles and responsibilities vary based on company size (Maglyas et al., 2017; Springer & Miler, 2018; Tyagi & Sawhney, 2010) . Springer and Miler (2018) identified different approaches to software product management depending on organization size. In a company’s early stages, the founders and core team members share responsibilities. As the company expands, the leaders often hire dedicated software PMs. Springer and Miler (2018) suggested that product characteristics also influence the software PM’s role. For example, the B2B model requires negotiating with clients and creating additional documents for business clients. Software PMs in the B2B model use specific techniques (e.g., client workshops). In contrast, the B2C model requires understanding the users, their segmentation, sources of origin, and behaviors to adapt the product to the target group with the highest business potential. Researchers have not addressed the clear differences in PMs’ roles in various environments. Many aspects of the software PM’s role require further research, such as how software product managers interplay with other roles. There is also a need for further research on the relationship between the software PM and the product owner and the collaboration of the PM with Agile teams (Springer & Miler, 2018) . This study filled this gap through the comprehensive RACI frameworks.
3. Review Questions
The research questions were categorized with Petticrew and Roberts’ (2005) population, intervention, comparison, outcome, context framework. The population is product managers working in software organizations. Intervention is software product manager’s role, responsibilities, and accountabilities. Outcome is the framework for clarifying product managers’ roles, responsibilities, and accountabilities; the RACI framework clarifying how the role’s interplay with the cross-functional teams. Context pertains to software product companies functioning in diverse environments. Comparison is other software product management frameworks. The following research questions (see Table 1) were the center of the qualitative study.
![]()
Table 1. Research questions and motivation.
4. Review Methods
The research is based on a systematic literature review (SLR). The SLR occurred with the guidelines of Kitchenham and Charters (2007) . The reasons for undertaking an SLR include summarizing the current research, identifying gaps in the recent literature, providing a framework for positioning new research, and avoiding bias in resource selection and result representation (Kitchenham & Charters, 2007) . In this study, the SLR showed the research gaps and provided systematic frameworks to address research questions. Moreover, the product life cycle stages proposed by Geracie & Eppinger (2013) , is used to frame the product managers’ activities, given the comprehensive coverage of the product life cycle from conception to retirement. Additionally, the RACI matrix, as defined by Smith et al. (2005) , is employed to structure the responsibilities, accountabilities, and interactions of the product manager with cross-functional teams.
4.1. Data Sources and Search Strategy
A search occurred to collect literature from databases (see Table 2) to study the current state of the research. Source selection occurred based on academic preferences and resource availability. The search strings were based on the research questions and the keywords, role OR product management. Few keywords returned numerous resources related to the core topics. The sources included
![]()
Table 2. Database sources and search strings.
Note. All the data sources returned results based on the search strings. However, there were additional steps taken for the data sources: 1For the ACM Digital Library, the advance search option was selected, and the search string “role* AND product AND manage*” (without quotes) was used in the title search. 2For EBSCOhost, the following databases were used Academic Search Premier, Business Source Premier, eBook Collection, ERIC (Education Resource Information Center), and Applied Science & Technology Source. The search showed 26 results initially; when the page option was selected to 20 results per page to export citations, the website removed duplicates and showed 13 results. 3For ProQuest Central, the full-text filter was applied and excluded Trade Journals, Wire Feeds, Newspapers, Magazines, and “Blogs, Podcasts, & Websites” from the Source type.
peer-reviewed articles, gray literature, journals, conference documents, the internet, and books. Comprehensive sources were selected to reduce publication bias and perform a thorough SLR.
4.2. Study Selection
Table 3 shows each data source’s search criteria (inclusion and exclusion). The goal was to collect information for all years, all sources, full text, and in the English language only. The preliminary result contained 89 sources. Further exclusions occurred based on the duplicates, title scan, abstract review, and full article review (see Table 3 and Figure 1).
Wohlin’s (2014) snowballing technique occurred after the database searches and filtering. The Stage 6 (Figure 1) results were an initial set for the snowballing technique (see Figure 2). One of the main advantages of snowballing is that it finds further references from relevant papers. Snowball sampling involves scanning study references to identify relevant papers. The citation analysis could
![]()
Table 3. Database sources and inclusion/exclusion criteria.
Note. This table, default selection, indicates that the selection was there by default from the source, while custom selection indicates the author explicitly made the selection.
result in examining many papers, especially those with numerous citations. In this study, snowball sampling found additional resources, for a total of 13 results for the analysis as shown in Appendix B.
4.3. Data Extraction
Data extraction and synthesis occurred with Atlas.ti tool, with all copies of the full-text resources imported into the tool. Next, each article underwent analysis and coding for relevant information. The coding involved labeling information to find activities based on cross-functions and the product life cycle.
The data extracted from each paper included:
· The different produce manager roles
· PM activities
· The deliverables or outcome of the activities
· Cross-functional interactions with the product manager
4.4. Data Synthesis
4.4.1. Synthesis of PM Roles
The data extraction process showed the different PM roles used in the literature review. The roles included PM, software PM, product owner, Agile PM, internal PM, technical PM, and service PM.
1) Product Manager
Product manager is a general role for a team member who manages one or more products within an organization. Although the role can have different titles (e.g., software PM, technical PM, Agile PM), most PMs channel market needs into the organization and seek an optimal balance between customers’ needs and the organization’s capabilities. PMs play an important role in maximizing the return on an organization’s investment over the product lifecycle (Geracie & Eppinger, 2013) . PMs have a boundary role at the intersection of the market and the organization (Lysonski, 1985) . Hence, it is also called a market-facing or outbound role. So, Product Manager, Strategic Product Manager, and Market-facing Product Manager are all the same role with different titles. The software PM is a PM working in the software industry. In this study, PM and software PM were interchangeable because they have the same role. Although the Agile PM is not a different role but a PM working in an Agile environment, PMs may have different activities in an Agile environment.
2) Product Owner
There has been a PM role since 1931, when Neil H. McElroy introduced the role. The product owner role became more popular in 2001 with its introduction in the Agile manifesto. The Agile method has a clearly defined product owner role, and the PM maximizes the business value of the output of the scrum development team. In most environments, the product owner and PM have separate roles but remain linked for optimal communication. They have clearly defined and distinct tasks and responsibilities comparable to those of the strategic and technical PMs (ISPMA, 2022) . None of the sources in this study showed the distinction between the technical PM and product owner; instead, they presented the roles as overlapping and necessary in an organization. This study reveals that activities performed by the technical PM and Product Owner are almost aligned, and hence both roles are consolidated into a single role in the proposed frameworks. While the Product Owner is Agile specific role, the technical PM is a widely accepted, generic, and development-methodology-independent role.
3) Technical PM
A technical PM has a detailed understanding of a product’s technological aspects. The technical PM commonly partners with market-facing PMs to serve the market’s needs. Technical PMs spend significant time supporting the product development team. In this study, any activities which require product engineering collaboration, it is considered as technical PM’s responsibility for which Strategic PM is accountable.
4) Internal PM
In contrast to market-facing PMs, internal PMs represent products that are a component of a market-facing product with customers inside the organization (Geracie & Eppinger, 2013) . This study did not include this role due to a lack of evidence for this role in the literature.
5) Service PM
Service-oriented PMs hold market-facing positions and manage the scope of an organization’s services at all levels (Geracie & Eppinger, 2013) . This study did not include this role due to a lack of evidence for this role in the literature.
6) Product Marketing Manager
The product marketing manager role focuses on go-to-market activities, dividing the product lifecycle into separate parts as the company expands. The PM, who used to manage the entire product lifecycle, now handles prelaunch activities in the product lifecycle, while the product marketing manager assumes responsibility for postlaunch activities (Geracie & Eppinger, 2013) . Kittlaus and Fricker (2017) indicates that the product marketing manager role is separate from the strategic product manager. However, in some organizations, one person takes on both roles as a software PM or product marketing manager. This study’s purpose was to define a PM’s role as distinct from other roles. Thus, the study did not include the product marketing manager role due to the assumption that software organizations have a separate role for product marketing. Additionally, this study identifies that the PM role is not limited to pre-launch activities but also post-launch activities. There is a clear distinction found in this study between the PM and Product Marketing functions without any confusion.
4.4.2. Synthesis of PM Activities
The synthesis of the PM activities was the most exhausting task of the research. The biggest challenge was the lack of common activity namings for PMs among the researchers and authors. Therefore, synthesizing PM responsibilities and accountabilities was difficult. The first action was to find the activity naming standards most researchers and authors used. The ISPMA (2022) was the reference for categorizing the activities found in the research. Most activities fell under the ISPMA super activity name (see Appendix C). However, a few changes were made to the ISPMA activity category to distinguish product managers’ activities. For example, ISPMA’s full product management framework has an activity called development execution that falls under development (product engineering). However, supporting the product engineering team is a responsibility specific to product managers. Therefore, the activity was changed to supporting the product engineering team. Appendix C presents the activity naming standards and the rationale for changing certain ISPMA activities to focus on PMs.
Many researchers and authors considered defining a solution a technical PM’s responsibility. The technical PM shares this responsibility with the product engineering team. However, ISPMA (2022) does not have a separate category for defining a solution, as this activity falls under the product definition. With several studies, including Geracie & Eppinger (2013) , it was necessary to illuminate the activity as a separate category before presenting the product definition in the life cycle. The ISPMA does not have a category for a product’s EOL plan. Therefore, another new activity was created.
Appendix C identifies two key super activities which are not illuminated in the ISPMA (2022) . One is Identify Solution and another is product end-of-life (EOL).
The following is a synthesis of each activity, showing the accountability and responsibilities of product managers, and how they consult and inform other cross-functional teams showing clear interaction. The synthesis presents the strategic and technical activities; deliverables or outcomes; and where the activity falls in the product life cycle. The categorization of strategic vs. technical PM is based on the PM’s role synthesis in section 4.4.1. The synthesis results in the RACI framework (Table 4) and Life cycle model for Product Managers (Figure 3).
Market Analysis. According to the ISPMA (2022) , a corporation should have deep insight into trends and developments in the target markets and the competitive landscape, including competitors’ strategies. The same applies to the product level, where the product manager needs reliable information.
Market analysis, or market research, is a multifaceted task that shares commonalities with various cross-functional domains such as marketing and sales, depending on the organizational approach, whether product-led or sales-led. In a product-led organization, market research is typically done by product managers or product teams as they prioritize customer feedback in their product development process. On the other hand, in a sales-led organization, market research is usually done by sales or marketing teams, as they prioritize revenue growth and focus on selling products that align with customer demand. ISPMA (2022) indicated that market research involves aggregated market analysis with feedback on product strengths and weaknesses and market technology trends. Hence, it is the responsibility of the PM. This study focuses on the product managers operating in a product-led organization. Therefore, it will be the product manager’s responsibility to conduct market research.
Market research can be a shared responsibility between product managers, marketing, sales, and any other dedicated research team depending on the organization structure. In any case, PMs should consult marketing & sales about the research outcomes, as they will promote and sell the product respectively. Usually, leaders task PMs to perform market research. Hence, Leaders are accountable while PMs are responsible.
· PM Role: Strategic, Responsible
· Product Life Cycle Stage: Conceive (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Evolving market requirements document (Geracie & Eppinger, 2013)
Customer Insight. Creating and evolving products to meet customers’ ever-changing needs requires understanding their problems and environment. PMs work to understand customers (ISPMA, 2022) . ISPMA defines customer insight in the product planning phase. However, customers are involved throughout the product life cycle. The conceive phase involves customers in a market analysis activity to understand their pain points and validate solutions/prototypes. In the development phase, customers validate incremental delivery (sprint demo) as part of the user stories acceptance criteria, an Agile-specific activity. In the qualify phase, customers get involved in product verification/user acceptance testing, a traditional Waterfall activity. In launch and delivery, customers provide feedback and complete a satisfaction survey as part of the continuous market analysis activity. PMs connect with customers throughout the life cycle; hence they are responsible. Leaders also learn critical customer insights, so they are informed.
· PM Role: Strategic, Responsible
· Product Life Cycle Stage: Conceive (Geracie & Eppinger, 2013) . Customer insight is embedded in other activities for the other product life cycle phases as defined in the description above
· Deliverable/Outcome: Evolving market requirements document (Geracie & Eppinger, 2013)
Identify Solution. Many researchers and authors considered the defining solution a technical PM’s responsibility shared with the product engineering team. However, ISPMA (2022) did not present this activity as a separate category from the product definition. Several studies included Geracie & Eppinger (2013) ; therefore, it was necessary to illuminate identifying a solution as a separate category before the product definition. In the conceive phase, after the market analysis, PMs build prototypes with high-level solution and validate them with the customers. After validation only, it seems logical to define positioning and product definition. PMs inform leaders by presenting market problem and high-level solution.
· PM Role: Strategic PM is Accountable, While Technical PM Shares Responsibility with Product Engineering
· Product Life Cycle Stage: Conceive (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Validated prototype & prioritized solution (Geracie & Eppinger, 2013)
Positioning and Product Definition. According to the ISPMA (2022) , positioning is an approach to communicating a product to potential customers. For a software PM, defining the relevant market is a key part of product positioning done with marketing. The positioning also includes the selection of sales channels through which target customers may be reached. ISPMA includes the go-to-market approach as a part of positioning. Positioning is relevant to marketing and sales. The product manager’s responsibility is to define the initial value proposition with the product definition. Afterward, the PM develops the positioning into the go-to-market strategy with marketing and sales. Product positioning generally involves product naming, product definition, value proposition or product unique differentiation, key customers and partners, and the sales channel.
As part of the product strategy, the product definition presents the product vision without a full specification. The product definition guides the product team in decisions about the product scope and requirements. A high-level product description can be the basis for marketing material (ISPMA, 2022) . PMs should work on the product definition while considering the company’s compliance guidelines (ISPMA, 2022) . Similarly, Geracie & Eppinger (2013) presents the product definition as consisting of the preliminary product requirements, including the user experience definition and requirements validation. ProdBOK also indicates how to perform competitive product analysis during product feature prioritization, which differs from the competitor evaluation during market research and occurs at the organization level, not the product level. The product manager is responsible for the product definition in the RACI chart. However, the PM should consult marketing and sales to review the product definition before full-blown specification and development. PMs should also consult those in marketing for product naming to frame the positioning statement (Geracie & Eppinger, 2013) . Geracie & Eppinger (2013) indicated that identifying potential solutions involves consulting product engineering for the product/solution architect. It involves technical expertise, then they are responsible for leading the engagement. Tkalich et al. (2022) indicated that product owners in Agile handle architecture coordination.
· PM Role: Strategic PM is Accountable and Responsible, while Technical PM only Responsible for Product definition
· Product Life Cycle Stage: Conceive (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Product value proposition and positioning statements, evolving PRD in Waterfall (Geracie & Eppinger, 2013) or epic definition in Agile (SAFe, 2023)
Cross-Functional Collaboration. ISPMA (2022) has a wide category for ecosystem management, which addresses the roles of the players in relevant ecosystems who manage relationships with partners and external stakeholders. There was no common consensus or clarity on this activity naming. Many sources have different names used for this activity, including stakeholder management; cross-functional teams; and engagement with internal and external stakeholders, including customers and partners. SAFe (2023) indicates that product managers provide support and enable key functions in the operational value stream to realize the full value of every release. The most common name was cross-functional team, which appeared appropriate for a product manager who collaborates with other functions (marketing, sales, legal & compliance, product engineering, customer service and support) throughout the product life cycle.
· PM Role: Strategic, Responsible
· Product Life Cycle Stage: PM handles cross-functional collaboration throughout the product life cycle stages
· Deliverable/Outcome: Product charter with role and responsibilities (Geracie & Eppinger, 2013) ; enable end-to-end operations (SAFe, 2023)
Sourcing. According to the ISPMA (2022) , a software PM ensures that the resource requirements from the product strategy and plan can be fulfilled. A software PM, usually in close cooperation with the line managers, ensures that the resource requirements from the product strategy and plan can be fulfilled. Software PMs identify resource gaps and constraints and predict upcoming resource shortages to enable timely action. Geracie & Eppinger (2013) presented sourcing as a part of the development plan under the project management activities. Geracie & Eppinger (2013) focuses on the traditional Waterfall methodology and the project management aspect. In Waterfall, the Project Manager handles resource management or acquisition. SAFe (2023) does not indicate who should handle the resource management or acquisition. Product managers often work with the responsible line manager, typically the development manager, without the project manager on the resources needed. An external website identified that poor resource planning is the top disadvantage of the Agile (Lynn, 2023) . Tkalich et al. (2022) identified that PMs in many companies compete with each other to acquire resources. In any case, Product Managers are accountable for resourcing, while product engineering is responsible for hiring as per the given budget, and Leadership is consulted for Approval.
· PM Role: Strategic, Accountable
· Product Life Cycle Stage: Plan (Geracie & Eppinger, 2013)
· Deliverable/Outcome: resources acquired (Geracie & Eppinger, 2013) ; buy vs. build decision (Kittlaus & Fricker, 2017)
Financial Analysis. According to the ISPMA (2022) , a software product manager aims to achieve sustainable success over a product’s life cycle. Sustainable success tends to be an economic success, as the profits generated indicate. The product manager puts together pricing, revenue, and cost in a financial business case. The PM consults the marketing or pricing manager (if available) for pricing, product engineering for the cost to build, and sales for revenue forecast. The PM influences the pricing determination in product-led organizations, however, in the Sales-led organization, it may be sales that drive the pricing. In software products, marketing has less influence on product pricing. SAFe (2023) indicates that the PM finds economically viable solutions with more value than costs. However, the business owner creates a lean business case containing financial aspects such as cost and revenue forecasts. If the business owner is not in a separate role, the product manager handles financial analysis in Agile.
· PM Role: Strategic, Responsible
· Product Life Cycle Stage: Financial analysis is an evolving activity throughout the product life cycle
· Deliverable/Outcome: Evolving financial business case (Geracie & Eppinger, 2013)
Legal and Compliance Management. Geracie & Eppinger (2013) and other sources did not provide legal and compliance management details but briefly addressed the need for legal contracts and documents. ISPMA (2022) suggested that software PMs are usually not legal experts and do not have to be. However, legal risks can significantly impact a product’s success. Therefore, PMs should remain aware of and take action to avoid or mitigate legal risks. PMs can turn to legal experts for guidance but should know the important questions to ask the legal experts (ISPMA, 2022) . PMs introduce the legal activity for the product assessment, thus legal is consulted and responsible for the assessment. The product managers and legal consultants work together to achieve the task, so both are considered responsible. Also, PMs should keep the entire team informed on critical decisions. This category includes customer contracts for acquiring products, which must be signed off on before the product launch.
ISPMA (2022) indicated that compliance involves adhering to internal or external standards and guidelines (e.g., sustainability and ethics, General Data Protection Regulation—GDPR). While working on the product definition, the PM should consider the company’s compliance guidelines. In Agile, the PM ensures compliance while enabling operations while “delivering the value” (SAFe, 2023) . SAFe also suggests that the product owner ensures compliance with built-in quality criteria/story acceptance.
· PM Role: Strategic PM is Accountable, and Shares Responsibility with Legal; Technical PM or Product Owner is Responsible for adhering to compliance with the product engineering standards
· Product Life Cycle Stage: Plan and Develop (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Legal and compliance approval; contracts and legal documents (Geracie & Eppinger, 2013)
Product Life Cycle Management. According to the ISPMA (2022) , PMs focus on a product throughout its entire life cycle. Each life cycle phase has characteristics and focus areas. In the initial stages of the life cycle, the company requires investments to develop the product. During the maturity and decline phases, the product produces significant revenue with little investment. The resulting profit can provide funds for other products in the portfolio. PMs should keep cross-functional teams engaged and informed throughout the stages on deliverables and product advancement. Typically, PMs consult leaders regarding product advancement as a part of the stage-gate process. There is a common definition found for product life cycle management. Although scholars have introduced different life cycles, the fundamentals have remained the same. SAFe (2023) indicated that PMs define desirable, viable, feasible, and sustainable solutions to meet customer needs and support development across the entire product life cycle.
· PM Role: Strategic, Accountable and Responsible
· Product Life Cycle Stage: All stages of the product life cycle
· Deliverable/Outcome: Product stage approval to advance into the next stage
Roadmapping. According to the ISPMA (2022) , product roadmapping is a long-term product strategy for a series of releases to achieve business goals in the strategic time frame (i.e., between 1 and 5 years). Tkalich et al. (2022) found that PMs in a large company are more committed to the roadmaps than the smaller company, which flexibly apply their roadmaps. Typically, PMs consult with the technical PM or product owner for roadmapping. Then technical PM or product owner consults product engineering for high-level time estimation and release planning. PMs should keep the sales team informed on who can attract more customers based on the new roadmap items. Agile has flexible roadmaps that continuously change as organizational objectives, and customer needs change (SAFe, 2023) .
· PM Role: Strategic, Responsible
· Product Life Cycle Stage: Plan (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Product roadmap
Release Planning. According to the ISPMA (2022) , release planning defines the detailed contents of a forthcoming product release to maximize the value of the release in relation to the product’s success over its life cycle. In Agile, releases are broken into sprints to deliver incremental value. The technical PM or product owner works with the engineering team on the detailed release and sprint planning.
· PM Role: Strategic PM is Accountable ensuring release commitment to customers/sales, while Technical PM is Responsible
· Product Life Cycle Stage: Plan (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Release Plan
Product Requirements Engineering (or Prioritized Product Backlog in Agile). According to the ISPMA (2022) , product requirements engineering continuously identifies and manages the requirements needed to implement the product strategy and address stakeholder needs. PMs are responsible for requirements gathering from different sources (e.g., sales, support, and evolving market needs). Changing requirements throughout the life cycle are often specified in standardized documents (in Waterfall) or sorted lists called backlogs (in Agile). Sales, customer service, and support teams are consulted to understand customer pain points and generate opportunities, which turns into product requirement engineering. Technical PM helps manage requirements regarding prioritization, elaboration, and roadmapping.
· PM Role. Strategic and Technical (Both) Responsible
· Product Life Cycle Stage: Product managers manage the requirements in the planning phase for the new product development, and once delivered it becomes a continuous activity in the delivered phase (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Evolving PRD in Waterfall OR preliminary prioritized product backlog in Agile (Geracie & Eppinger, 2013)
Supporting the Product Engineering Team. Kittlaus and Fricker (2017) indicates that product engineering may work based on a project structure or a continuous mode. Product engineering organizations have various methodologies, such as Waterfall or Agile. The development methodology impacts the software PM’s work, especially the technical PM. The methodology affects how requirements are submitted for implementation and how acceptance of product deliverables is managed. With most Agile methodologies, every iteration consists of analysis, design, coding, and testing. With Waterfall, there are no iterations, but one stage or phase occurs after the other.
· PM Role: Strategic PM is Accountable, While Technical PM is Responsible
· Product Life Cycle Stage: Develop (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Product release or Sprint release
Detailed Requirements Engineering (or Define User Stories, Acceptance Criteria, and Prioritized Backlog in Agile). Detailed requirements engineering is part of the development phase. After defining the release contents, the PM submits and refines the corresponding product requirements for development (ISPMA, 2022) . The phase also includes UX development. The UX design scope and product expectations fall under the product definition activity which happens in the conceive phase. The minor UI/UX enhancements are handled as a part of ongoing development. Detailed requirements engineering is a shared responsibility of the technical PM and product engineering team. The technical PM coordinates with the UX and developers. In Agile, the product owner writes functional stories, and the product engineering team writes nonfunctional stories. The user stories contain detailed acceptance criteria, including UX considerations.
· PM Role: Strategic PM is Accountable, While Technical PM Shares Responsibility with the Product Engineering Team
· Product Life Cycle Stage: Develop (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Detailed PRD in Waterfall or refined product backlog in Agile (Geracie & Eppinger, 2013)
Product Verification (and/or Accept User Stories in Agile). The PM gets heavily involved in product verification testing as a proxy user to ensure the overall functionality. Many PMs review and prioritize quality issues to determine which issues to correct before launch. PMs may also handle formal acceptance and approval with the test team. The PM may also become involved with the customer in planning and creating user acceptance testing (Geracie & Eppinger, 2013) . In Waterfall, the customer participates in the qualify phase to validate the whole product. However, in Agile, the customer participates in the development phase to validate incremental features and in the qualify phase for the whole product verification. Typically, the quality engineering team (a part of product engineering) handles detailed product testing and ensures quality assurance, while PMs handle the whole product or release signoff. Technical PMs or product owners address user stories acceptance.
· PM Role: Strategic PM is Accountable, and shares Responsibility with the technical PM
· Product Life Cycle Stage: In Waterfall, the customer participates in the qualify phase to validate the whole product. However, in Agile, the customer participates in the development phase to validate the incremental feature (via accepting user stories) and the qualify phase for whole product verification.
· Deliverable/Outcome: User Acceptance Testing (UAT) signoff in Waterfall; user stories accepted in Agile
Operations Readiness. PMs support and enable key functions (e.g., marketing, sales, legal and compliance, customer service and support) to ensure the full value of every release (SAFe, 2023) . Product support readiness enables the support team to maintain the product after the sale. According to the ISPMA (2022) , support consists of the product-related services provided to existing customers, such as maintenance, training, operations, and the user help desk. Kittlaus and Fricker (2017) indicated that product-specific training is important to product success. The company’s sales and marketing, technical support, maintenance staff, and, if applicable, customers should receive product-specific training. In larger companies, training requires a multiplier approach. Developers and PMs conduct initial training for the staff (i.e., by training the trainers) who subsequently conduct the training. Hence, in the RACI chart, the PM is responsible for operations readiness, including training for internal groups such as product support & service, and sales.
· PM Role: Strategic, Accountable & Responsible
· Product Life Cycle Stage: Qualify (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Sales and support training, product documentation, launch plan
Orchestrate Product Launch. According to the ISPMA (2022) , product launches involve introducing a new product, version, or release to the market. The PM orchestrates the launch with the consultation of the product engineering and technical PM. The PM informs other cross-functions on the launch plan to prepare them for their responsibilities.
· PM Role. Strategic, Accountable & Responsible
· Product Life Cycle Stage: Launch (Geracie & Eppinger, 2013)
· Deliverable/Outcome: New product or release to market
Product Performance Management. According to the ISPMA (2022) , product performance management involves continuously tracking and analyzing relevant measures and taking timely action. ISPMA defines four categories of performance. Financial performance (e.g., profit and loss metrics, such as gross margin and EBIT, average revenue per customer, customer lifetime value); market performance (e.g., market share, market growth, and customer acquisition cost); customer performance (e.g., customer satisfaction score [CSAT], NPS, customer retention and churn rate); and organizational performance (e.g., time to market speed and onboarding cost). Key performance indicators (KPIs) enable continuous tracking and analysis of the product’s business performance. Ideally, KPIs address all elements of the product strategy. PMs may need to consult required teams to gather KPIs, such as marketing, sales, and product engineering. SAFe (2023) does not present product performance management as the product manager’s responsibility. However, Tkalich et al. (2022) found that product monitoring and adjustment occurred in all companies with Agile PMs.
· PM Role: Strategic and Technical (Both) Responsible. The strategic PM handles market and customer-specific KPIs, while the technical PM manages product- or data-related KPIs, depending on the development system of records.
· Product Life Cycle Stage: Delivery (Geracie & Eppinger, 2013) .
· Deliverable/Outcome: KPIs and metrics.
End-of-Life Plan. After determining to withdraw the product from the market, the company focuses on activities in a structured EOL plan. This EOL plan is the reverse of a launch plan (Geracie & Eppinger, 2013) , presenting the company’s plan for gracefully withdrawing a product from the market while minimizing the impact on customers who may use more than one of the company’s products. Legal considerations and contract terms can indicate the appropriate approach and timing for the product’s retirement. Another important factor is product support. While company leaders may choose to withdraw a product from the market, they may maintain some product support past the point of the product’s retirement. A well-thought-out plan enables customers to plan and manage their transition to alternative products (Geracie & Eppinger, 2013) . While the PM outlines the strategic EOL for customers, the technical PM outlines the technology decommissioning plan with the engineering consultants. Marketing, sales, and customer service and support functions are informed of the plan so that they can plan to sunset their activities.
· PM Role: Strategic and Technical (Both) Responsible
· Product Life Cycle Stage: Retire (Geracie & Eppinger, 2013)
· Deliverable/Outcome: Product EOL plan, then product discontinued
Portfolio Management. There were references to this activity under the PM’s role (Maglyas et al., 2013, 2017; Bekkers et al., 2010; Haines, 2014) . However, it is excluded from the PM’s framework as it was considered participative activity. A participative activity is an activity where someone else is responsible and consults the product manager for input. Leaders are mostly accountable or responsible for such activities.
![]()
Table 4. Software product manager RACI framework (SPM-RF).
![]()
Figure 3. Software product manager life cycle model (SPM-LCM). Note. Strategic PM is accountable for all activities for which Technical PM is responsible.
5. Results
The purpose of the review was to gain a comprehensive understanding of PMs’ roles, responsibilities, and accountabilities. From the product management body of knowledge (ISPMA, 2022; Geracie & Eppinger, 2013) , two common roles emerged. strategic PM and technical PM. The strategic role is customer-facing and impacts the product, while the technical role is internal, except in Agile, where it extends to gathering customer feedback during sprints. The technical PM influences team product engineering. Strategic activities require strong business acumen, customer communication, and product management skills, whereas technical activities require technical knowledge and an understanding of the development environment. The strategic PM focuses on product discovery through continuous market analysis, while the technical PM focuses on continuous delivery.
For this SLR, identifying responsibilities was a complicated and exhaustive task, as previous scholars had different names for the same responsibilities, activities, tasks, core activities, supporting activities, deliverables, and outcomes. The literature does not clearly show the distinct responsibilities of strategic and technical PMs. Therefore, this in-depth literature review and synthesis involved mapping and identifying the various activities aligned with the ISPMA super-categories. The extant research was used to differentiate the PM’s specific activities from the product management frameworks. As a result, the Software Product Manager Life Cycle Model (SPM-LCM) was developed to address the first research question (see Figure 3). The extensive data synthesis also produced the Software Product Manager RACI Framework (SPM-RF) to address the second research question (see Table 4).
In summary, the findings introduce two innovative frameworks which frame the Software Product Manager’s holistic framework: SPM-LCM and SPM-RF. These two frameworks clarify the roles, responsibilities, accountabilities, and how it interplays with other cross functional groups, offering a comprehensive understanding of software product managers’ functions.
6. Discussion
6.1. Principal Findings
This SLR found 19 key responsibilities for PMs. This study found that a technical PM has similar responsibilities as a product owner, a role in the Agile methodology.
Geracie & Eppinger (2013) indicated that the product marketing manager assumes responsibility for postlaunch activities. However, this study found that the marketing team may get involved with the PM with some prelaunch activities, such as product naming, branding, positioning, pricing, marketing, and product launch alignment. ProdBOK indicated that product marketing is an active function of continuously assessing the 4Ps of marketing (i.e., product, place, promotions, and price). The marketing team can consult the PM on product marketing; however, product marketing falls outside the PM’s accountability and responsibility.
The RACI framework (see Table 4) shows that PMs consult the sales team more than any other department after product engineering. Therefore, sales and engineering are the two main interfaces for the product team. PMs consult the sales team during the product positioning for the sales channel selection, sales readiness (in operations readiness), financial analysis (for revenue forecast), roadmapping to sell a forward-looking product, product requirements for engineering to gather feedback from sales, product performance management (to measure sales/revenue growth), and market analysis (during growth phase) to understand customer pain points and challenges.
This study found that the PM interacts with customer service and support teams to prepare them for contractual obligations (e.g., service-level agreements), maintenance, technical support, and onboarding and service after the sales transition. The PM also interacts with legal and compliance teams regarding company policies, regulatory policies, data compliance, and customer contracts before product launch to ensure legal compliance. Also, the PM performs legal assessments during the product end-of-life (EOL). The PM interacts with the engineering function the most, as shown by the RACI framework (see Table 4).
6.2. Meaning of Findings
The study included the first product management framework to show the distinct PM role. This study presented the PM’s roles, responsibilities, and accountabilities.
The study synthesizes the primary research from many sources on the PM’s role and responsibilities, how other factors impact it, and how a PM role interacts with other cross-functional areas. Hence, this SLR should be considered the latest view of all the related studies mentioned in the related study section.
Product EOL is a blind spot in many frameworks (Jansen et al., 2011; Geracie & Eppinger, 2013) . Therefore, other frameworks should include EOL activity to be inclusive. This SLR found no research on the role of the technical PM; therefore, the study provided a baseline for studying that role and how to combine it with the Agile product owner role. The framework in this study did not conflict with other product management frameworks. Extant frameworks focus on product management as a whole and not on PMs.
Maglyas’s (2013) role framework was only partially useful for this study. The role framework presents the four software PM roles: leaders, strategists, experts, and problem-solvers. However, only leaders and strategists were roles relevant to the software PM role. Also, Maglyas’s framework does not address the technical PM’s role.
This study with the SPM-RF filled the research gap Springer and Miler (2018) identified on how software PMs interplay with other roles. Tkalich et al. (2022) suggested further research on Agile PMs. This research with SPM-RF suggests how Agile values impact the PM role. Jansen et al. (2011) identified a blind spot regarding EOL in the product management framework. Therefore, this study with the SPM-LCM addressed the blind spot.
Bekkers et al. (2010) presented the 68 capabilities needed for software product management maturity at a software product organization. Many sources have confused the maturity model with 68 total activities. The Kittlaus and Fricker (2017) indicates the activities of a product management framework as a whole. This study focused on the PM’s activities to provide clarity to the community.
7. Conclusion
This research significantly contributes to enhancing clarity, performance, and collaboration within teams and organizations by providing valuable insights into software product managers’ roles. The frameworks introduced—SPM-LCM and SPM-RF—serve as practical tools to improve the understanding of PMs’ tasks across the product lifecycle, ultimately promoting product success and the well-being of product managers.
Recommendations
Market analysis is a critical business function that involves various departments such as product, marketing, and sales, depending on the type of organization—product-led or sales-led. Future research could examine the impact of market analysis on the role of product managers in sales-led organizations, illuminating how they work with marketing and sales teams in the market analysis process.
The interaction between PMs and project managers in the Agile methodology remains unclear, as Agile does not have a defined role for Project Managers. Many activities traditionally done by Project Managers are now divided between PMs and product owners in Agile. However, there is no clear mapping between the roles. For example, who is responsible for resource planning in Agile remains unclear. Resource planning is the Project Manager’s responsibility in Waterfall. Additionally, the role of a business analyst remains undefined in Agile, as the product owner and product engineering team now handle the activities traditionally performed by a business analyst. Further research could show the roles of PMs and business analysts in Agile. Future studies could also show how business analysts interact with PMs.
The product owner (the Agile role) has caused significant confusion regarding the PM role. This study was a means of clarifying the PM’s role. However, the Agile community could change the name of the product owner role to technical PM to keep the role generic and avoid any possible conflict. Due to the high number of activities for PMs, software industry leaders, especially those at SMEs, should hire technical PMs in separate roles to enhance the organization’s performance. Researchers and authors should use common terms defined in this study for the PM activities in future research to avoid confusion. Furthermore, additional investigation is advised to explore the influence of organizational factors, including organization size, product segments (B2B vs. B2C), and other relevant aspects, on the Product Manager’s RACI framework.
This study was the first to present the role and responsibilities of PMs operating in different environments. The study focused on PMs’ activity separately from the entire product management framework. The systematic frameworks in this study require validation to enhance their general acceptance.
Acknowledgements
I thank Dr. Burrell (my chair) for insightful feedback and invaluable guidance in reviewing my research. I am also grateful to Capitol Technology University for providing valuable resources on product management. My family, including my spouse and children, have provided constant support throughout this journey, and I am deeply grateful. I would also like to thank my friends for their unwavering motivation. Lastly, I appreciate all the researchers and authors who have contributed to software product management for their instrumental work in advancing the discipline.
This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors.
Appendix A
Product Management Life Cycle Model (Haines, 2014)
Note. The Product Management Life Cycle Model shown here is from The Product Manager’s Desk Reference, 3rd edition, by Steven Haines (McGraw-Hill, 2021), is also copyrighted by Sequent Learning Networks LLC, and is used with the permission of the author, Steven Haines.
Appendix B
Final Study Selection
Appendix C
Activity Mapping to Common Naming