Browse

Journals By Subject

Life Sciences, Agriculture & Food
Chemistry
Medicine & Health
Materials Science
Mathematics & Physics
Electrical & Computer Science
Earth, Energy & Environment
Architecture & Civil Engineering
Education
Economics & Management
Humanities & Social Sciences
Multidisciplinary

Books

Publish Conference Abstract Books
Upcoming Conference Abstract Books
Published Conference Abstract Books
Publish Your Books
Upcoming Books
Published Books

Proceedings

Events

Events
Five Types of Conference Publications

Join

Join as Editor-in-Chief
Join as Senior Editor
Join as Editorial Board Member
Become a Reviewer

Information

For Authors
For Reviewers
For Editors
For Conference Organizers
For Librarians
Article Processing Charges
Special Issue Guidelines
Editorial Process
Manuscript Transfers
Peer Review at SciencePG
Open Access
Copyright and License
Ethical Guidelines
Submit an Article
Research Article | | Peer-Reviewed

Time to Value (TtV) as a Missing Requirements Prioritization Criterion for Startup Survival: Insights from Founders vs. Systematic Literature Review

Frédéric Pattyn*,  Peter Goetz
Published in International Journal of Sustainability Management and Information Technologies (Volume 11, Issue 1)
Received: 27 March 2025     Accepted: 7 April 2025     Published: 29 April 2025
Views:       Downloads:
Download PDF
Abstract

Software startups operate under extreme uncertainty and financial pressure, making Requirements Prioritization (RP) a critical activity for improving survival prospects. This study investigates which prioritization criteria are most relevant to early-stage ventures by conducting a systematic literature review (SLR) of 40 studies and analyzing 358 RP references encompassing 82 distinct criteria across 10 categories. Additionally, we conducted 34 semi-structured interviews with founders from 19 software startups to compare academic insights with real-world practices. The analysis reveals a substantial gap between scholarly emphasis and practitioner needs: while "expected cost" is the most frequently cited criterion in the literature, criteria related to financial impact—such as return on investment, cash flow, and time to value—are underrepresented despite being consistently cited by the most successful startups in our sample. Notably, the criterion "Time to Value," absent from all reviewed literature, emerged as a key factor among practitioners. These findings highlight the need for a more financially grounded and context-sensitive approach to RP in startup environments. The study concludes with a call for greater alignment between academic frameworks and the realities faced by early-stage software ventures, especially in economically challenging conditions.

Published in International Journal of Sustainability Management and Information Technologies (Volume 11, Issue 1)
DOI 10.11648/j.ijsmit.20251101.14
Page(s) 45-66
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), 2025. Published by Science Publishing Group
Previous article
Keywords

Startups, Requirements Prioritization, Requirements Prioritization Criteria, Requirements Engineering, Product Management

1. Introduction
Software startups are notorious for operating in a high-paced, uncertain, and resource-constrained context
[1]
, faced with numerous challenges contributing to their high failure rates, including premature scaling, cash flow challenges (82%), difficulties in obtaining financing or investors (47%)
[2, 3]
and funding shortages (21 to 44%)
[4, 5]
. A significant proportion, up to 63% fail
[4]
, with a quarter of these failures occurring in the first year alone
[5]
. Therefore their survival is tightly linked to prioritizing those features that will mitigate of much of these challenges as possible.
In their early stages, startups often embark on product decision-making activities
[6]
without a strategic plan for product development
[7]
. This lack of foresight can lead to inefficient requirements selection process
[8]
, misallocation of critical resources
[9]
, insufficient market research or business case analysis
[2]
, and an over-commitment to solutions that do not meet market needs
[10]
. One example is the tendency to invest heavily in a feature-rich Minimum Viable Product (MVP) with a long time-to-market
[11]
, often without traction or a clear business development strategy
[1]
. Consequently, they face the risk of not achieving a product-market fit
[6]
and struggle with acquiring their first paying customers
[1]
, negatively affecting the startup’s runway (number of months a company has left until cash runs out) and therefore probability of success.
Effective cash flow management, driven by strategic planning and efficient resource allocation, emerges as a critical factor in ensuring future venture survival. However, there exists a significant gap in academic literature regarding the analysis of cash flow as a determinant in requirements prioritization, particularly within the startup context. Existing research, while highlighting the significance of financial ratios in requirements prioritization discussions, often overlooks the unique challenges faced by startups. Furthermore, the distinct conditions and constraints under which startups operate necessitate a tailored approach to requirements prioritization. The absence of specific research underscores the importance and urgency of conducting this study to address identified gaps
[14]
.
In the end it all boils down to managing as good as possible the startup’s runway
[13, 15]
, the number of months a company has left until their cash runs out; trying to keep their costs as low as possible, as long as needed until they convince their stakeholders to give money, whether as paying customers, or investors
[16, 17]
. The survival of startups is highly dependent by striving for these results
[18]
.
2. Related Work
Requirements Engineering (RE) is often regarded as a front-end activity in software systems development process, validating the feasibility of a project and the assessment of the associated risks
[19]
. RE consists out of different activities such as product planning (including vision, business case analysis, requirements triage, requirements prioritization
[20]
, roadmapping and release planning), stakeholder negotiation (including communication and agreeing on them
[19, 20]
), requirements management, elicitation
[19-21]
, analysis
[19-21]
and checking
[20, 22]
. This study will focus on requirements prioritization (RP).
Requirements prioritization (RP), or task prioritization (TP) is considered an important decision-making activity in RE
[23]
and is the most researched area in software development
[24]
because it’s considered one of its crucial activities
[25-27]
. Still, finding the best approach to RP is difficult
[28]
, even with the wide range of available methods and criteria.
Through time a multitude of different types of methods, such as, but not limited to, multi-criteria decision-making method, multi-attribute utility theory (MAUT), Analytic Hierarchy Process (AHP), fuzzy theory, Case Based Reasoning (CBR) or Ranking (CBR)
[29]
, Data Envelopment Analysis (DEA), SMART, ELECTRE, PROMETHEE, SAW, TOPSIS
[30]
, MOSCOW, bubble sort, Binary Search Tree (BST), minimal spanning tree, numerical assignment, planning game, priority groups, Value Oriented Prioritization (VOP), $ 100 allocation
[31-33]
or cumulative voting
[25]
, Fuzzy RDF FG
[34]
, e³-value
[35]
, expert or management opinion, impact/effort matrix, kano model, story mapping, ICE, RICE, weighted scoring, opportunity scoring, buy a feature, weighted shortest jobs first, feature buckets, frequency and volume of use, assumption mapping, systemico model, hypothesis prioritization canvas
[36]
, cost/value approach
[29]
, dot voting
[29]
, eclipse framework
[29]
, integrated prioritization approach
[37]
, interactive generic algorithm
[38]
, Lanchester theory
[29]
, ranking based on product definition
[39]
, quality functional development (QFD)
[31]
, quantitative win-win
[40]
, RePizer
[41]
, round the group prioritization
[42]
, top ten requirements
[43]
, Wieger’s matrix approach
[39]
, aggregated DM methods
[44]
or aggregated indices randomization method (AIRM)
[45]
, have been constructed, discussed, refined and compared as part of the current body of knowledge regarding the available methods to perform RP.
Besides the models, some studies have focused one choosing the requirements prioritization criteria, in the pursuit of improving the performance of predictors
[46]
, both for functional as, non-functional
[47]
requirements prioritization efforts. This seldomly gets done considering a startup context. Specifically, Ma
[48]
, Hujainah et al.
[37]
both emphasize the selection criteria and methods employed within requirements engineering (RE) while not addressing the startup context. On the other hand, Gupta et al.
[49]
demonstrates a strong focus on the startup context, yet it remains descriptive and does not link back to the perspective of practitioners. This study will focus on identifying those requirements prioritization criteria that could be key for software startup survival.
3. Research Methodology
We employed a mixed-method approach to explore relevant requirements prioritization criteria (RPC) in the context of software startups, incorporating both theoretical and practitioner perspectives. The theoretical perspective was examined through a systematic literature review (SLR), while the practitioner view was captured via 34 semi-structured interviews with 19 software startup founders, conducted during the first two years of their ventures. This combination of methods provides a comprehensive understanding of which RPCs are considered valuable in early-stage startups and highlights areas that warrant further research and practical attention.
3.1. Research Questions
The primary aim of this study is to comprehensively gather and synthesize relevant trace evidence concerning activities related to requirements prioritization criteria (RPC) in software startups. This is achieved through a systematic literature review, which explores existing academic research within the software startup domain, and through semi-structured interviews with startup founders, which offer practical insights into how these criteria are applied in real-world scenarios. Together, these complementary methods provide a well-rounded understanding of RPC in early-stage software ventures.
By examining the available literature, our investigation seeks not only to identify existing practices, contrast theory from reality, but also to structure and envision their impact on startups, considering current best practices. To guide this endeavor, a set of research questions (RQs) has been formulated and is presented in Table 1. Through this study, we aspire to offer valuable insights that can inform decision-making processes and contribute to the overall success and sustainability of software startups in today’s dynamic business landscape.
Table 1. Research Questions.

Research Question

Purpose

RQ1

Are there scholarly investigations that address the activities associated with RPC?

To identify existing scholarly investigations focusing on activities related to RPC, which is essential for understanding the existing body of literature and identifying research gaps, providing a foundation for the SLR.

RQ2

What are the RPC that could be considered by a Product Manager when shaping its process?

To determine the range of RPC that Product Managers can consider, enhancing decision-making and aligning product development with business goals, crucial for software startups' success.

RQ2.1

How is the distribution of identified criteria across publications represented in terms of frequency?

To analyze the frequency and distribution of RPC in academic publications, helping identify the most emphasized factors and guiding researchers and practitioners to focus on widely recognized criteria.

RQ2.2

What are the RPC that are discussed in the retained publications?

To identify and summarize the specific RPC discussed in the selected academic publications, providing insights into the various factors considered in decision-making and helping identify common themes, trends, and gaps in literature.

RQ3

Which studies within the literature also consider the context of software startups?

To identify studies addressing the context of software startups in relation to RPC, highlighting unique challenges and dynamics, and offering targeted insights and evidence-based guidance for startup decision-makers.

RQ3.1

What are the RPC that are highlighted in academic research that are especially taking into account the software startup context?

To explore RPC highlighted in research considering the software startup context, helping tailor RP processes to their unique needs and enhancing decision-making effectiveness.

