Research Article | | Peer-Reviewed

Innovating the Future: Unveiling the Initial Iteration of the Pragmatic Framework for Product Managers

Received: 25 April 2024     Accepted: 13 May 2024     Published: 30 May 2024
Views:       Downloads:
Abstract

Context: This study introduces the Pragmatic Framework for Product Managers, a tool developed to enhance the understanding and application of product management activities. Objectives: The aim is to provide a comprehensive overview of Product Manager (PM) activities that positively impact efficiency, business growth, budget control, user satisfaction, and release processes. The framework is intended to aid decision-making, training, and clarifying the PM role, ultimately contributing to product success. Methods: A systematic literature review of 134 studies was conducted to develop the PFPM. This extensive research led to identifying and classifying 122 activities into 33 categories within 6 domains, forming a robust framework for product managers. Results: The PFPM, in its initial iteration, represents a minimal viable product of the framework. The research findings highlight the framework’s potential for future refinement, particularly in the context of software startups. Conclusion: The PFPM significantly affects software companies' product decision-making, PM training, and role transparency. It is a valuable resource for researchers and practitioners in Software Product Management (SPM), Requirement Engineering (RE), New Product Development (NPD), and innovation. The framework paves the way for future studies focused on the unique dynamics of PM activities in the software startup ecosystem.

Published in American Journal of Engineering and Technology Management (Volume 9, Issue 2)
DOI 10.11648/j.ajetm.20240902.12
Page(s) 32-50
Creative Commons

This is an Open Access article, distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution and reproduction in any medium or format, provided the original work is properly cited.

Copyright

Copyright © The Author(s), 2024. Published by Science Publishing Group

Keywords

Product Manager, PM, Framework, PFPM, Software Product Management, SPM, Requirements Engineering, RE, Innovation

1. Introduction
In the high-speed, unpredictable, and resource-limited world of software startups, early-stage ventures often find themselves operating in an environment rife with risks and challenges . These obstacles, combined with an inherent overconfidence in their survival chances lead many founders to plunge into the complexities of early product decision-making without a thorough product or market understanding. The result is often a startup with no strategic plan for product development , inefficient requirement selection processes , critical resource allocation issues , insufficient market research or business case analysis , and an overallocation of resources towards solutions that do not address any or sufficient market needs . Consequently, these startups frequently fail to achieve product-market fit and struggle to secure their first paying customers , endangering their runway and probability of success.
With the potential to significantly influence future performance , introducing improvements in early product decision-making processes is paramount. The general consensus is that there needs to be an owner of the product , and it’s typically this role the Product Manager (PM) fills. Despite the significant effort of the International Software Product Management Association (ISPMA) to develop the Framework for Product Management , it isn’t supported by rigorous academic research, nor are any other similar frameworks. Addressing this gap calls for a framework solidly built on academic fundamentals that could be used for future research.
The Pragmatic Framework for Product Managers (PFPM) could be of significant value to anyone responsible for handling the PM tasks. This could be a dedicated PM or a (co-) founder juggling it as a duo-role. Additionally, the results of this study may inform future SPM, RE, NPD, innovation, and startup research. Ultimately, the aim is to indirectly increase the probability of survival for startups and, potentially, their valuation outcomes by minimizing costly early decisions mistakes through the implementation of context-appropriate product management methods and task prioritization.
2. Related Work
2.1. Product Manager Activities Since 1983
Beyond this vague consensus, myriad tasks are associated with this role. As part of an ongoing systematic literature review of 134 studies covering studies since 1983, 662 unique tasks spanning 122 activities have been identified.
2.2. Product Managers at Startups
Considering solely the limited literature focused on the startup context (Table 1), the number of studies drops from 134 to 8 and from 122 activities to merely 45, of which 40 can be attributed to a single paper by Springer and Miler .
Table 1. Activities in Startup PM literature.

Ref.

Count Activities

Activities

3

Requirements prioritization, requirements elicitation, writing user stories

8

Requirements prioritization, requirements elicitation, writing user stories, requirements analysis, requirements selection, negotiating priorities, product validation, stakeholder communication

4

Requirements prioritization, requirements elicitation, writing user stories, requirements validation

3

Sales strategy, sales execution, development budgets

2

Requirements prioritization, product planning (incl. releases)

40

Lead, stakeholder management, stakeholder communication, communicate with development, define business model, evaluate business model, product lifecycle management, product strategy & vision, product planning (incl. releases), strategic management, project management, corporate strategy & vision, update roadmap, resource allocation, requirements management, requirements elicitation, prototyping, marketing execution, sales execution, collect customer feedback, financial management (incl. funding), resource management, go to market (GtM), forecasting, market research, manage software development, requirements prioritization, negotiate priorities, supplier management, product ideation, requirements validation, requirements gathering, data analysis, business case analysis, write product initiation document, approve development, cost estimation, development budgets, user research, requirements analysis.

7

Create a roadmap and product strategy vision; write user stories; prioritize requirements; research and development; stakeholder communication; and resource allocation.

3

Create backlog, requirements prioritization, product planning (incl. releases)

2.3. Activity Domains
The domains aim to understand in which departments or teams the identified activities might be handled. This is to make it possible in later studies to refine the actual role and responsibility level of the product manager for each activity further, even for those allocated to domains outside of the product domain.
The domains have been adapted from the ISPMA ® SPM Framework V.2.0 . Their framework is focused on product management as a whole field, not directed to the actual individual activities of a product manager. Besides that, it is focused mainly on general software product development processes, which means it covers all possible company sizes and complexities. Considering the end goal of making it more pragmatic and transparent and possibly further refining it for startups, some adaptations are made to make it more relevant to the future target audience (Table 2).
Table 2. ISPMA structure versus the Pragmatic Framework for Product Managers (PFPM) domains.

ISPMA

PFPM domains

Strategic Management

Executive leadership

Product Strategy

Product Strategy & Planning

