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

Frederic Pattyn

doi:doi:10.11648/j.ajetm.20240902.12

Research Article |

| Peer-Reviewed

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

Frederic Pattyn^*

Published in American Journal of Engineering and Technology Management (Volume 9, Issue 2)

Received: 25 April 2024 Accepted: 13 May 2024 Published: 30 May 2024

Views: Downloads:

Download PDF

Share This Article

Twitter
Linked In
Facebook

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

[1]

. These obstacles, combined with an inherent overconfidence in their survival chances

[2]

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

[3]

, inefficient requirement selection processes

[4]

, critical resource allocation issues

[5]

, insufficient market research or business case analysis

[2]

, and an overallocation of resources towards solutions that do not address any or sufficient market needs

[6]

. Consequently, these startups frequently fail to achieve product-market fit

[7]

and struggle to secure their first paying customers

[1]

, endangering their runway

[8]

and probability of success.

With the potential to significantly influence

[9]

future performance

[10, 11]

, introducing improvements in early product decision-making processes is paramount. The general consensus is that there needs to be an owner of the product

[3]

, 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

[12]

, 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

[5]

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

[8, 13, 14]

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

[15]

Table 1. Activities in Startup PM literature.

Ref.

Count Activities

Activities

[16]

Requirements prioritization, requirements elicitation, writing user stories

[17]

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

[18]

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

[19]

Sales strategy, sales execution, development budgets

[20]

Requirements prioritization, product planning (incl. releases)

[15]

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.

[21]

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

[22]

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

[23]

. 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

[24]

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

[25]

, 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

[26]

. 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

[27]

, 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.

Download: Download full-size image

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)

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.

Download: Download full-size image

Figure 2. Statistical consensus, 100% agreement.

Download: Download full-size image

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).

Download: Download full-size image

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.

Download: Download full-size image

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.

Download: Download full-size image

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.

Download: Download full-size image

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.

Download: Download full-size image

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.

Download: Download full-size image

Figure 9. Marketing domain.

5.5. Sales

Figure 10. overviews the Sales domain, including domain-category pairs and the respective domain-activity pairs underneath.

Download: Download full-size image

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.

Download: Download full-size image

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. https://doi.org/10.1002/smj.2378
[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. https://doi.org/10.1109/iemc.2002.1038454
[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. https://doi.org/10.1007/978-3-030-94873-3_59
[5]	Eisenmann, T. R. (2020). Determinants of early-stage startup performance: Survey results. Harvard Business School Entrepreneurial Management Working Paper (21-057). https://doi.org/10.2139/ssrn.3725023
[6]	Insights, C. (2021). The Top 12 Reasons Startups Fail. https://www.cbinsights.com/research/report/startup-failure-reasons-top/
[7]	Kyril, K. (2022). Startup Failure Rate: How Many Startups Fail and Why in 2023? Failory. https://www.failory.com/blog/startup-failure-rate
[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). https://doi.org/10.1109/rew57809.2023.00073
[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. https://doi.org/10.1016/j.sysarc.2007.12.004
[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. https://doi.org/10.1109/access.2018.2881755
[11]	Azar, J., Smith, R. K., & Cordes, D. (2007). Value-oriented requirements prioritization in a small development organization. IEEE software, 24(1), 32-37. https://doi.org/10.1109/ms.2007.30
[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. https://doi.org/10.1007/978-3-642-31371-4_5
[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). https://doi.org/10.1109/rew57809.2023.00071
[14]	Pattyn, F. (2023). Enhancing Startup Success Rates: Towards a Pragmatic Framework for Product Managers (PFPM). IEEE 31st International Requirements Engineering Conference (RE). https://doi.org/10.1109/re57278.2023.00059
[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). https://doi.org/10.15439/2018f100
[16]	Albuga, S., & Odeh, Y. (2018). Towards prioritizing software business requirements in startups. 2018 8th International Conference on Computer Science and Information Technology (CSIT). https://doi.org/10.1109/csit.2018.8486216
[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. https://doi.org/10.1016/j.infsof.2019.02.001
[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. https://doi.org/10.1016/j.jss.2018.08.059
[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. https://doi.org/10.1111/j.1540-5885.2009.00701.x
[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. https://doi.org/10.1007/978-3-642-39336-5_16
[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). https://doi.org/doi.org/10.1109/re.2005.36
[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. https://doi.org/10.1145/3180155.3180158
[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. https://doi.org/10.1109/mitp.2022.3217728
[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. https://doi.org/10.1007/978-3-031-26178-7_1
[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

Plain Text BibTeX RIS

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

Frederic Pattyn

Department of Business Informatics and Operations Management, Ghent University, Ghent, Belgium

Contact Email

http://orcid.org/0000-0002-8912-9585

Download PDF

Plain Text BibTeX RIS

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