RQ3.2

Do the RPC uncovered through scholarly investigations differ from reality shared by software startup founders?

To compare the RPC identified in academic research with those reported by software startup founders, revealing potential gaps or alignments between theory and practice, and informing more contextually relevant and effective prioritization approaches for early-stage ventures.

RQ3.3

Do the RPC that are highlighted in software startup research, appropriate in an era of rising interest rates?

To evaluate the suitability of RPC in the context of rising interest rates, providing insights into their effectiveness in mitigating risks and aiding startups in adapting RP strategies for financial sustainability.

RQ3.4

What Requirements Prioritization Criteria show the most promise to improve decision-making at software startups in a more economic challenging context?

To identify RPC that promise to improve decision-making in challenging economic contexts, aiding startups in making efficient decisions and ensuring resilience in economically challenging times.
RQ1. Are there scholarly investigations that address the activities associated with Requirements Prioritization Criteria (RPC)? This research question is essential as it sets the groundwork for identifying the existing body of literature that specifically focuses on activities related to Requirements Prioritization Criteria. By exploring the presence of scholarly investigations in this domain, these basic bibliometrics, including a temporal analysis trying to show some chronological patterns of interest in the subject and their origin, support the systematic literature review (SLR) by providing an overview of the attention given to this specific topic. Understanding the scope and extent of prior studies is crucial for synthesizing existing knowledge and identifying potential gaps and research opportunities in the field of software product management.
RQ2. What are the Requirements Prioritization Criteria (RPC) that could be considered by a Product Manager when shaping its process? Understanding the range of Requirements Prioritization Criteria that Product Managers can consider when shaping their prioritization process is fundamental for enhancing decision-making in software startups. By identifying a comprehensive set of criteria, the SLR can offer practitioners valuable guidance in making informed choices while selecting and prioritizing requirements. This knowledge empowers Product Managers to optimize resource allocation, align product development with business goals, and increase the likelihood of software startup success.
RQ2.1. How is the distribution of identified criteria across publications represented in terms of frequency? Analyzing the distribution of identified Requirements Prioritization Criteria across different publications allows the SLR to examine their popularity and prevalence in the academic literature. By assessing the frequency with which criteria are mentioned, the review can identify the most commonly emphasized factors during requirements prioritization. This analysis aids in recognizing the relative importance of different RPC and helps researchers and practitioners focus on the criteria that have received significant attention in previous studies.
RQ2.2. What are the RPC that are discussed in the retained publications? This research question holds significant value as it focuses on identifying and summarizing the specific Requirements Prioritization Criteria discussed in the retained publications. By analyzing the content of these publications, the systematic literature review (SLR) aims to compile a comprehensive list of RPC that have been highlighted and explored in the academic literature. This knowledge allows researchers and practitioners to gain insights into the various criteria that have been considered in requirements prioritization decision-making across different studies and contexts. Understanding the range of RPC discussed in the retained publications helps to create a foundation for subsequent analyses and comparisons, enabling researchers to identify common themes, emerging trends, and potential gaps in the existing literature. Additionally, this investigation contributes to the overall synthesis of knowledge, providing a valuable resource for researchers and practitioners seeking a comprehensive understanding of the relevant factors influencing requirements prioritization in software production.
RQ3. Which studies within the literature also consider the context of software startups? This research question is of utmost importance as it narrows down the investigation to studies within the literature that specifically address the context of software startups in relation to Requirements Prioritization Criteria. By focusing on this subset of studies, the systematic literature review (SLR) aims to identify and highlight research that has specifically examined requirements prioritization practices in the unique environment of software startups. This subset analysis enables the SLR to distinguish studies that consider the particular challenges, constraints, and dynamics faced by startups during requirements prioritization. The results of this investigation can offer valuable insights into the relevance and applicability of RPC in the context of software startups, shedding light on which criteria have been emphasized and tested within this specific domain. This understanding provides software startup stakeholders, including Product Managers and decision-makers, with targeted information and evidence-based guidance to optimize requirements prioritization processes, leading to more informed and effective decision-making tailored to the specific needs of startups.
RQ3.1. What are the Requirements Prioritization Criteria that are highlighted in academic research, especially taking into account the software startup context? Exploring the Requirements Prioritization Criteria specifically highlighted in academic research related to the software startup context is valuable for understanding the unique considerations and challenges faced by startups during requirements prioritization. By focusing on this aspect, the SLR can identify criteria that are particularly relevant and effective in the startup environment. This knowledge can guide Product Managers in making context appropriate decisions, enhancing RP processes tailored to the specific needs of software startups.
RQ3.2. This research question plays a crucial role in bridging the gap between academic theory and real-world practice by comparing the Requirements Prioritization Criteria identified in the literature with those shared by software startup founders during semi-structured interviews. While the systematic literature review (SLR) provides a structured overview of academically recognized RPC, the interview data offer practical insights into how prioritization is approached in early-stage, resource-constrained environments. By examining potential alignments or discrepancies between these two perspectives, the study seeks to reveal whether the criteria valued by practitioners reflect or diverge from those emphasized in scholarly work. This comparison contributes to a deeper understanding of the applicability and relevance of academic findings in startup settings, ultimately supporting more informed, evidence-based decision-making for both researchers and practitioners in software product management.
RQ3.3. Do the Requirements Prioritization Criteria that are highlighted in software startup research, appropriate in an era of rising interest rates? With the current era of rising interest rates posing new challenges for software startups, evaluating the suitability of Requirements Prioritization Criteria highlighted in startup research becomes crucial. By examining the compatibility of these criteria with changing economic conditions, the SLR can offer insights into their effectiveness in mitigating risks associated with higher interest rates. This assessment aids Product Managers in adapting RP strategies and ensuring financial health and sustainability in the face of economic fluctuations.
RQ3.4. What Requirements Prioritization Criteria show the most promise to improve decision-making at software startups in a more economic challenging context? Identifying Requirements Prioritization Criteria that hold the most promise for improving decision-making in software startups during an economic context with higher interest rates is of significant value for startups aiming to navigate challenging financial landscapes. By highlighting criteria that can enhance decision-making efficiency and financial health, the SLR provides actionable insights for Product Managers, leading to more resilient and successful software startups.
3.2. Review Protocol Development
Our review protocol methodology (Figure 1) is an extended adaptation of the structures described by Kitchenham
[50]
, Brereton et al.
[51]
, Kitchenham et al.
[52]
, and consequently reduces the possibility of researcher bias
[50]
. When it comes to the first step of planning, identifying the necessity for a SLR (see Section 2.1), defining the research questions and their value (see Section 3.1) have already been discussed. The final goal of both defined search strategies is compiling a master list of studies that will be considered to be part of the structured literature review. The unfiltered search results should be saved and retained for possible reanalysis. For this structured literature review, only relevant primary studies will be considered (journal papers and conference proceedings). This means that publications from book, research registers, internet (blog posts, website...) and professional journals get excluded.
To comprehensively search for related studies, our search strategy began with an online search of digital libraries. Studies that are related to this review were extracted from four relevant digital libraries and databases for conducing a SLR
[53]
, namely, IEEE Xplore, ScienceDirect, Springer Link and ACM Digital Library, using the following search terms: ((Criteria OR aspects OR attributes OR variables OR category OR variable OR categories) AND (Requirements OR Requirement) AND (prioritization OR selection OR triage)).
Figure 1. Overview of review protocol.
Required to limit the research domain because there’s already written a lot on the topic
[54]
; it is advisable to limit and structure the presentation. The following inclusion (Table 2), exclusion (Table 3) and quality assessment criteria (Table 4) have been considered for validation.
Hujainah et al.
[37]
opted to only include papers that reach a score of 50% for the inclusion criteria - our benchmark before a pilot study will be the same. This means setting the bar at a score of 2.5 out of 5. For the exclusion criteria; when the sum is less than 2, the paper gets excluded.
The main goal of quality assessment criteria is to increase the confidence level that the study is actually relevant and methodologically solid. This in order to make sure that the outcome of the study makes it possible to guide future research recommendations. Only the papers that have survived the previous hurdle (the inclusion and exclusion criteria) are in scope to have their quality assessed. In software engineering, usually all levels of evidence get accepted. The only threshold that might be viable would be to exclude level 5 evidence when there’s a reasonable number of primary studies at a great level
[50]
. Because the used primary sources that are taken into account are academic publications and not books or magazines, the requirement is considered automatically fulfilled in most cases, and therefore will not consider this a separate criteria.
Table 2. Inclusion criteria.

IC

Inclusion criteria

1

0.5

0

1

Reports on requirements prioritization criteria

In-depth (multiple criteria)

Basic (single criterium)

None

2

Reports on context

Startup

General

None

3

Reports results of the prioritization efforts

Explicitly mentioned

Basic

None

4

Paper within the Requirements Engineering domain

Explicitly mentioned

Linked

No

5

Paper related to software products

Software

General

Other
Table 3. Exclusion criteria.

Exclusion criteria

1

0.5

0

1

Year of publication before 1983

>= 1983

N/A

Before 1983

2

There is no PDF file available

PDF available

N/A

No available
Table 4. Quality assessment criteria.

Quality assessment criteria

2

1

0

QAC1

Citations

Citations >= 100 (top 2%)

C between 100 AND 5

C < 5 (lower 50%)

QAC2

Number of references

#ref >= 25

#ref between 25 AND 10

#ref < 10

QAC3

Is the proposed methodology (criteria) clearly explained?

Yes

Moderate

No

QAC4

Is the evaluation of proposed criterai on adequate case studies, subjects or project data sets?

Subjects >10

Subjects between 10 AND 4

Subjects <4

QAC5

Is the result of the study clearly stated?

Yes

Moderate