Product Planning

Product Strategy & Planning

Development

Engineering & Development

Marketing

Marketing

Sales & Fulfilment

Sales

Delivery Services & Support

Customer Support & Success

Executive leadership is often used in the current startup literature to define the people, including the founders, to build and lead their early-stage ventures to prosperity. Therefore, this seems to be a more appropriate highest-level domain name for this framework than strategic management.
For simplicity's sake, a single product domain gets created. At this stage, there is no academic need to make a distinction, which means that "Product Strategy" and "Product Planning" get combined into a single domain with the name "Product Strategy & Planning."
Development gets extended to Engineering and Development because software engineering has firmly entered the startup vocabulary , and we want to tailor the framework as much as possible toward its future audience and not alienate any prospective users. Sales & fulfillment was renamed to the more accessible and broader name of Sales to simplify the model as much as possible.
Delivery Services & Support is an older name; in recent years, this role has been rebranded to Customer Support & Success . Therefore, considering our future audience, the domain's name gets updated accordingly.
3. Study Design
3.1. Top-Down Approach
Based on the limited research that's been done in this specific combined niche of startups and product manager activities , it is not prudent to start from the already limited set of activities from the startup literature to define the initial iteration of the PFPM. Because of this, a top-down approach in terms of data collection and analysis method is preferred. Here the overarching framework is first created based on all available research on the topic of Product Manager activities, before refining it further to specific niche contexts.
3.2. Towards the First Iteration of the PFPM
This means that this study will start with the 122 activities (see section 2.1) and the described activity domains (see section 2.3) and start from there to develop the first iteration of the framework. This top-down approach will consist of different steps (Figure 1). The setup of each step will be discussed in this section, while the results of each step will be documented in section 3.
Figure 1. Study design.
Academic validity
A survey was created to gather the required data to develop this tool. The goal of this survey was to generate domain-activity pairs, but one of the most important characteristics of this framework is its academic validity. Taking that into account, it means that the academic quality of the respondents' input needs to be ensured. Every one of them had to answer some demographic questions (Table 3) and be ensured of their GPDR rights and anonymity. Based on this data, only those respondents with academic experience (PhD holder or PhD candidate) and within one of the fields of interest (RE, SPM, NPD, or startups) were retained and therefore considered qualified respondents.
Table 3. Academic validity: Demographic questions.

Question 1: What is the highest degree you obtained?

Options: High school, Bachelor's, Master's, MBA, PhD student, PhD, Executive. I do not want to share this information.

Reasoning: Only respondents having answered Ph.D. student or Ph.D. will be retained for analysis to ensure the academic envisioned benchmark of the study.

Question 2: How many years of research experience do you have within the RE, NPD, SPM, or startup domain?

Options: number (number of years of experience)

Reasoning: Only respondents with relevant research experience within one of these domains will be retained for analysis to ensure the academic envisioned benchmark of the study. Those with at least 5 years of experience will be considered possible experts within the study.

Question 3: How many years of experience do you have within product roles?

Options: number (number of years of experience)

Reasoning: Only respondents with at least 5 years of experience in a product role will be considered as possible experts within the study.

Question 4: How many years of experience do you have as a product manager?

Options: number (number of years of experience)

Reasoning: It is interesting to know whether or not any of their years in a product role are also spent as a product manager because this relevant practitioner's experience should positively impact their answers.

Question 5: For how many startups did you work for?

Options: number (number of startups they have worked for)

Reasoning: It is interesting to know whether they have startup experience, considering the end goal, because this relevant practitioner's experience should positively impact their answers.

Question 6: How many years have you worked at startups so far?

Options: number (number of years of experience)

Reasoning: Only respondents with at least 5 years of startup experience will be considered possible experts within the study.

Question 7: How many times were you part of the founding team?

Options: number (number of times part of the founding team)

Reasoning: It is interesting to know whether or not they were part of a founding team because this relevant practitioner's experience should positively impact their answers.

Question 8: How many times were you the product manager?

Options: number (number of times as a startup product manager)

Reasoning: It is interesting to know whether or not any of their years in a product role are also spent as a product manager because this relevant practitioner's experience should positively impact their answers.

Question 9: What is your gender?

Options: Male, Female, I do not what to share

Reasoning: It is interesting to see whether or not there would be any gender differences, but more importantly, to make sure that both sexes are represented in this still mainly male-dominated occupation.

Additional questions regarding their product manager and startup experience are asked to make it possible to define the experts among the respondents. Once identified, they will be asked whether they would be willing to further advance the analysis of the study as experts. The rules that will define the respondents that could be considered an expert are:
1. Have at least 5 years of academic experience
2. Have at least 5 years of experience in a product role
3. Have at least 5 years of startup experience
Gather possible domain-activity pairs
Table 4. Pragmatic Framework for Product Managers (PFPM) domains.

Pragmatic Framework for Product Managers (PFPM) domains

Executive leadership

Product Strategy & Planning

Engineering & Development

Marketing

Sales

Customer Support & Success