No
QAC1: Citations. According to Weingart
[55]
regardless the year of the publication, having over 100 citations can be considered impactful, while having fewer than five makes the paper part of the lower half. This is also a tactic used by Krishnan and Ulrich
[56]
. The number of citations is based on Google scholar, or Research Gate depending on availability of the data.
QAC2: References. Ucar et al.
[57]
sees an increase in the number of references in academic papers, with median of 25 references per engineering journal papers in 2013.
QAC3: Proposed methodology. To insure that the quality of the paper meets scientific rigor, it’s a must to include a criteria that evaluates the used methodology (technique or solution) of the study
[37]
.
QAC4: Reference data. Besides purely the methodology, it’s relevant to check whether or not the results could be of any value based on the amount of underlying data
[37]
. Having done a preliminary literature study within the field of Requirements Engineering, and it’s remarkable to observe that most of the papers are done based on limited case studies.
Most papers within this field of research cover each time only a limited number of case studies
[58]
. According to Rodriguez et al.
[59]
it’s because of the often confidentiality issues regarding this sensitive topic. This is also one of the validity threats mentioned by Barney et al.
[60]
with his paper having below 5 case studies; due to the too low number of use cases, the results have a low statistical power. For those papers that opt for the use of case studies, the total number of used case studies (companies) is most frequently rather few; below 5
[59, 61]
. According to Klotins
[11]
this highlights the difficulty of getting in-depth access to live startups. There are a couple to be found between 5 and 10
[62-65]
. There are only a handful of papers that go over 10, never reaching 20
[20, 66, 67]
. A low number of case studies in papers should be considered a validity threat according to Barney et al.
[60]
.
QAC5: Stated result. When the methodology and the research data are at par, the final element regarding to study structure that deserves some additional scrutiny is how clearly the study results are stated
[37, 68]
.
Although it’s not a commonly supported practice to use basic arithmetic to decide whether or not the quality of a paper is good enough, it does get done somethings Hujainah et al.
[37]
, Achimugu et al.
[29]
. So here the maximum score that’s possible is 5 times 2, making 10. Papers scoring below 5 get excluded from the study.
Validate Review Protocol. The review protocol has been validated by running a positive pilot on an initial subset of hundred studies found via the search strategy
[6, 69]
. This to see the impact of the selected inclusion, exclusion and quality assessment criteria.
Execute Research Strategy
Figure 2 shows that the search strategy resulted in a total of 161 papers, of which 40 have survived the review protocol. Considering the limit number of initial studies, an acceptance rate of 25% is highly recommended
[2-5]
. Considering the data, this thresholds gets basically achieved with an positive acceptance rate of 24.84%.
Figure 2. Protocol result search strategy.
3.3. Semi-structured Interviews
We conducted 34 interviews with the founders of 19 software startups (see Table 5), using a purposive sampling method
[12, 71]
. All software startups were part of the same quarterly cohort (Q4/2022), of the same startup accelerator in Belgium. To ensure homogeneity as much as possible, three startups (S3, S6 and S19) got excluded because they were already too long in business, or were a non-profit. The first interview took place in Q4 of 2022 and the final interview, including data gathering in Q2 of 2024. We followed the general interview guidelines Patton (2002) to ensure consistency and reliability in our data collection. In accordance with our ethics policy, we ensured that all participants and their shared information would remain confidential. We performed thematic analysis (Kiger & Varpio, 2020) on the transcripts of the interviews. The guiding questions that have been asked related to the study were; (1) How do you determine, due to resource constraints, which ones make the cut and which ones don’t? (2) For those that make it, how do you prioritize them? (3) Which requirements prioritization criteria do you use? and (4) Which prioritization methods do you use?
Table 5. Startups and interviews.

ID

Role

Sector

Interviews

Years in business

For profit?

S1

Co-founder & CTO

Football data analytics

1 (1h15)

3

Yes

S2

Co-founder & CTO

Security platform

2 (2h07)

2

Yes

S3

CEO

AI for mobile mapping

2 (0h57)

7

Yes

S4

Founder & Product Manager

Web3 SocialFi

3 (2h45)

3

Yes

S5

CEO & co-founder

PLG platform

2 (1h13)

4

Yes

S6

Co-owner

Legal tech

2 (2h35)

5

Yes

S7

Co-founder

HR tech

1 (0h45)

2

Yes

S8

Founder

Logistical solution

1 (1h25)

3

Yes

S9

Co-founder

Form builder

3 (3h24)

3

Yes

S10

Co-founder & CTO

Web2 credit market

2 (1h45)

3

Yes

S11

CEO

HR tech

3 (2h53)

3

Yes

S12

CEO & founder

Healthcare platform

2 (1h48)

2

Yes

S13

Co-owner

HR tech

2 (1h15)

3

Yes

S14

CEO & founder

HR tech

1 (2h11)

3

Yes

S15

CEO & co-founder

Data document management

3 (2h41)

3

Yes

S16

Founder

Fashion tech

1 (0h58)

2

Yes

S17

CEO & co-founder

AI for trends analysis

1 (1h23)

4

Yes

S18

Co-founder

HR tech

1 (0h51)

4

Yes

S19

Co-founder

HR-tech

1 (1h34)

2

No
4. Results
RQ1: Are there scholarly investigations that address the activities associated with Requirements Prioritization Criteria (RPC)?
Of collated studies, two thirds are journal publications. When drilling down on the journals, Information and Software Technology takes the number one position with 21.05% of all related publications, followed by the Journal of Systems and Software, good for 10.53%. The rest of them only represent 5% or less. When taking a closer look to the conference publications, the largest source (20%) can be traced back to IEEE. Besides the IEEE conferences, all the rest are one-offs.
The examination of the temporal distribution of these publications related (Figure 3) to requirements prioritization criteria activities reveals interesting peaks. On average, there are two publications per year. However, two standout years, 2003 and 2010, demonstrate exceptional activity with both 5 publications each. Notably 3 out of 4 studies during the 2018-2019 period have been observed to consider a startup context. Even more interestingly, these are 100% of the retained publications related to that field of inquiry. This surge in research aligns with a period of prosperity and success for startups
[14]
, which is not surprising given the increasing attention and significance attributed to the startup ecosystem during that time. This observation highlights the growing interest in understanding and addressing the unique challenges and opportunities faced by product managers within the dynamic and thriving environment of startups.
Figure 3. Number of papers by year of publication.
RQ2: What are the Requirements Prioritization Criteria (RPC) that could be considered by a Product Manager when shaping its process?
The answer to RQ2 gets answered with the following sub-questions.
RQ2.1. How is the distribution of identified criteria across publications represented in terms of frequency?
Table 6 presents a comprehensive list of 82 identified RPC along with their corresponding relative frequencies in and references to the qualified papers. Notably, the activity garnering the most significant attention is the expected cost (including development), accounting for 12.75% of the discussions. However, the most intriguing observation arises from the fact that close to three quarters (59/82) of them are referenced merely up to 1 percent, indicating considerable untapped potential for further and in-depth scholarly exploration.
Table 7 gives the overview of all identified criteria, allocated to one of the categories. In the end, this resulted in 82 final selection criteria across 10 categories as defined by Svahnberg et al.
[70]
. Here it gets confirmed that the category of cost-related factors, with 18.73% is the one that’s most discussed.
Table 6. Overview of distribution of identified requirements prioritization criteria (top 10).

Requirements Prioritization Criteria

% of all citations

Expected cost (incl. development)

12.75%

Risks (incl. dev, business, failure...)

6.18%

Resource constraints (incl. HR)

5.98%

Dependencies (incl. requirements, customers, technical...)

5.78%

Time constraints

4.98%

Stakeholder preferences

4.58%

Business value

4.18%

Customer value

2.79%

Value (generic)

2.79%

Estimated expected revenue

2.79%
Table 7. Overview of the RPC across categories.

Category

Criteria

Count cited

Cost-Related Factors: includes criteria related to budget, cost constraints, cost-benefit analysis, costs of not implementing a requirement, development costs, and cost of maintenance.

Expected cost (incl. development) Budget constraints Cost benefit ratio Efficiency (incl. decreasing costs) Maintenance Budget process Cost of taken no action Cost importance ratio

94 (18.73%)

Revenue and Financial Impact:

covers criteria such as revenue generation, financial benefits, profitability, return on investment (ROI), and net present value.

Estimated expected revenue

Value (generic)

Profitability

Financial value

Return on investment (ROI)

Payback period

Net present value (NPV)

Break-even point

Cash flow analysis

Internal rate of return (IRR)

57 (11.35%)

Business and Strategic Impact:

encapsulates criteria related to business goals, strategic benefits, market share estimates, competitive differentiation, and alignment with product strategy.

Business value

Estimated market share

Competitive intensity

Strategy alignment

MVP feature set coverage

Strategic value

Signed contracts

Market maturity (incl. growth rate)

Proprietary position

Cultural alignment

Brand value

Company synergies

Need to demonstrate product

Existence of market need

Feature promised

58 (11.55%)

Stakeholder and Customer Considerations:

comprises criteria related to customer needs, customer value, stakeholder value, stakeholder preferences, and customer satisfaction.

Stakeholder preferences Customer value Importance User satisfaction Change management User engagement Contribution to user task User loyalty Frequency of use Communication Partnership

60 (11.95%)
Table continues
Table 7. Continued.

Category

Criteria

Count cited

Technical Factors and Constraints:

includes criteria related to technical feasibility, complexity of development, technology constraints, product technology, and testability

Complexity Technical constraints Code change Re-usability Modifiability Redundancy (incl. data) Technology Compatibility (incl. technical) Scalability Standards

27 (5.38%)

Resource Constraints and Availability:

covers criteria such as resource constraints, availability of human resources, skilled personnel, and other re-sources.

Resource constraints (incl. HR)

30 (5.89%)

Quality and Performance Metrics:

encompasses criteria like quality of service, performance, reliability, maintainability, and error rates.

Quality of service Easy to use Documentation quality Level of ambiguity User experience Reduce errors Reliability Consistency Durability Traceability Testability Non-functional characteristics

35 (6.97%)
Table 7. Continued.

Category

Criteria

Count cited

Risk Assessment: incorporates criteria related to risks, including development risks, business risks, risk of failure, and risk of implementing a feature.

Risks (incl. dev, business, failure...) Penalties Prioritization (incl. features, bugs) Predictability (incl. commercial, info) Volatility Security Feasibility Regulations Legal mandate Harm avoidance Issues

74 (14.74%)

Time Constraints and Scheduling:

includes criteria related to development time, time to market, delivery time, and scheduling constraints.

Time constraints

Time to market

37 (7.37%)

Dependency and Interdependency Factors:

Covers criteria such as dependencies between requirements, feature dependencies, and requirement precedence constraints.

Dependencies (incl. requirements, customers, technical...)

Similarity

30 (5.98%)

= 502 (100%)
RQ2.2. What are the RPC that are discussed in the retained publications?
Table 8 shows in detail which RPC that got discussed in each of the retained studies. For each of these studies, the full paper has been thoroughly read and coded in order to identify all mentioned RPC.
Table 8. Selected studies and their RP criteria.

Ref.

Cited RP criteria

[
35]

Profitability

[72]

Predictability (incl. commercial, info), Return on investment (ROI), Risks (incl. dev, business, failure...)

[73]

Complexity, expected cost (incl. Development), Time to market

[74]

Business value, Change management, Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), MVP feature set coverage, Resource constraints (incl. HR), Risks (incl. dev, business, failure...)

[75]

Expected cost (incl. development), Financial value, Value (generic)

[76]

Budget constraints, Risks (incl. dev, business, failure...), Time constraints, Time to market

[77]

Customer value, Expected cost (incl. development), Risks (incl. dev, business, failure...)

[40]

Expected cost (incl. development), Feasibility, Quality of service, Time constraints

[78]

Business value

[66]

Business value, Expected cost (incl. development), Return on investment (ROI), Stakeholder preferences, Value (generic)

[65]

Cost benefit ratio, Expected cost (incl. development), Maintenance, Resource constraints (incl. HR), Time constraints

[79]

Cultural alignment

[20]

Cost benefit ratio, Customer value, Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), MVP feature set coverage, Need to demonstrate product, Prioritization (incl. features, bugs), Stakeholder preferences, Strategy alignment

[80]

Business value, Customer value, Dependencies (incl. requirements, customers, technical...), Easy to use, Efficiency (incl. decreasing costs), Estimated expected revenue, Expected cost (incl. development), Prioritization (incl. features, bugs), Profitability, Quality of service, Reduce errors, Resource constraints (incl. HR), Time to market, User engagement

[81]

Customer value

[82]

Budget constraints, Quality of service, Time constraints, Time to market

[83]

Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), Importance, Penalties, Risks (incl. dev, business, failure...), Time constraints, Volatility
Table 8. Continued.

Ref.

Cited RP criteria

[64]

Budget constraints, Cost benefit ratio, Customer value, Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), Risks (incl. dev, business, failure...), Time constraints

[84]

Cost importance ratio, Expected cost (incl. development), Importance

[33]

Financial value, Resource constraints (incl. HR), Stakeholder preferences, Strategic value, Time constraints

[85]

Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), Importance, Stakeholder preferences

[86]

Competitive intensity, Customer value, Estimated market share, Expected cost (incl. development), Financial value, Penalties, Risks (incl. dev, business, failure...), Time constraints, User engagement, Value (generic)

[29]

Expected cost (incl. development), Quality of service, Resource constraints (incl. HR), Time constraints

[87]

Business value, Customer value, Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), Penalties, Risks (incl. dev, business, failure...), Time constraints, Value (generic)

[32]

Customer value, Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), Prioritization (incl. features, bugs)

[38]

Customer value, Resource constraints (incl. HR), Technical constraints, Time constraints

[88]

Documentation quality, Efficiency (incl. decreasing costs), Estimated expected revenue, Expected cost (incl. development), Reduce errors, Time constraints

[89]

Budget constraints, Competitive intensity, Customer value, Expected cost (incl. development), Regulations, Time constraints, User satisfaction

[37]

Budget constraints, Business value, Complexity, Consistency, Customer value, Dependencies (incl. requirements, customers, technical...), Easy to use, Estimated expected revenue, Expected cost (incl. development), Feasibility, Importance, Level of ambiguity, Maintenance, Modifiability, Penalties, Predictability (incl. commercial, info), Prioritization (incl. features, bugs), Quality of service, Redundancy (incl. data), Reliability, Resource constraints (incl. HR), Re-usability, Risks (incl. dev, business, failure...), Security, Stakeholder preferences, Technical constraints, Technology, Testability, Time constraints, Traceability, User satisfaction, Value (generic), Volatility
Table 8. Continued.

Ref.

Cited RP criteria

[90]

Competitive intensity, Cost of taken no action, Dependencies (incl. requirements, customers, technical...), Expected cost (incl. development), Financial value, MVP feature set coverage, Predictability (incl. commercial, info), Regulations, Resource constraints (incl. HR), Signed contracts, Stakeholder preferences, Strategy alignment, Time to market

[60]

Change management, Competitive intensity, Complexity, Cost benefit ratio, Dependencies (incl. requirements, customers, technical...), Estimated expected revenue, Feature promised, Maintenance, Profitability, Resource constraints (incl. HR), Signed contracts, Stakeholder preferences, Time to market, Volatility

[91]

Company synergies, Competitive intensity, Complexity, Durability, Existence of market need, Market maturity (incl. growth rate), Payback period, Predictability (incl. commercial, info), Profitability, Proprietary position, Regulations, Resource constraints (incl. HR), Strategic value, Strategy alignment, Time to market

[92]

Estimated expected revenue, Expected cost (incl. development), Partnership, Return on investment (ROI), Stakeholder preferences

[93]

Business value, Customer value, Expected cost (incl. development), Non-functional characteristics, Strategy alignment

[94]

Prioritization (incl. features, bugs)

[95]

Return on investment (ROI)

[96]

Budget process, Estimated expected revenue, Financial value, Internal rate of return (IRR), Payback period, Profitability, Return on investment (ROI)

[97]

Cash flow analysis, Estimated expected revenue, Estimated market share, Expected cost (incl.

development), Financial value, Profitability

[46]

Break-even point

[70]

Budget constraints, Business value, Complexity, Customer value, Dependencies (incl. requirements, customers, technical...), Estimated expected revenue, Expected cost (incl. development), Financial value, Penalties, Prioritization (incl. features, bugs), Quality of service, Resource constraints (incl. HR), Risks (incl. dev, business, failure...), Stakeholder preferences, Technical constraints, Time constraints, Time to market, Value (generic), Volatility
RQ3: Which studies within the literature also consider the context of software startups?
The examination of requirements prioritization criteria within the startup domain reveals a notable scarcity of research. Out of 40 analyzed studies, 12 of them give some context about the companies that were involved, only 3 explicitly focus on a software startup context (Table 9). Those papers will be taken into account when answering RQ3.1 (see Section 3.1.6). Overall, this is a clear indication that the startup context, and the related RPC, is of relative under-researched nature.
Table 9. Requirements prioritization research considering a software startup context.

Ref.

Title

Startup?

[74]

Agile requirements prioritization in large-scale outsourced system projects: An empirical study

[66]

Prioritization of quality requirements: State of practice in eleven companies

[20]

A model of requirements engineering in software startups

X

[80]

An anatomy of requirements engineering in software startups using multi-vocal literature and case survey

X

[81]

Towards prioritizing software business requirements in startups

X

[83]

Challenges and future trends in software requirements prioritization

[64]

Do we know enough about requirements prioritization in agile projects: insights from a case study

[84]

Supporting the selection of software requirements

[85]

A comparison of nine basic techniques for requirements prioritization

[29]

A systematic literature review of software requirements prioritization research

[87]

Value-oriented requirements prioritization in a small development organization

[60]

A product management challenge: Creating software product value through requirements selection
RQ3.1. What are the Requirements Prioritization Criteria that are highlighted in academic research, especially taking into account the software startup context?
In contrast to the 82 RP criteria, when considering all references, there are only 19 (Table 10) to be found when explicitly taking the startup context into account, across 3 studies
[20, 80, 81]
.
Table 10. Overview of all identified RPC (top 5).

Startup Requirements Prioritization Criteria

% of all citations

Expected cost (incl. development)

11.54%

Customer value

11.54%

Dependencies (incl. requirements, customers, technical...)

7.69%

Prioritization (incl. features, bugs)

7.69%

Efficiency (incl. decreasing costs)

7.69%
When grouping on the category level (see Section 5.1.3) it’s clear that first cost-related factors is the number one interest (23.08%), and secondary more subjective interests that are getting considered as startup RPC with stakeholder and customer considerations (19.23%) and business and strategic impact (15.38%). When it comes to revenue and financial impact category, it’s barely considered (Table 11).
Table 11. Overview of RPC across categories.

Startup Requirements Prioritization Categories

% of all citations

Cost-Related Factors

23.08%

Stakeholder and Customer Considerations

19.23%

Business and Strategic Impact

15.38%

Quality and Performance Metrics

11.54%

Dependency and Interdependency Factors

7.69%

Risk Assessment

7.69%

Revenue and Financial Impact

7.69%

Time Constraints and Scheduling

3.85%

Resource Constraints and Availability

3.85%
RQ3.2. Do the RPC uncovered through scholarly investigations differ from reality shared by software startup founders?
The comparison between scholarly investigations and insights from startup founders reveals a high degree of overlap in the Requirements Prioritization Criteria (RPC) identified, with one notable exception. Table 12 presents the RPCs mentioned during the interviews, along with their corresponding categories. Among these, “Expected Cost” emerged as a particularly critical criterion for startups. The data suggests that neglecting to consider development costs during prioritization can have severe consequences—specifically, all startups in the study that did not factor in this criterion (S5, S7, and S15) were no longer operational at the time of last interview.
Interestingly, all interview-identified criteria except one—“Time to Value” (TtV)—were also present in the academic literature summarized in Table 7. Based on founder insights, "Time to Value" refers to the period between the release of a feature and the moment when its intended business value—such as revenue, ROI, growth, exposure, or another measurable goal—is largely realized. This criterion, although absent in the literature sample, appears to be of practical significance in early-stage startup environments, suggesting a potential gap in academic coverage and an opportunity for further research.
Table 12. Overview of used RPC across categories by software startups vs scholarly investigations.

Requirements Prioritization Categories

Requirements Prioritization Criteria

Startup id

In SLR?

Cost-Related Factors

Expected cost (including development days)

S1, S2, S9, S10, S11, S12, S15, S16 and S17

Yes

Business and Strategic Impact

Strategic alignment

S4, S5, S14, S16 and S17

Yes

Time Constraints and Scheduling

Time to Value (TtV)

S2, S8, S9, S10, S11, S12 and S15

No

Time Constraints and Scheduling

Time to Market (TtM)

S1, S2, S4, S8, S9 and S10

Yes

Revenue and Financial Impact

Business case (including expected revenue and ROI)

S2, S9, S11, S12, S15, and S17

Yes

Stakeholder and Customer Considerations

Stakeholder preferences (informal user discussions)

S8, S9 S12, S14 and S17

Yes

Stakeholder and Customer Considerations

Stakeholder preferences (count of user requests)