After sharing demographic data (see section 3.2), the respondents have to create 122 domain-activity pairs. For every activity, one of the domains (Table 4) or one of the following options; "I do not know for sure" and "Too generic (multiple options possible)" needs to be selected. To ensure that all of the respondents had the same understanding of the different activities, a short and easy description was added to each of the activities, see section 8, Table 13.
Statistical consensus
The data analysis to determine validated domain-activity pairs initiates by checking the availability of a statistical consensus per generated pair. Statistical consensus is defined as: 100% of the respondents agree (Figure 2.) on the provided domain-activity pair (excluding those answers that have stated that they do not know or that it is too generic), or at least having a 60% agreement, excluding those answers that have stated that they do not know, or that it is too generic), but with a minimum standard deviation of 2 (Figure 3). That ensures that the spread and difference between the highest voting pair and the others is still substantial, meaning at least double.
Figure 2. Statistical consensus, 100% agreement.
Figure 3. Statistical consensus, 60% with minimum the standard deviation of 2.
Expert consensus
During the process of expert consensus, those pairs that did not get validated via statistical consensus and checked against only the experts' answers. Here, a domain-activity pair is considered validated when there is a 100% consensus among the expert respondents in the provided domain-activity pair (excluding those answers that have stated that they do not know or that it is too generic) combinations.
Expert discussion, statistical consensus
For the remaining domain-activity pairs that have not yet been validated, a digital workshop is conducted where the researcher discusses and moderates the experts' answers, sharing relevant insights and research to facilitate a possible consensus. Considering the context, the benchmark to consider a domain-activity pair validated gets adjusted. There, everybody agrees when there are at least 3 valid answers, and all but one agrees, or if there is only a maximum of 2 valid answers.
Expert discussion, combining consensus
The final remaining ones combine with their closest related domain-activity pair during this digital workshop.
Grouping domain-activity to domain-category pairs
The analysis results reflect that all 122 activities have been paired with a domain. Visually adding all of them to the framework will strain the framework's readability and pragmatic value. Therefore, to make it aesthetically more pleasing and increase its practical value, those domain-activity pairs, whether single or already combined, get further grouped based on practical relevance.
Final approval by experts
At this stage, the analysis is completed, and a draft of the framework is ready for final approval by the experts. The experts will receive the most straightforward representation of the framework, meaning an overview of the domains with the grouped domain-category pairs underneath, and the more extensive version, meaning an overview of all the domains, including not only the grouped domain-category pairs underneath but also the distributed 122 domain-activity pairs underneath them. Based on the experts' feedback, any framework updates might be warranted. Once this feedback has been incorporated, the initial iteration of the Pragmatic Framework for Product Managers (PFPM) will be considered approved and ready for the next steps in its academic lifecycle.
4. Results
Figure 4 provides an overview of the evolution of the number of validated pairs throughout the study design’s steps. Going from none of them being validated to having covered all 122 out of 122 domain-activity pairs. The resulting draft was accordingly validated by the experts, resulting in the initial iteration of the Pragmatic Framework for Product Managers (PFPM).
Figure 4. Results from the study design.
4.1. Academic Validity
Table 5 provides a summary of the demographic questions. A total number of 11 respondents have filled out the survey, and all of them met the qualification criteria (see section 3.2). Considering the expert qualification criteria (see section 3.2), 3 respondents (Table 6) were identified as possible experts for the study. After reaching out to them, all of them accepted the request.
Table 5. Academic validity, demographic markers.

Demographic markers

Sex

7 males and 4 females

Education

6 having a PhD, 5 being a PhD student

Personal Description

9 academics, 2 Product Managers

Years of experience

On average, it is 11,81, with a minimum of 3 and a maximum of 30.

Currently a PM?

A single one is currently also a PM.

Experience in a product role?

5 out of 11 have previous/current experience in a product role.

Experience as a PM?

2 out of 10 have previous/current experience as a PM.

Table 6. Identified possible experts.

ID

Description

1

He holds a Ph.D. and has 15 years of experience, 6 of which are in a product role. Has been part of 4 startups, for a total of 5 years, of which he has been part of the founding team 4 times.

3

She holds a Ph.D. and has 20 years of experience, of which 10 years are as a product manager. Has been part of 3 startups for a total of 5 years, of which she has been the PM twice and part of the founding team once.

6

She is a PhD candidate (ready to defend) in Product Management. At the same time, I am a Product Manager at the market leader focused on product management software with 10 years of experience in product roles, of which 9 are as a Product Manager. She has been part of 3 startups for 6 years, of which she has been the PM twice, but never part of the founding team.

Besides the basic qualification criteria, it is also interesting to study whether or not they have some valuable practitioner experience, which should add to the overall quality of the study. Here, this is the case. Out of all respondents, 64% (7/11) have been active in a startup, of which one has been active in 4 and 2 others in 3. They also share, on average, 5 years of startup experience, while the overall average of the group is 2. Out of the respondents, 5 have been part of a founding team at least once, of which 3 were the PM.
4.2. Statistical Consensus
When doing the statistical consensus analysis (see section 3.2) of 1.342 pairs, table 7 shows the top 10 pairs, while that 65 out of the 122 domain-activity pairs got validated accordingly (see section 8, Table 14).
Table 7. Statistical consensus, results.

Activities

Consensus

St. Dev.

Domain

Customer support

100%

0.00

Customer Support & Success

Market research communication

100%

0.00

Marketing

Product planning (incl. releases)

100%

0.00

Product Strategy & Planning

Product strategy vision

100%

0.00

Product Strategy & Planning

Sales execution

100%

0.00

Sales

Marketing copy

91%

4.50

Marketing

Marketing research

91%

4.50

Marketing

Market research

90%

4.00

Marketing

Sales Analysis

90%

4.00

Sales

Sales planning

90%

4.00

Sales

4.3. Expert Consensus
Table 8 shows the additional 11 pairs confirmed after finishing the expert consensus analysis (see section REF _Ref155123544 \w \h \* MERGEFORMAT 0). These additional pairs bring the total to 76 out of 122, or 62% of all potential domain-activity pairs.
Table 8. Expert consensus, results.

Activities

Consensus

Domain

Packaging

100%

Marketing

User research

100%

Marketing

Distribution management

100%

Sales

Define market priorities

100%

Product Strategy & Planning

Competitive analysis

100%

Marketing

Negotiate requirements

100%

Product Strategy & Planning

Supplier management

100%

Product Strategy & Planning

Negotiate priorities

100%

Product Strategy & Planning

Inspire

100%

Product Strategy & Planning

Sourcing

100%

Product Strategy & Planning

Tactical planning

100%

Engineering & Development