S8, S9, S10, S11, S14, S15 and S17

Yes
When looking at the criteria within the revenue and financial impact category, having a clear and measurable business case—such as expected ROI, probability to upsell customers (S12), contribution to a 1M ARR target (S15), 100% revenue certainty (S2, S8, S9, S11, S17), or the percentage of users expected to adopt a feature (S2, S15)—emerges as one of the most valued considerations among the most successful startups. These teams consistently prioritize features that are tied to financial outcomes and that can be tracked post-release, setting them apart from less successful startups, who often lack this structured approach.
For instance, startup S3 initially emphasized financial impact in their prioritization and demonstrated strong performance early in the study. However, by the end, they had moved away from this criterion—citing the effort required and frequent mismatches with reality—which coincided with a decline in their performance. Similarly, S9 reflected on their experience and shared that, if given the chance to start over, they would be far more disciplined in only building features backed by a strong, revenue-driven business case. Strikingly, none of the startups that ended up bankrupt had included financial impact as a prioritization criterion, highlighting the significant risks of overlooking this factor in early-stage product decisions.
RQ3.3. Do the Requirements Prioritization Criteria that are highlighted in software startup research, appropriate in an era of rising interest rates?
The findings suggest that the Requirements Prioritization Criteria (RPC) currently emphasized in software startup research may not be fully appropriate or sufficient in an era of rising interest rates. While academic literature does acknowledge the importance of financial decision-making, it often omits key financial metrics that become particularly critical under tighter economic conditions. Financial ratios such as return on investment (ROI), internal rate of return (IRR), payback period, cash flow analysis (CFA), and net present value (NPV)—which are fundamental
[7]
for evaluating capital efficiency in high-interest environments—are notably absent in the reviewed startup-focused literature. This indicates a gap between the financial rigor required in such economic contexts and the financial criteria being promoted in academic research on startups.
In contrast, insights from the interviews with startup founders reveal a stronger emphasis on practical financial reasoning. The most successful startups consistently prioritized features based on clearly defined business cases that could be measured post-release. These included criteria such as expected ROI, upsell potential (S12), contribution to revenue targets like 1M ARR (S15), and revenue certainty (S2, S8, S9, S11, S17). Moreover, the criterion "Time to Value" (TtV)—highlighted in interviews but absent from the academic literature—gains relevance in a high-interest environment where delayed returns are increasingly costly. TtV captures the urgency of achieving measurable outcomes quickly, aligning well with the realities of higher capital costs.
The consequences of neglecting financial impact in prioritization decisions were evident: all startups that failed to consider this dimension (S5, S7, and S15) were no longer operational at the time of the final interviews. Meanwhile, startups like S3 and S9 experienced a decline in performance after deprioritizing financial criteria, reinforcing the critical nature of revenue-related decision-making in challenging economic conditions.
In summary, while academic RPC methods cover many relevant themes, they lack the financial depth needed to guide prioritization effectively in periods of rising interest rates. Startup practice is currently ahead of literature in recognizing the importance of measurable financial outcomes and short time-to-value—suggesting an opportunity for research to evolve in step with the software startup context and economic environment.
RQ3.4. What Requirements Prioritization Criteria show the most promise to improve decision-making at software startups in a more economic challenging context?
In a more challenging economic context, healthy financial ratios become more and more important to secure the next round of funding, which is of primordial importance for startups having a limited runway. Therefore considering financial metrics (see Section 3.1.7) would already be a good step forward depending on the stage of the venture. Considering all contexts, the papers (Table 13) that consider the revenue and financial impact category gets referenced 11.35% (see Section 5.1.3). Those studies that consider the startup context don’t reference any of the more advanced financial ratios (see Section 5.1.6).
Table 13. Financial RPC.

Paper

Financial ratio

Boehm

[72]

Return on investment (ROI)

Svensson et al.

[66]

Return on investment (ROI)

Cleland-Huang and Denne

[98]

Net present value (NPV)

Cooper

[90]

Payback period

Bekkers et al.

[92]

Return on investment (ROI)

Fogelstrom et al.

[95]

Return on investment (ROI)

Gorchels

[96]

Return on investment (ROI), Internal rate of return (IRR), Payback period

Cosse and Swan

[97]

Cash flow analysis

Guyon and Elisseeff

[46]

Break-even point
5. Discussion
5.1. Research Question 1 Related to Scholarly Investigations That Address Requirements Prioritization Criteria
In this comprehensive study, we delve into the temporal analysis and research focus of requirements prioritization criteria through a systematic literature review and detailed analysis requirements prioritization criteria through a systematic literature review and detailed analysis in search for the answer to the first research questions (see Section 3.1.1). Analyzing in total 40 selected studies, we identified that once since recent times, an uptick can be noticed where the software startup context is considered explicitly (see Section 5.1.5), reflecting the evolving landscape of prioritization practices. While the increasing attention to startups is promising, we note that further exploration in this area is warranted, presenting ample opportunities for future research Moreover, our investigation revealed prominent academic outlets for publishing research on product manager activities. Notably, “Information and Software Technology”, and “Journal of Systems and Software”, emerged as key journals (see Section 5.1.1) in the field, showcasing the credible and relevant contributions they offer. Our findings highlight the need to bridge the knowledge gap in this dynamic domain and provide valuable insights for researchers, practitioners, and decision-makers seeking to comprehend and enhance prioritization practices in various contexts.
5.2. Research Question 2 Related to What Requirements Prioritization Criteria a Product Management Should Consider When Shaping Their Processes
In this systematic literature review and accompanying data analysis, we delve into the multifaceted nature of requirements prioritization criteria, starting from 358 unique criteria. Refining them (see Section 5.1.3) made it possible to not only to reduce them to 82 distinct criteria, but also to map and structure them to 10 highly comprehensive categories. Overall, the category related to cost-related factors has been observed to be the most discussed theme in the literature. However, we acknowledge that the academic focus on cost may not align with the primary concern and challenge, knowingly or unknowingly by practitioners, especially in software startups during a time of increasing interest rates. For practitioners being able to secure their next funding round, and therefore being able to manage their cash flow position better are paramount importance to enhance the probability of survival of their venture. By addressing crucial research questions and observations during analysis, this systematic literature review lays the groundwork for future research endeavors, contributing to the advancement of requirements prioritization processes, especially the used criteria and knowledge.
5.3. Research Question 3 Related to the Studies That Consider the Software Startup Context
In this study, we critically examined the subset of academic literature that explicitly considers the software startup context when discussing Requirements Prioritization Criteria (RPC). Out of the broader selection of 40 retained publications, only a limited number directly address the unique characteristics, constraints, and challenges faced by software startups (see Section 5.1.5). This indicates that while requirements prioritization is a well-covered topic in general, the nuances of early-stage ventures—such as limited resources, short runways, and high market uncertainty—remain underexplored in scholarly work. By identifying these context-specific studies, we were able to highlight which RPCs are most frequently emphasized in startup-relevant research and observe how their framing may differ from that in mature or large-scale organizations. Notably, although startup-oriented papers do reference prioritization principles, they rarely incorporate startup-specific financial metrics or decision-making dynamics in detail. This lack of tailored insights presents an opportunity for further inquiry and refinement. Our analysis reinforces the importance of continued research that captures the lived realities of startup environments, especially in economically volatile conditions. Addressing this gap is essential for ensuring that the academic discourse remains both relevant and actionable for early-stage product managers navigating complex prioritization decisions.
6. Completeness
Within the confines of the formulated research questions (see Section 3.1), we have conducted a rigorous review exercise on requirements prioritization criteria research, with a special interest for the software startup context, resulting in the identification and selection of 40 studies that adequately address at least one of the defined research questions. Spanning from the earliest publication in 1983 to the most recent ones in 2019, the selected studies provide valuable insights into this domain. However, it is essential to acknowledge that a systematic literature review, by its nature, cannot ever be fully completed. The paradigm shift and dynamic nature of requirements prioritization, especially in the context of startup research, may have led to some relevant studies eluding our inclusion. Additionally, the decision to focus solely on English-published articles, and non-grey literature may have inadvertently omitted important and pertinent studies available in other languages. Despite these limitations, the review provides a comprehensive and valuable snapshot of the current state of requirement prioritization research, serving as a foundation for further exploration and analysis in this ever-evolving field.
7. Threats to Validity
This review protocol encountered various challenges that could potentially threaten its validity, including bias in publications and data extraction inaccuracies. To mitigate these challenges, a meticulous search strategy was devised, encompassing diverse literature databases, explicit selection criteria, and rigorous quality criteria. However, it is acknowledged that not all relevant research might have been captured through search terms, leading to the possibility of important studies being omitted. Furthermore, strict adherence to selection criteria (see paragraph “Define inclusion and exclusion criteria” in Section 3.2.1) and comprehensive quality assessment (see paragraph “Define quality assessment criteria” in Section 3.2.1) was enforced to minimize incorrect omissions. In the context of this structured literature review, several types of validity were considered and addressed:
Descriptive Validity: The precision with which the research accurately portrays the collected information was ensured through the utilization of a data extraction form (see paragraph “Define data extraction monitoring” in Section 3.2.1), documenting the information essential for addressing the research questions and maintaining descriptive validity.
Theoretical Validity: To capture the intended scope of investigation effectively, efforts were made to avoid biases in study identification, maintain neutrality in inclusion and exclusion criteria, and ensure accurate data extraction and classification. Ongoing refinement of the review protocol, even using a pilot, all aspects of the protocol got checked in order to maximized the study’s theoretical validity and objectivity.
Generalizability: Given the extensive coverage of a broad research area over an extended period, the findings of this mapping study are probably generalizable, even without the inclusion of unindexed studies from grey or none English publications.
Interpretive Validity: The involvement of researchers with expertise in software engineering and empirical research enhanced the interpretive validity of the study, minimizing the impact of personal bias on data interpretation (see Section 3.2). Here also artificial intelligence (see Section 5.1.3) got used to increase the internal consistency, in order to further reduce any personal bias on the data interpretation.
Repeatability: Documentation of the mapping procedure and outcomes based on the studied research papers contributes to the study’s repeatability, enabling replication by other researchers under similar conditions.
Although efforts have been made to ensure the validity of this study, it is recognized that other researchers might arrive at a similar list of decisions and publications but not necessarily identical to ours
[3]
. The inherent complexity and evolving nature of academic research necessitate a continuous and critical approach to address potential threats to validity, enhancing the reliability and robustness of future studies in this domain.
8. Conclusions
Our systematic literature review of 40 studies uncovered only limited attention to the software startup context, with most RPC frameworks focusing on general or enterprise settings. Key startup-specific realities—like extreme resource constraints, short time horizons, and the need for rapid validation—remain underexplored. To address this gap, we conducted 34 interviews with founders from 19 software startups. Their insights highlight criteria consistently undervalued in the literature but crucial in practice. One such example is the presence of a measurable business case—a common thread among the most successful startups. As one founder (S9) noted, “If a feature doesn’t clearly tie into a business goal, it’s a distraction we can’t afford.”
Another standout is Time to Value (TtV), defined by founders as the duration between releasing a feature and realizing its intended business outcome. Despite its practical importance—especially in high-interest, cash-sensitive environments—TtV is absent from all reviewed academic papers.
This misalignment matters: none of the startups that went bankrupt had prioritized financial criteria like expected cost, TtV, or business case strength. The literature, likewise, largely ignores established financial metrics such as ROI, NPV, or cash flow analysis—precisely the lenses that founders rely on when capital is constraint and/or expensive and speed is of the essence.
In short, the startup lens is still a blind spot in RPC research. Without it, we risk offering frameworks optimized for stability in a mature context, not for software startup survival.
9. Research Agenda
Building upon our research findings, we propose a research agenda that addresses crucial gaps and contributes to the advancement of RP methodologies, particularly in the software startup context. The following possible research questions serve as a guide for future investigations:
RQ1: What RP methodologies show the greatest potential for adaptation by incorporating financial ratios, particularly cash flow analysis, to better cater to software startups in an economic climate of escalating interest rates?
RQ2: Based on the complexities of the startup context, is there a method that could be formulated that would be able to improve their probability of success by reducing the number of costly early-stage mistakes?
RQ2: Can empirical evidence be provided that, ceteris paribus, the prioritization criteria for software startups indeed matter in different interest rate environments? And if so, which ones actually confirmed to generate the highest probability of survival?
In essence, prioritizing cash flow management to mitigate the failure rates of early-stage ventures. Emphasizing academia-industry collaboration, we call for collective efforts to promote research that supports the thriving growth of software startups in challenging economic times. This research agenda opens doors for further joint academic research in the domains of Software Product Management, Startups, and Requirements Engineering, ultimately fostering innovation and success in the startup ecosystem.
Abbreviations