4.4. Expert Discussion, Statistical Consensus
Table 9 shows the additional 25 pairs confirmed after finishing the expert discussion statistical consensus analysis (see section REF _Ref155123544 \w \h \* MERGEFORMAT 0). These additional pairs bring the total to 101 out of 122, or 83% of all potential domain-activity pairs.
Table 9. Expert discussion, statistical consensus, results.

Activities

Domain

Consensus

Votes

Requirements elicitation

Product Strategy & Planning

75%

4

Competitive research

Marketing

67%

3

Product validation

Engineering & Development

67%

3

Communication

Customer Support & Success

67%

3

Requirements gathering

Product Strategy & Planning

75%

4

Business case analysis

Product Strategy & Planning

67%

3

Define stakeholders

Product Strategy & Planning

75%

4

Evaluate business model

Executive Leadership

67%

3

Requirements prioritization

Product Strategy & Planning

75%

4

Requirements re-prioritization

Product Strategy & Planning

75%

4

Advertising execution

Marketing

67%

3

Stakeholder communication

Executive Leadership

75%

4

Brand planning

Marketing

75%

4

Development budgets

Product Strategy & Planning

75%

4

Communication planning

Product Strategy & Planning

67%

3

Pricing

Sales

67%

3

Release validation

Product Strategy & Planning

67%

3

Evaluate new requirements

Product Strategy & Planning

67%

3

Customer qualification

Sales

67%

3

Release management

Engineering & Development

67%

3

Define delivery model

Sales

67%

3

Inventory management

Sales

67%

3

Write user stories

Product Strategy & Planning

67%

1

Scope change management

Product Strategy & Planning

75%

4

Innovation management

Product Strategy & Planning

67%

3

4.5. Expert Discussion, Combining Consensus
Table 10 shows how the remaining 21 pairs got allocated, finishing all 122 domain-activity pairs. Each was combined (see section 3.2) to an activity that was at least validated in one of the previous runs to ensure internal validity, consistency, and quality.
Table 10. Expert discussion, combining consensus, results.

Activities

Domain

Requirements management

Product Strategy & Planning

Product design

Product Strategy & Planning

Go to market (GtM)

Product Strategy & Planning

Monitor and control results

Executive Leadership

Requirements selection

Product Strategy & Planning

Approve development

Engineering & Development

Process management

Product Strategy & Planning

Service management

Customer Support & Success

Risk management

Product Strategy & Planning

Branding planning

Marketing

Environmental scanning

Product Strategy & Planning

Project management

Product Strategy & Planning

Resource allocation

Product Strategy & Planning

Define business model

Executive Leadership

Training

Engineering & Development

Value chain management

Product Strategy & Planning

Create how-to-demo stories

Engineering & Development

Define control criteria

Engineering & Development

Cost estimation

Product Strategy & Planning

Data analysis

Product Strategy & Planning

Resource management

Product Strategy & Planning

4.6. Grouping Domain-Activity to Domain-Category Pairs
At this stage, all domain-activity pairs are known. To further increase the pragmatic and aesthetic value of the initial iteration of the framework, the number of combinations needs to be reduced. These efforts resulted in 33 grouped domain-category pairs, covering all 122 domain-activity pairs across. All of them are closely related to each other and within their domain. Table 11 shows how many domain-activity pairs each domain-category pair overarches. By far, the largest domain-category pair is the one of requirements management covering 23 pairs.
Table 11. Distribution of domain-activity pairs.

Domain-category

Count of pairs

Requirements management

23

Business cases

8

Strategic management and communication

8

Marketing execution

7

Sales execution

6

Market research & communication

6

Branding

5

Manage software development

5

Customer support

4

Advertising

4

Product planning

4

Quality assurance

4

Technical training and support

3

Resource management

3

Product strategy and vision

3

Human resource management

3

Roadmapping

3

Corporate strategy and vision

2

Financial management

2

Research and development

2

Product backlog management

2

Supplier, legal & I.P. management

2

Business model

2

Distribution management

2

Approve roadmap

1

Pricing

1

Release management

1

Inventory management

1

Positioning

1

Portfolio management

1

Product lifecycle management

1

Monitor and control results

1

Product value proposition

1

Total

122

4.7. Final Approval by Experts
The framework was shared with the three experts to get their final approval on the grouping of the pairs (see section 4.6). All of them have provided feedback (Table 12). Resulting in a single change: Supplier, legal, I.P. rights moves from Product Strategy & Planning to Executive Leadership.
Table 12. Feedback for approval by experts.

Expert

Feedback

Expert 1

Makes it even more concise. You are missing the Audit (Monitoring and Evaluation segment) in the executive leadership domain.

Changes: No changes are required because the Monitor control results cover this request. The audit itself has never been identified and cannot be considered at this stage.

Expert 2

Hi Frederic, I went through the slides. All look logical. I only saw " inventory management " in Sales on the last slide. It is better passed to Product Strategy and Planning.

Changes: It has been mapped with the sales domain since the expert discussion and statistical consensus step. The current pair stands because data trumps opinion, unless it might have been during a grouping effort.

Expert 3

I do not have any comments besides Supplier, legal, or I.P. management – I have never seen it assigned to Product teams. Overall, looks very good!

Changes: This has indeed been an oversight during the grouping. Checking back on the analysis, legal and I.P. rights management was originally linked to the executive leadership domain, but this was incorrectly moved to the product strategy and planning domain during grouping.