RP

Requirements Prioritization

MVP

Minimum Viable Product

RE

Requirements Engineering

TP

Task Prioritization

MAUT

Multi-Attribute Utility Theory

AHP

Analytic Hierarchy Process

CBR

Case Based Reasoning

DEA

Data Envelopment Analysis

SMART

Specific, Measurable, Achievable, Relevant, Time-bound – Context not Clarified in Text but Likely This Meaning

ELECTRE

ELimination Et Choix Traduisant la REalité

PROMETHEE

Preference Ranking Organization METHod for Enrichment Evaluation

SAW

Simple Additive Weighting

TOPSIS

Technique for Order of Preference by Similarity to Ideal Solution

BST

Binary Search Tree

VOP

Value Oriented Prioritization

FG

Fuzzy RDF FG (Likely Fuzzy Graph-based, Specific Meaning Unclear)

QFD

Quality Functional Development

AIRM

Aggregated Indices Randomization Method

SLR

Systematic Literature Review

RPC

Requirements Prioritization Criteria

RQ

Research Question

IC

Inclusion Criteria

QAC

Quality Assessment Criteria

IRR

Internal Rate of Return

NPV

Net Present Value

ROI

Return on Investment

CFA

Cash Flow Analysis
Data Availability Statement
The data supporting the findings of this study are available through standard licensed open access databanks for academic research. The underlying master data and analysis are available from the authors upon reasonable request.
Conflicts of Interest
The authors declare no conflicts of interest.
References
[1] Giardino, C., et al. Key challenges in early-stage software startups. in International conference on agile software development. 2015. Springer.

https://doi.org/10.1007/978-3-319-18612-2_5

[2] Flint, M. Small business cash flow management: Strategies for success. 2023 29/11/2023]; Available from:

https://preferredcfo.com/cash-flow-reason-small-businesses-fail/

[3] Fatema, K., M. Syeed, and M. S. U. Miah, Demography of startup software companies: an empirical investigation on the success and failure. International Journal of Computer Applications, 2020. 975: p. 8887.

https://doi.org/10.1007/978-981-96-3294-7_26

[4] Kotashev, K., Startup Failure Rate: How Many Startups Fail and Why. Failory. Consultado el, 2022. 28.
[5] Kolmar, C. 20+ must-know startup statistics [2023]: Average time to reach profitability at a startup. 2023 19/7/2023]; Available from:

https://www.zippia.com/advice/start-up-profitability-statistics

[6] Pattyn, F. Preliminary Structured Literature Review Results Using ChatGPT: Towards a Pragmatic Framework for Product Managers at Software Startups. in 2023 IEEE 31st International Requirements Engineering Conference Workshops (REW). 2023. IEEE.

https://doi.org/10.1109/REW57809.2023.00071

[7] Crowne, M. Why software product startups fail and what to do about it. Evolution of software product development in startup companies. in IEEE International engineering management conference. 2002. IEEE.

https://doi.org/10.1109/IEMC.2002.1038454

[8] Tokarev, B. Comparative Analysis of the Product Management Application in Startups of Different Types. in Proceedings of the International Scientific Conference “Smart Nations: Global Trends In The Digital Economy” Volume 1. 2022. Springer.

https://doi.org/10.1007/978-3-030-94873-3_59

[9] Eisenmann, T. R., Determinants of early-stage startup performance: Survey results. Harvard Business School Entrepreneurial Management Working Paper, 2020(21-057).

https://doi.org/10.2139/ssrn.3725023

[10] Insights, C. Top 12 reasons startups fail. 2023 25/6/2023]; Available from:

https://www.cbinsights.com/research/startup-failure-reasons-top

[11] Klotins, E., Software Engineering in Start-up Companies. Ph.D. thesis, in Department of Software Engineering. 2019.
[12] Nyimbili, F. and L. Nyimbili, Types of Purposive Sampling Techniques with Their Examples and Application in Qualitative Research Studies. British Journal of Multidisciplinary and Advanced Studies, 2024. 5(1): p. 90-99.
[13] Pattyn, F., Improving Software Startup Viability: Addressing Requirements Prioritization Challenges Amid Increasing Interest Rates. 14th International Conference on Software Business (ICSOB), 2023
[14] Pattyn, F. and Usman R. Smart Scaling for Software Startups Through Financial Requirements Prioritization Criteria. in 2025 15th International Conference of Software Business (ICSOB). 2025.

https://doi.org/10.1007/978-3-031-85849-9_35

[15] Pattyn, F. The Hidden Costs of Ignoring Cash Flow: A Call for Strategic Requirements Prioritization at Startups during an Era of Rising Interest Rates. in IEEE 31st International Requirements Engineering Conference Workshops (REW). 2023. IEEE.
[16] Chang, Y. and W. M. Kock, Credit Guarantee Scheme and Startup Businesses: Financial Pipelines and Successful Startups in South East Asia, in Investment in Startups and Small Business Financing. 2021, World Scientific. p. 265-302.

https://doi.org/10.1142/9789811235825_0009

[17] Ogujiuba, K. K., et al., SMEs, success, and capital startups: Evidence from the service sector in South Africa. Administrative Sciences, 2023. 13(5): p. 127.

https://doi.org/0.3390/admsci13050127

[18] Korpysa, J., U. S. Singh, and S. Singh, Decision Criteria and Determining Factors Importance Validation Advocating Sustainability of Entrepreneurial Startups for Social Inclusion and Capacity Building. 2023.
[19] Nuseibeh, B. and S. Easterbrook. Requirements engineering: a roadmap. in Proceedings of the Conference on the Future of Software Engineering. 2000.

https://doi.org/10.1016/j.jss.2024.112229

[20] Melegati, J., et al., A model of requirements engineering in software startups. Information and software technology, 2019. 109: p. 92-107.

https://doi.org/10.1016/j.infsof.2019.02.001

[21] Bambazek, P., I. Groher, and N. Seyff, Requirements engineering for sustainable software systems: a systematic mapping study. Requirements Engineering, 2023. 28(3): p. 481-505.

https://doi.org/10.1007/s00766-023-00402-1

[22] Fricker, S. A., R. Grau, and A. Zwingli, Requirements engineering: best practice. 2015, Springer.
[23] Svensson, R. B. and R. Torkar, Not all requirements prioritization criteria are equal at all times: A quantitative analysis. Journal of Systems and Software, 2024. 209: p. 111909.

https://doi.org/10.1016/j.jss.2023.111909

[24] Bugayenko, Y., et al., Prioritizing tasks in software development: A systematic literature review. Plos one, 2023. 18(4): p. e0283838.

https://doi.org/10.1177/0739456X17723971

[25] Alhenawi, E., et al., Choosing a Suitable Requirement Prioritization Method: A Survey. arXiv preprint arXiv: 2402.13149, 2024.

https://doi.org/10.48550/arXiv

[26] Winton, J. and F. Palma, Improving Software Requirements Prioritization through the Lens of Constraint Solving. arXiv preprint arXiv: 2306.12391, 2023.

https://doi.org/10.48550/arXiv.2306.12391

[27] Noviyanto, F., R. Razali, and M. Z. Ahmad Nazri, Understanding requirements dependency in requirements prioritization: a systematic literature review. International Journal of Advances in Intelligent Informatics, 2023. 9(2).

https://doi.org/10.26555/ijain.v9i2.1082

[28] Rehman, S. U., M. Aoun, and A. Qayoom, Selection Criteria for Requirement Prioritization Techniques for software development: Data Analysis. The Asian Bulletin of Big Data Management, 2023. 3(2): p. 201-215.

https://doi.org/10.62019/abbdm.v3i2.60

[29] Achimugu, P., et al., A systematic literature review of software requirements prioritization research. Information and software technology, 2014. 56(6): p. 568-585.

https://doi.org/10.1016/j.infsof.2014.02.001