5. Pragmatic Framework for Product Managers
Once the final approval has been given (see section 4.7) by the experts and the final refinement has been executed, the first iteration of the Pragmatic Framework for Product Managers (PFPM) has geen established. This framework comprises 6 domains and 33 domain categories and covers all 122 PM activities. Figure 5. shows the highest level of the framework, the overview of the domains, and their main categories. For each domain, it is possible to go one level deeper and see which activities are assigned to which categories.
Figure 5. Pragmatic Framework for Product Managers (PFPM).
5.1. Executive Leadership
Figure 6. overviews the Executive Leadership domain, including domain-category pairs underneath the respective domain-activity pairs.
Figure 6. Executive Leadership domain.
5.2. Product Strategy & Planning
Figure 7. gives an overview of the Product Strategy & Planning domain, including domain-category pairs underneath the respective domain-activity pairs.
Figure 7. Product Strategy & Planning domain.
5.3. Engineering & Development
Figure 8. overviews the Engineering & Development domain, including domain-category pairs underneath the respective domain-activity pairs.
Figure 8. Engineering & Development domain.
5.4. Marketing
Figure 9. gives an overview of the Marketing domain, including domain-category pairs underneath the respective domain-activity pairs.
Figure 9. Marketing domain.
5.5. Sales
Figure 10. overviews the Sales domain, including domain-category pairs and the respective domain-activity pairs underneath.
Figure 10. Sales domain.
5.6. Customer Support & Success
Figure 11. gives an overview of the Customer Support & Success domain, including domain-category pairs and underneath the respective domain-activity pairs.
Figure 11. Customer Support & Success domain.
6. Conclusion
Through academic scrutiny, this research aimed to improve upon other similar but non-academic frameworks in terms of trust, rigor, and methodological robustness. The Pragmatic Framework for Product Managers (PFPM) provides a comprehensive overview of 122 Product Manager activities, transparently distributed across 33 categories and 6 domains. This framework can now be the foundation for future more contextual specific research and support practitioners by making the opaque world of being PM more transparent and clear.
7. Research Agenda
The primary goal of this research proposal is to develop a Pragmatic Framework for Product Managers (PFPM) a that initially encompasses all PM activities. Once the initial iteration is established, further steps will involve trimming the number of activities, enhancing the state-of-the-art related practices, and considering more concise and context-specific variants, such as software startups. For each of these variants, even more in-depth research can be undertaken to see whether the actual activities could also be improved based on the particular context of the research context. This endeavor necessitates ongoing academic collaboration across similar domains such as Software Product Management, Requirements Engineering, New Product Development, Startups, Entrepreneurship, and Innovation management. Identifying and refining core activities within the framework will set the stage for continuous research to further enhance and expand its applicability. All of these efforts will further maximize the framework’s value.
Abbreviations

PM

Product Manager

PFPM

Pragmatic Framework for Product Managers

SPM

Software Product Management

RE

Requirements Engineering

NPD

New Product Development

ISPMA

International Software Product Management Association

GDPR

General Data Protection Regulation

PhD

Doctor of Philosophy

MBA

Master of Business Administration

Author Contributions
Frederic Pattyn is the sole author. The author read and approved the final manuscript.
Conflicts of Interest
The authors declare no conflicts of interest.
Appendix
Supplementary Data
Table 13. 122 activities and their simplified description.

Activities

Description

Advertising budget

Deciding how much money to spend on showing people our cool stuff.

Advertising execution

Making sure our cool stuff is shown to people the way we planned.

Advertising planning

Thinking about how and where to show people our cool stuff.

Advertising Policies

Rules about how we show our cool stuff to people.

Approve development

Saying "yes" whether what is built can go live.

Approve roadmap

Saying "yes" to the map shows where our ideas are going.

Backlog grooming

Cleaning up the list of ideas we want to make real.

Brand management

Taking care of how people see our company.

Brand planning

Thinking about how we want people to see our company.

Branding execution

Making our company look the way we planned.

Branding planning

Deciding how we want our company to look.

Budget management

Deciding how to use our money.

Business case analysis

Is our idea a good one for our company?

Collect customer feedback

Listening to what people say about our cool stuff.

Communicate with development

Talking to the people who make our ideas real.

Communication

Talking and listening to people about our cool stuff.

Communication planning

Planning how to talk and listen to people about our cool stuff.

Compensation & benefits

Deciding how much money and extras we give people for their work.

Competitive analysis

Figuring out what others are doing that we might do better.

Competitive research

Learning about what others are doing.

Corporate Strategy and Vision

Deciding where we want our company to go.

Cost estimation

Guessing how much money it will take to make our ideas real.

Create business case

Making a reason for why an idea could be good for the company.

Create how-to-demo stories

Making stories to show how to use our cool stuff.

Create product backlog

Making a list of ideas we want to make real.

Create roadmap

Drawing a map that shows where our ideas are going.

Customer qualification

Figuring out who might like to have our cool stuff.

Customer support

Helping people when they have problems with our cool stuff.

Data analysis

Looking at numbers and information to learn new things.

Define business model

Deciding how we make money.

Define control criteria

Deciding how we know our stuff is made right.

Define delivery model

Deciding how our cool stuff gets to people.

Define market priorities

Deciding what cool stuff we want to show off first.

Define new product guidelines

Making rules to make our new cool stuff real.

Define stakeholders

Figuring out who cares about our cool stuff.

Development budgets

Deciding how much money we spend to make our ideas real.

Distribution management

Making sure our cool stuff gets to people.

Environmental scanning

Looking around to see what is happening that might affect our company.

Evaluate business case

Deciding if the reason for our idea is good enough to make it real.

Evaluate business model

Checking if the way we make money is working.

Evaluate new requirements

Deciding if the written instructions we need to make an idea real are correct.

External stakeholder management

We talked and listened to people outside our company who cared about our cool stuff.

Financial management (incl. funding)

Deciding how we use and get money.

Forecasting

Guessing what will happen with our cool stuff in the future.

Go to market (GtM)

Getting our new cool stuff out to people.

Innovation management

Taking care of new ideas.

Inspire

Making people excited about our ideas.

Internal stakeholder management

Talking and listening to people in our company who care about our cool stuff.

Inventory management

Keeping track of how much cool stuff we have.

Lead

Being the boss and showing everyone the way.

Legal and I.P. rights management

Taking care of rules and who can use our cool ideas.

Manage software development

Making sure our computer stuff is made right.

Market research

Learning about the people who might like our cool stuff.

Market research communication

Talking about what we learned about people who might like our cool stuff.

Marketing budget

Deciding how much money to spend talking about our cool stuff.

Marketing communication

Talking and showing people our cool stuff.

Marketing copy

Writing words about our cool stuff.

Marketing execution

Doing what we planned to show people our cool stuff.

Marketing planning

Thinking about how we will show people our cool stuff.

Marketing research

Learning more about people who might like our cool stuff.

Marketing strategy

Making a plan for how to show people our cool stuff.

Monitor and control results

Watching to see if things are going the way we want.

Negotiate priorities

Deciding what we do first when we cannot do everything.

Negotiate requirements

Deciding what we need to make our ideas real.

Packaging

Making our cool stuff look nice when people get it.

Partnership management

Taking care of friends who help us sell our cool stuff.

Performance management

Making sure everyone is doing their best work.

Portfolio management

Taking care of all our cool stuff.

Positioning

Making sure people see our cool stuff the way we want.

Pricing

Deciding how much people pay for our cool stuff.

Process management

Making sure we do things the right way.

Product design

Drawing how our cool stuff should look.

Product ideation

Coming up with new ideas for cool stuff.

Product lifecycle management

Taking care of our cool stuff from the start (idea) to the grave (end-of-life).

Product Marketing

Showing people our cool stuff and why it is awesome.

Product planning (incl. releases)

Making a plan for our new cool stuff and when people can get it.

Product research

Learning about what cool stuff we should make.

Product strategy and vision

Deciding what cool stuff we want to make and where we want it to go.

Product validation

I'm checking if our cool stuff is as awesome as we think.

Product value proposition

Saying why our cool stuff is awesome.

Project management

Making sure we are making our ideas on time, budget, and scope.

Prototyping

Making a first version of our cool stuff to see if it works.

Quality assurance

Checking that our cool stuff is really good (has no bugs).

Recruitment

Finding new people to help us make cool stuff.

Release management

Making sure people can get our new cool stuff when we are ready.

Release validation

Checking that our new cool stuff is ready for people.

Requirements analysis

Figuring out what we need to make our ideas real.

Requirements elicitation

Finding out what we need to make our ideas real.

Requirements gathering

Collecting what we need to make our ideas real.

Requirements management

Taking care of what we need to make our ideas real.

Requirements prioritization

Deciding which things we need first to make our ideas real.

Requirements re-prioritization

Changing what things we need first to make our ideas real.

Requirements selection

Picking what we need to make our ideas real.

Requirements Validation

Checking that we have what we need to make our ideas real.

Research and Development

Learning and making new cool stuff.

Resource allocation

Deciding who does what to make our cool stuff.

Resource management

Making sure we have what we need to make our cool stuff.

Risk management

Making sure nothing bad happens while we make our cool stuff.

Sales Analysis

Looking at numbers to see how well we are selling our cool stuff.

Sales execution

Making sure we are selling our cool stuff the right way.

Sales planning

Making a plan for how we sell our cool stuff.

Sales strategy

Make a plan for getting people to buy our cool stuff.

Sales training

Teaching people how to sell our cool stuff.

Scope change management

Dealing with changes to what we are making.

Service management

Making sure we are helping people with our cool stuff the right way.

Sourcing

Finding where we get the things we need to make our cool stuff.

Stakeholder communication

Talking to people who care about our cool stuff.

Stakeholder management

Taking care of people who care about our cool stuff.

Strategic communication

Talking about big important things.

Strategic management

Taking care of big important things.

Strategic planning

Making a plan for big important things.

Supplier management

Taking care of the people who give us what we need to make our cool stuff.

Tactical planning

Making a plan for the little things.

Technical support

Helping people when they have problems with our computer stuff.

Training

Teaching people how to do things.

Update roadmap

Changing the map that shows where our ideas are going.

Update strategic goals

Changing what we want to achieve.

Use scenarios

Imagining how people will use our cool stuff.

User research

Learning about the people who use our cool stuff.

Value chain management

Taking care of every step, from making to selling our cool stuff.

Write product initiation document

Writing why a new idea is good and how to make it real.

Write user stories

Write instructions to make sure that what we need to make is correct.

Table 14. Statistical consensus, full results.

Activities

Consensus

St. Dev.

Domain

Customer support

100%

0.00

Customer Support & Success

Market research communication

100%

0.00

Marketing

Product planning (incl. releases)

100%

0.00

Product Strategy & Planning

Product strategy vision

100%

0.00

Product Strategy & Planning

Sales execution

100%

0.00

Sales

Marketing copy

91%

4.50

Marketing

Marketing research

91%

4.50

Marketing

Market research

90%

4.00

Marketing

Sales Analysis

90%

4.00

Sales

Sales planning

90%

4.00

Sales

Sales training

90%

4.00

Sales

Strategic management

90%

4.00

Executive Leadership

Collect customer feedback

89%

3.50

Customer Support & Success

Lead

82%

3.77

Executive Leadership

Marketing communication

82%

3.77

Marketing

Marketing planning

82%

3.77

Marketing

Write product initiation document

82%

3.77

Product Strategy & Planning

Compensation & benefits

82%

3.50

Executive Leadership

Financial management (incl. funding)

82%

3.50

Executive Leadership

Manage software development

82%

3.50

Engineering & Development

Product lifecycle management

80%

3.30

Product Strategy & Planning

Recruitment

80%

3.30

Executive Leadership

Create roadmap

80%

3.00

Product Strategy & Planning

Sales strategy

80%

3.00

Sales

Internal stakeholder management

78%

2.83

Executive Leadership

Portfolio management

78%

2.83

Executive Leadership

Backlog grooming

78%

2.50

Product Strategy & Planning

Requirements Validation

75%

1.00

Engineering & Development

Marketing budget

73%

3.09

Marketing

Performance management

73%

3.09

Executive Leadership

Product value proposition

73%

3.09

Product Strategy & Planning

Advertising budget