[30] Velasquez, M. and P. T. Hester, An analysis of multi-criteria decision making methods. International journal of operations research, 2013. 10(2): p. 56-66.
[31] Racheva, Z., et al. A conceptual model and process for client-driven agile requirements prioritization. in 2010 Fourth International Conference on Research Challenges in Information Science (RCIS). 2010. IEEE.

https://doi.org/10.1109/SCSE53661.2021.9568346

[32] Herrmann, A. and M. Daneva. Requirements prioritization based on benefit and cost prediction: an agenda for future research. in 2008 16th IEEE International Requirements Engineering Conference. 2008. IEEE.

https://doi.org/10.1109/RE.2008.48

[33] Perini, A., et al. An empirical study to compare the accuracy of AHP and CBRanking techniques for requirements prioritization. in 2007 Fifth International Workshop on Comparative Evaluation in Requirements Engineering. 2007. IEEE.

https://doi.org/10.1109/CERE.2007.1

[34] Ma, Y., et al., Requirements prioritization for complex products based on fuzzy associative predicate representation learning. Advanced Engineering Informatics, 2024. 62: p. 102621.

https://doi.org/10.1016/j.aei.2024.102621

[35] Gordijn, J. and J. Akkermans, Value-based requirements engineering: exploring innovative e-commerce ideas. Requirements engineering, 2003. 8(2): p. 114-134.

https://doi.org/10.1007/s00766-003-0169-x

[36] Trieflinger, S., et al. How to prioritize your product roadmap when everything feels important: a grey literature review. in 2021 IEEE International Conference on Engineering, Technology and Innovation (ICE/ITMC). 2021. IEEE.

https://doi.org/10.1109/ICE/ITMC52061.2021.9570243

[37] Hujainah, F., et al., Software requirements prioritisation: a systematic literature review on significance, stakeholders, techniques and challenges. IEEE Access, 2018. 6: p. 71497-71523.

https://doi.org/10.1109/access.2018.2881755

[38] Tonella, P., A. Susi, and F. Palma, Interactive requirements prioritization using a genetic algorithm. Information and software technology, 2013. 55(1): p. 173-187.

https://doi.org/10.1016/j.infsof.2012.07.003

[39] Racheva, Z., M. Daneva, and L. Buglione. Supporting the dynamic reprioritization of requirements in agile development of software products. in 2008 Second International Workshop on Software Product Management. 2008. IEEE.

https://doi.org/10.1145/3291533.3291574

[40] Ruhe, G., A. Eberlein, and D. Pfahl, Trade-off analysis for requirements selection. International Journal of Software Engineering and Knowledge Engineering, 2003. 13(04): p. 345-366.

https://doi.org/10.1142/S0218194003001378

[41] Khan, S. U. R., et al., RePizer: a framework for prioritization of software requirements. Frontiers of Information Technology & Electronic Engineering, 2016. 17: p. 750-765.

https://doi.org/10.1631/FITEE.1500162

[42] Achimugu, P., A. Selamat, and R. Ibrahim. A clustering based technique for large scale prioritization during requirements elicitation. in Recent Advances on Soft Computing and Data Mining: Proceedings of The First International Conference on Soft Computing and Data Mining (SCDM-2014) Universiti Tun Hussein Onn Malaysia, Johor, MalaysiaJune 16th-18th, 2014. 2014. Springer.

https://doi.org/10.1007/978-3-319-07692-8_59

[43] Aasem, M., M. Ramzan, and A. Jaffar. Analysis and optimization of software requirements prioritization techniques. in 2010 International Conference on Information and Emerging Technologies. 2010. IEEE.

https://doi.org/10.1109/ICIET.2010.5625687

[44] Mardani, A., et al., Multiple criteria decision-making techniques and their applications–a review of the literature from 2000 to 2014. Economic research-Ekonomska istraživanja, 2015. 28(1): p. 516-571.

https://doi.org/10.1080/1331677X.2015.1075139

[45] Aruldoss, M., T. M. Lakshmi, and V. P. Venkatesan, A survey on multi criteria decision making methods and its applications. American Journal of Information Systems, 2013. 1(1): p. 31-43.
[46] Guyon, I. and A. Elisseeff, An introduction to variable and feature selection. Journal of machine learning research, 2003. 3(Mar): p. 1157-1182.

https://doi.org/10.1007/s11334-022-00492-0

[47] Muhammad, A., et al., Prioritizing non-functional requirements in agile process using multi criteria decision making analysis. IEEE Access, 2023. 11: p. 24631-24654.

https://doi.org/10.1109/ACCESS.2023.3253771

[48] Ma, Q., The effectiveness of requirements prioritization techniques for a medium to large number of requirements: a systematic literature review. 2009, Auckland University of Technology.
[49] Gupta, V., et al., Requirements engineering in software startups: A systematic mapping study. Applied Sciences, 2020. 10(17): p. 6125.

https://doi.org/10.3390/app10176125

[50] Kitchenham, B., Procedures for performing systematic reviews. Keele, UK, Keele University, 2004. 33(2004): p. 1-26.

https://doi.org/10.4236/ojbm.2025.132042

[51] Brereton, P., et al., Lessons from applying the systematic literature review process within the software engineering domain. Journal of systems and software, 2007. 80(4): p. 571-583.

https://doi.org/10.1016/j.jss.2006.07.009

[52] Kitchenham, B., et al., Systematic literature reviews in software engineering–a systematic literature review. Information and software technology, 2009. 51(1): p. 7-15.

https://doi.org/10.1016/j.infsof.2008.09.00

[53] Al-Moslmi, T., et al., Approaches to cross-domain sentiment analysis: A systematic literature review. Ieee access, 2017. 5: p. 16173-16192.

https://doi.org/10.1109/ACCESS.2017.2690342

[54] Ernst, H., Success factors of new product development: a review of the empirical literature. International journal of management reviews, 2002. 4(1): p. 1-40.

https://doi.org/10.1111/1468-2370.00075

[55] Weingart, S., How many citations does a paper have to get before it's significantly above baseline impact for the field. 2012.
[56] Krishnan, V. and K. T. Ulrich, Product development decisions: A review of the literature. Management science, 2001. 47(1): p. 1-21.

https://doi.org/10.1287/mnsc.47.1.1.10668

[57] Úcar Marqués, I., et al., Growth in the number of references in engineering journal papers during the 1972-2013 period. Scientometrics, 2014, 98, 1855-1864, 2014.

https://doi.org/10.1007/s11192-013-1113-6