73%

3.03

Marketing

Corporate Strategy and Vision

73%

2.50

Executive Leadership

Marketing strategy

73%

2.50

Marketing

Product Marketing

73%

2.50

Marketing

Create business case

70%

2.62

Product Strategy & Planning

Partnership management

70%

2.62

Executive Leadership

Prototyping

70%

2.62

Engineering & Development

Positioning

70%

2.00

Marketing

Create product backlog

67%

2.16

Product Strategy & Planning

Product ideation

67%

2.16

Product Strategy & Planning

Budget management

64%

2.49

Executive Leadership

Requirements analysis

64%

2.49

Engineering & Development

Technical support

64%

2.49

Engineering & Development

Update roadmap

64%

2.49

Product Strategy & Planning

Marketing execution

64%

2.49

Marketing

Quality assurance

64%

2.49

Engineering & Development

Research and Development

64%

2.49

Engineering & Development

Strategic planning

64%

2.36

Executive Leadership

Advertising planning

60%

2.06

Marketing

Define new product guidelines

60%

2.06

Product Strategy & Planning

External stakeholder management

60%

2.06

Executive Leadership

Forecasting

60%

2.06

Product Strategy & Planning

Product research

60%

2.06

Product Strategy & Planning

Stakeholder management

60%

2.06

Executive Leadership

Strategic communication

60%

2.06

Executive Leadership

Advertising Policies

60%

2.05

Marketing

Approve roadmap

60%

2.05

Executive Leadership

Communicate with development

60%

2.05

Engineering & Development

Evaluate business case

60%

2.05

Product Strategy & Planning

Update strategic goals

60%

2.05

Product Strategy & Planning

Brand management

55%

2.05

Marketing

Branding execution

55%

2.05

Marketing

Legal and I.P. rights management

55%

2.05

Executive Leadership

Use scenarios

55%

2.05

Product Strategy & Planning