[58] Cheng, B. H. and J. M. Atlee, Research directions in requirements engineering. Future of software engineering (FOSE'07), 2007: p. 285-303.

https://doi.org/10.1109/FOSE.2007.17

[59] Rodriguez, P., C. Urquhart, and E. Mendes, A theory of value for value-based feature selection in software engineering. IEEE Transactions on Software Engineering, 2020. 48(2): p. 466-484.

https://doi.org/10.1109/TSE.2020.2989666

[60] Barney, S., A. Aurum, and C. Wohlin, A product management challenge: Creating software product value through requirements selection. Journal of Systems Architecture, 2008. 54(6): p. 576-593.

https://doi.org/10.1016/j.sysarc.2007.12.004

[61] Goknil, A., I. Kurtev, and K. van den Berg. A metamodeling approach for reasoning about requirements. in Model Driven Architecture–Foundations and Applications: 4th European Conference, ECMDA-FA 2008, Berlin, Germany, June 9-13, 2008. Proceedings 4. 2008. Springer.
[62] Cox, K., M. Niazi, and J. Verner, Empirical study of Sommerville and Sawyer's requirements engineering practices. IET software, 2009. 3(5): p. 339-355.

https://doi.org/10.1049/iet-sen.2008.0076

[63] Lubars, M., C. Potts, and C. Richter. A Review of the State of the Practice in Requirements Modeling. in [1993] Proceedings of the IEEE International Symposium on Requirements Engineering. 1993. IEEE.

https://doi.org/10.1109/ISRE.1993.324842

[64] Racheva, Z., et al. Do we know enough about requirements prioritization in agile projects: insights from a case study. in 2010 18th IEEE International Requirements Engineering Conference. 2010. IEEE.

https://doi.org/10.1109/RE.2010.27

[65] Wohlin, C. and A. Aurum, Criteria for selecting software requirements to create product value: An industrial empirical study. Value-based software engineering, 2006: p. 179-200.

https://doi.org/10.1007/3-540-29263-2_9

[66] Svensson, R. B., et al. Prioritization of quality requirements: State of practice in eleven companies. in 2011 IEEE 19th international requirements engineering conference. 2011. IEEE.

https://doi.org/10.1109/RE.2011.6051652

[67] Baskerville, R., J. Travis, and D. P. Truex. Systems without method: The impact of new technologies on information systems development projects. in Proceedings of the IFIP WG8. 2 Working Conference on The Impact of Computer Supported Technologies in Information Systems Development. 1992.
[68] Inayat, I., et al., A systematic literature review on agile requirements engineering practices and challenges. Computers in human behavior, 2015. 51: p. 915-929.

https://doi.org/10.1016/j.chb.2014.10.046

[69] Pattyn, F., Supporting technical paper, including the review protocol regarding a systematic literature review. 2023.
[70] Svahnberg, M., et al., A systematic review on strategic release planning models. Information and software technology, 2010. 52(3): p. 237-248.
[71] Rai, N and Bikash T., A study on purposive sampling method in research. Kathmandu School of Law, 2015. 5(1): p.8-15
[72] Boehm, B., Value-based software engineering: reinventing. ACM SIGSOFT Software Engineering Notes, 2003. 28(2): p. 3.

https://doi.org/10.1145/638750.638775

[73] Boehm, B., Some future trends and implications for systems and software engineering processes. Systems Engineering, 2006. 9(1): p. 1-19.

https://doi.org/10.1002/sys.20044

[74] Daneva, M., et al., Agile requirements prioritization in large-scale outsourced system projects: An empirical study. Journal of systems and software, 2013. 86(5): p. 1333-1353.

https://doi.org/10.1016/j.jss.2012.12.046

[75] Harman, M., et al. Search based software engineering for software product line engineering: a survey and directions for future work. in Proceedings of the 18th International Software Product Line Conference-Volume 1. 2014.

https://doi.org/10.1145/2648511.2648513

[76] Berander, P. Using students as subjects in requirements prioritization. in Proceedings. 2004 International Symposium on Empirical Software Engineering, 2004. ISESE'04. 2004. IEEE.

https://doi.org/10.1109/ISESE.2004.1334904

[77] Heindl, M. and S. Biffl. A case study on value-based requirements tracing. in Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering. 2005.

https://doi.org/10.1016/j.jksuci.2022.11.002

[78] Ruhe, G., A. Eberlein, and D. Pfahl. Quantitative WinWin: a new method for decision support in requirements negotiation. in Proceedings of the 14th international conference on Software engineering and knowledge engineering. 2002.

https://doi.org/10.1145/568760.568789

[79] Tuunanen, T. and I.-T. Kuo, The effect of culture on requirements: a value-based view of prioritization. European Journal of Information Systems, 2015. 24(3): p. 295-313.

https://doi.org/10.1057/ejis.2014.29

[80] Tripathi, N., et al., An anatomy of requirements engineering in software startups using multi-vocal literature and case survey. Journal of Systems and Software, 2018. 146: p. 130-151.

https://doi.org/10.1145/2460999.2461004

[81] Albuga, S. and Y. Odeh. Towards prioritizing software business requirements in startups. in 2018 8th International Conference on Computer Science and Information Technology (CSIT). 2018. IEEE.

https://doi.org/10.1109/CSIT.2018.8486216

[82] Karlsson, J. and K. Ryan, A cost-value approach for prioritizing requirements. IEEE software, 1997. 14(5): p. 67-74.

https://doi.org/10.1109/52.605933

[83] Babar, M. I., M. Ramzan, and S. A. Ghayyur. Challenges and future trends in software requirements prioritization. in International conference on computer networks and information technology. 2011. IEEE.

https://doi.org/10.1109/ICCNIT.2011.6020888

[84] Karlsson, J. and K. Ryan. Supporting the selection of software requirements. in Proceedings of the 8th international workshop on software specification and design. 1996. IEEE.

https://doi.org/10.5555/1784542.1784583

[85] Vestola, M., A comparison of nine basic techniques for requirements prioritization. Helsinki University of Technology, 2010: p. 1-8.

https://doi.org/10.34028/iajit/20/6/4

[86] Shao, F., et al., DRank: A semi-automated requirements prioritization method based on preferences and dependencies. Journal of Systems and Software, 2017. 126: p. 141-156.

https://doi.org/10.1016/j.jss.2016.09.043

[87] Azar, J., R. K. Smith, and D. Cordes, Value-oriented requirements prioritization in a small development organization. IEEE software, 2007. 24(1): p. 32-37.

https://doi.org/10.1007/978-3-030-27192-3_24

[88] Gorschek, T. and A. M. Davis, Requirements engineering: In search of the dependent variables. Information and Software Technology, 2008. 50(1-2): p. 67-75.

https://doi.org/10.1016/j.infsof.2007.10.003

[89] Avesani, P., et al. Facing scalability issues in requirements prioritization with machine learning techniques. in 13th IEEE International Conference on Requirements Engineering (RE'05). 2005. IEEE.

https://doi.org/10.1109/RE.2005.30

[90] Lehtola, L., M. Kauppinen, and S. Kujala. Requirements prioritization challenges in practice. in International Conference on Product Focused Software Process Improvement. 2004. Springer.
[91] Cooper, R. G., From experience: the invisible success factors in product innovation. Journal of product innovation management, 1999. 16(2): p. 115-133.
[92] Bekkers, W., et al. A framework for process improvement in software product management. in Systems, Software and Services Process Improvement: 17th European Conference, EuroSPI 2010, Grenoble, France, September 1-3, 2010. Proceedings 17. 2010. Springer.

https://doi.org/10.1007/978-3-642-15666-3_1

[93] Dzamashvili Fogelström, N., et al., The impact of agile principles on market‐driven software product development. Journal of software maintenance and evolution: Research and practice, 2010. 22(1): p. 53-80.

https://doi.org/10.1002/spip.420

[94] Lehtola, L. and M. Kauppinen, Suitability of requirements prioritization methods for market‐driven software product development. Software Process: Improvement and Practice, 2006. 11(1): p. 7-19.

https://doi.org/10.1002/spip.249

[95] Fogelström, N. D., et al. When product managers gamble with requirements: Attitudes to value and risk. in Requirements Engineering: Foundation for Software Quality: 15th International Working Conference, REFSQ 2009 Amsterdam, The Netherlands, June 8-9, 2009 Proceedings 15. 2009. Springer.

https://doi.org/10.1007/978-3-642-01853-4_8

[96] Gorchels, L., Transitioning from engineering to product management. Engineering Management Journal, 2003. 15(4): p. 40-47.

https://doi.org/10.1080/10429247.2003.11415224

[97] Cosse, T. J. and J. E. Swan, Strategic marketing planning by product managers—Room for improvement? Journal of Marketing, 1983. 47(3): p. 92-102.

https://doi.org/10.1177/002224298304700310

[98] Cleland-Huang, J. and M. Denne. Financially informed requirements prioritization. in Proceedings of the 27th international Conference on Software Engineering. 2005.

https://doi.org/10.1007/s43546-021-00073-6

Cite This Article
Plain Text BibTeX RIS

  • APA Style

    Pattyn, F., Goetz, P. (2025). Time to Value (TtV) as a Missing Requirements Prioritization Criterion for Startup Survival: Insights from Founders vs. Systematic Literature Review. International Journal of Sustainability Management and Information Technologies, 11(1), 45-66. https://doi.org/10.11648/j.ijsmit.20251101.14

    Copy | Download

    ACS Style

    Pattyn, F.; Goetz, P. Time to Value (TtV) as a Missing Requirements Prioritization Criterion for Startup Survival: Insights from Founders vs. Systematic Literature Review. Int. J. Sustain. Manag. Inf. Technol. 2025, 11(1), 45-66. doi: 10.11648/j.ijsmit.20251101.14

    Copy | Download

    AMA Style

    Pattyn F, Goetz P. Time to Value (TtV) as a Missing Requirements Prioritization Criterion for Startup Survival: Insights from Founders vs. Systematic Literature Review. Int J Sustain Manag Inf Technol. 2025;11(1):45-66. doi: 10.11648/j.ijsmit.20251101.14

    Copy | Download 

  • @article{10.11648/j.ijsmit.20251101.14,
  author = {Frédéric Pattyn and Peter Goetz},
  title = {Time to Value (TtV) as a Missing Requirements Prioritization Criterion for Startup Survival: Insights from Founders vs. Systematic Literature Review
},
  journal = {International Journal of Sustainability Management and Information Technologies},
  volume = {11},
  number = {1},
  pages = {45-66},
  doi = {10.11648/j.ijsmit.20251101.14},
  url = {https://doi.org/10.11648/j.ijsmit.20251101.14},
  eprint = {https://article.sciencepublishinggroup.com/pdf/10.11648.j.ijsmit.20251101.14},
  abstract = {Software startups operate under extreme uncertainty and financial pressure, making Requirements Prioritization (RP) a critical activity for improving survival prospects. This study investigates which prioritization criteria are most relevant to early-stage ventures by conducting a systematic literature review (SLR) of 40 studies and analyzing 358 RP references encompassing 82 distinct criteria across 10 categories. Additionally, we conducted 34 semi-structured interviews with founders from 19 software startups to compare academic insights with real-world practices. The analysis reveals a substantial gap between scholarly emphasis and practitioner needs: while "expected cost" is the most frequently cited criterion in the literature, criteria related to financial impact—such as return on investment, cash flow, and time to value—are underrepresented despite being consistently cited by the most successful startups in our sample. Notably, the criterion "Time to Value," absent from all reviewed literature, emerged as a key factor among practitioners. These findings highlight the need for a more financially grounded and context-sensitive approach to RP in startup environments. The study concludes with a call for greater alignment between academic frameworks and the realities faced by early-stage software ventures, especially in economically challenging conditions.
},
 year = {2025}
}

    Copy | Download 

  • TY  - JOUR
T1  - Time to Value (TtV) as a Missing Requirements Prioritization Criterion for Startup Survival: Insights from Founders vs. Systematic Literature Review

AU  - Frédéric Pattyn
AU  - Peter Goetz
Y1  - 2025/04/29
PY  - 2025
N1  - https://doi.org/10.11648/j.ijsmit.20251101.14
DO  - 10.11648/j.ijsmit.20251101.14
T2  - International Journal of Sustainability Management and Information Technologies
JF  - International Journal of Sustainability Management and Information Technologies
JO  - International Journal of Sustainability Management and Information Technologies
SP  - 45
EP  - 66
PB  - Science Publishing Group
SN  - 2575-5110
UR  - https://doi.org/10.11648/j.ijsmit.20251101.14
AB  - Software startups operate under extreme uncertainty and financial pressure, making Requirements Prioritization (RP) a critical activity for improving survival prospects. This study investigates which prioritization criteria are most relevant to early-stage ventures by conducting a systematic literature review (SLR) of 40 studies and analyzing 358 RP references encompassing 82 distinct criteria across 10 categories. Additionally, we conducted 34 semi-structured interviews with founders from 19 software startups to compare academic insights with real-world practices. The analysis reveals a substantial gap between scholarly emphasis and practitioner needs: while "expected cost" is the most frequently cited criterion in the literature, criteria related to financial impact—such as return on investment, cash flow, and time to value—are underrepresented despite being consistently cited by the most successful startups in our sample. Notably, the criterion "Time to Value," absent from all reviewed literature, emerged as a key factor among practitioners. These findings highlight the need for a more financially grounded and context-sensitive approach to RP in startup environments. The study concludes with a call for greater alignment between academic frameworks and the realities faced by early-stage software ventures, especially in economically challenging conditions.

VL  - 11
IS  - 1
ER  -

    Copy | Download

Author Information
Download PDF
Submit an Article
  • Abstract
  • Keywords

  • Document Sections

    1. 1. Introduction
    2. 2. Related Work
    3. 3. Research Methodology
    4. 4. Results
    5. 5. Discussion
    6. 6. Completeness
    7. 7. Threats to Validity
    8. 8. Conclusions
    9. 9. Research Agenda
    Show Full Outline
  • Abbreviations
  • Data Availability Statement
  • Conflicts of Interest
  • References
  • Cite This Article
  • Author Information

About Us

Science Publishing Group (SciencePG) is an Open Access publisher, with more than 300 online, peer-reviewed journals covering a wide range of academic disciplines.

Learn More About SciencePG

Products

Information

Important Link

Copyright © 2012 -- 2026 Science Publishing Group – All rights reserved.