References
[1] Giardino, C., Bajwa, S. S., Wang, X., & Abrahamsson, P. (2015). Key challenges in early-stage software startups. International conference on agile software development
[2] Artinger, S., & Powell, T. C. (2016). Entrepreneurial failure: Statistical and psychological explanations. Strategic Management Journal, 37(6), 1047-1064.
[3] Crowne, M. (2002). Why software product startups fail and what to do about it. Evolution of software product development in startup companies. IEEE International Engineering Management Conference.
[4] Tokarev, B. (2022). Comparative Analysis of the Product Management Application in Startups of Different Types. Proceedings of the International Scientific Conference “Smart Nations: Global Trends In The Digital Economy” Volume 1.
[5] Eisenmann, T. R. (2020). Determinants of early-stage startup performance: Survey results. Harvard Business School Entrepreneurial Management Working Paper (21-057).
[6] Insights, C. (2021). The Top 12 Reasons Startups Fail.
[7] Kyril, K. (2022). Startup Failure Rate: How Many Startups Fail and Why in 2023? Failory.
[8] Pattyn, F. (2023b). The Hidden Costs of Ignoring Cash Flow: A Call for Strategic Requirements Prioritization at Startups during an Era of Rising Interest Rates. IEEE 31st International Requirements Engineering Conference Workshops (REW).
[9] Barney, S., Aurum, A., & Wohlin, C. (2008). A product management challenge: Creating software product value through requirements selection. Journal of Systems Architecture, 54(6), 576-593.
[10] Hujainah, F., Bakar, R. B. A., Abdulgabber, M. A., & Zamli, K. Z. (2018). Software requirements prioritisation: a systematic literature review on significance, stakeholders, techniques and challenges. IEEE Access, 6, 71497-71523.
[11] Azar, J., Smith, R. K., & Cordes, D. (2007). Value-oriented requirements prioritization in a small development organization. IEEE software, 24(1), 32-37.
[12] Kittlaus, H.-B. (2012). Software product management and agile software development: conflicts and solutions. Software for People: Fundamentals, trends and best practices, 83-96.
[13] Pattyn, F. (2023). Preliminary Structured Literature Review Results using ChatGPT: Towards a Pragmatic Framework for Product Managers at Software Startups. IEEE 31st International Requirements Engineering Conference Workshops (REW).
[14] Pattyn, F. (2023). Enhancing Startup Success Rates: Towards a Pragmatic Framework for Product Managers (PFPM). IEEE 31st International Requirements Engineering Conference (RE).
[15] Springer, O., & Miler, J. (2018). The role of a software product manager in various business environments. 2018 Federated Conference on Computer Science and Infor-mation Systems (FedCSIS).
[16] Albuga, S., & Odeh, Y. (2018). Towards prioritizing software business requirements in startups. 2018 8th International Conference on Computer Science and Information Technology (CSIT).
[17] Melegati, J., Goldman, A., Kon, F., & Wang, X. (2019). A model of requirements engineering in software startups. Information and software technology, 109, 92-107.
[18] Tripathi, N., Klotins, E., Prikladnicki, R., Oivo, M., Pompermaier, L. B., Kudakacheril, A. S., Unterkalmsteiner, M., Liukkunen, K., & Gorschek, T. (2018). An anatomy of requirements engineering in software startups using multi-vocal literature and case survey. Journal of Systems and Software, 146, 130-151.
[19] Tyagi, R. K., & Sawhney, M. S. (2010). High‐performance product management: the impact of structure, process, competencies, and role definition. Journal of Product Innovation Management, 27(1), 83-96.
[20] Marciuska, S., Gencel, C., & Abrahamsson, P. (2013). Exploring how feature usage relates to customer perceived value: A case study in a startup company. International Conference of Software Business.
[21] Lehtola, L., Kauppinen, M., & Kujala, S. (2005). Linking the business view to requirements engineering: long-term product planning by roadmapping. 13th IEEE International Conference on Requirements Engineering (RE'05).
[22] Gralha, C., Damian, D., Wasserman, A. I., Goulão, M., & Araújo, J. (2018). The evolution of requirements practices in software startups. Proceedings of the 40th International Conference on Software Engineering.
[23] Kittlaus, H.-B. Usability from a Product Manager’s Perspective 1. 46. WI-MAW-Rundbrief.
[24] Barhydt, J. (2023). Psychological Safety in Startup Organizations. Pepperdine University.
[25] Gupta, V., Rubalcaba, L., & Gupta, C. (2023). Connecting Dots Between Entrepreneurs, Research Publishers, and Software Engineering Researchers: An Outcome of Mixed Methods Empirical Research. IT Professional, 25(1), 68-80.
[26] Kleinaltenkamp, M., Prohl-Schwenke, K., & Elgeti, L. (2023). The Rise of a New Business Function: Customer Success (Management). In Customer Success Management: Helping Business Customers Achieve Their Goals (pp. 1-6). Springer.
[27] Pattyn, F. (2023d). Overcoming the Limitations: A Research Agenda towards a Pragmatic Framework for Product Managers at Software Startups. Ghent University.
Cite This Article
  • APA Style

    Pattyn, F. (2024). Innovating the Future: Unveiling the Initial Iteration of the Pragmatic Framework for Product Managers. American Journal of Engineering and Technology Management, 9(2), 32-50. https://doi.org/10.11648/j.ajetm.20240902.12

    Copy | Download

    ACS Style

    Pattyn, F. Innovating the Future: Unveiling the Initial Iteration of the Pragmatic Framework for Product Managers. Am. J. Eng. Technol. Manag. 2024, 9(2), 32-50. doi: 10.11648/j.ajetm.20240902.12

    Copy | Download

    AMA Style

    Pattyn F. Innovating the Future: Unveiling the Initial Iteration of the Pragmatic Framework for Product Managers. Am J Eng Technol Manag. 2024;9(2):32-50. doi: 10.11648/j.ajetm.20240902.12

    Copy | Download

  • @article{10.11648/j.ajetm.20240902.12,
      author = {Frederic Pattyn},
      title = {Innovating the Future: Unveiling the Initial Iteration of the Pragmatic Framework for Product Managers
    },
      journal = {American Journal of Engineering and Technology Management},
      volume = {9},
      number = {2},
      pages = {32-50},
      doi = {10.11648/j.ajetm.20240902.12},
      url = {https://doi.org/10.11648/j.ajetm.20240902.12},
      eprint = {https://article.sciencepublishinggroup.com/pdf/10.11648.j.ajetm.20240902.12},
      abstract = {Context: This study introduces the Pragmatic Framework for Product Managers, a tool developed to enhance the understanding and application of product management activities. Objectives: The aim is to provide a comprehensive overview of Product Manager (PM) activities that positively impact efficiency, business growth, budget control, user satisfaction, and release processes. The framework is intended to aid decision-making, training, and clarifying the PM role, ultimately contributing to product success. Methods: A systematic literature review of 134 studies was conducted to develop the PFPM. This extensive research led to identifying and classifying 122 activities into 33 categories within 6 domains, forming a robust framework for product managers. Results: The PFPM, in its initial iteration, represents a minimal viable product of the framework. The research findings highlight the framework’s potential for future refinement, particularly in the context of software startups. Conclusion: The PFPM significantly affects software companies' product decision-making, PM training, and role transparency. It is a valuable resource for researchers and practitioners in Software Product Management (SPM), Requirement Engineering (RE), New Product Development (NPD), and innovation. The framework paves the way for future studies focused on the unique dynamics of PM activities in the software startup ecosystem.
    },
     year = {2024}
    }
    

    Copy | Download

  • TY  - JOUR
    T1  - Innovating the Future: Unveiling the Initial Iteration of the Pragmatic Framework for Product Managers
    
    AU  - Frederic Pattyn
    Y1  - 2024/05/30
    PY  - 2024
    N1  - https://doi.org/10.11648/j.ajetm.20240902.12
    DO  - 10.11648/j.ajetm.20240902.12
    T2  - American Journal of Engineering and Technology Management
    JF  - American Journal of Engineering and Technology Management
    JO  - American Journal of Engineering and Technology Management
    SP  - 32
    EP  - 50
    PB  - Science Publishing Group
    SN  - 2575-1441
    UR  - https://doi.org/10.11648/j.ajetm.20240902.12
    AB  - Context: This study introduces the Pragmatic Framework for Product Managers, a tool developed to enhance the understanding and application of product management activities. Objectives: The aim is to provide a comprehensive overview of Product Manager (PM) activities that positively impact efficiency, business growth, budget control, user satisfaction, and release processes. The framework is intended to aid decision-making, training, and clarifying the PM role, ultimately contributing to product success. Methods: A systematic literature review of 134 studies was conducted to develop the PFPM. This extensive research led to identifying and classifying 122 activities into 33 categories within 6 domains, forming a robust framework for product managers. Results: The PFPM, in its initial iteration, represents a minimal viable product of the framework. The research findings highlight the framework’s potential for future refinement, particularly in the context of software startups. Conclusion: The PFPM significantly affects software companies' product decision-making, PM training, and role transparency. It is a valuable resource for researchers and practitioners in Software Product Management (SPM), Requirement Engineering (RE), New Product Development (NPD), and innovation. The framework paves the way for future studies focused on the unique dynamics of PM activities in the software startup ecosystem.
    
    VL  - 9
    IS  - 2
    ER  - 

    Copy | Download

Author Information
  • Abstract
  • Keywords
  • Document Sections

    1. 1. Introduction
    2. 2. Related Work
    3. 3. Study Design
    4. 4. Results
    5. 5. Pragmatic Framework for Product Managers
    6. 6. Conclusion
    7. 7. Research Agenda
    Show Full Outline
  • Abbreviations
  • Author Contributions
  • Conflicts of Interest
  • Appendix
  • References
  • Cite This Article
  • Author Information