Navigating the software development landscape: Introducing the term Research Viable Product (RVP) – Short Position Statement

I have recently just published as an open-source pre-print my thoughts and views on the need for a new term in the development lifecycle called 'Research Viable Product'.  You can read the full article here (as a pre-print) or a copy is below.

In the research software engineering community, we frequently encounter industry jargon to describe the development phase. Terms such as the minimum viable product (MVP), minimum marketable product (MMP), proof of concept (PoC) and prototype are commonly used to describe different stages in the development and testing of new software and products [1], [2]. Each term signifies a specific phase in the product lifecycle. In each phase, developers, owners, stakeholders, and teams are designed to manage risk, use resources efficiently, execute the development process to a specific standard and create software that meets user needs and market demands. 

However, the nature of research-oriented software development sometimes stretches beyond the traditional scopes of MVPs, MMPs, PoCs, and Prototypes. This raises the following question: is there a more suitable term for describing software developed in a research context? Any term should accurately reflect the objectives and challenges unique to the field of research software engineering: the research viable product (RVP) is one possible term. This term has received little use in the research software engineering community to date but could be used to describe the type of software or product more accurately developed. It is important to note that, as part of this Short Position Statement, the term ‘product’ is used in the broadest sense, encompassing digital health apps, content management systems, and algorithms implemented on Cloud architecture, among other possible products [3].

Decoding the jargon: MVP, MMP, PoC and Prototype

Before delving into the concept of RVP, let us briefly revisit the definitions of generic software development terms:

• Proof of Concept (PoC): A realisation of a specific method or idea to demonstrate its feasibility. It also has the potential for further development, often prior to the creation of a full product. It often lacks significant functionality or all outcomes or is preplanned (e.g., mocked-up).
• Prototype: An early sample, model, or release of a product built to test a concept or process, widely used across industries to refine and validate the functionality of a design.
• Minimum viable product (MVP): A product with the minimum essential features to attract early adopters and validate a product idea early in the development cycle.
• Minimum Marketable Product/Final Product: A version of a product or service that includes the minimum set of features necessary to be released to the market and satisfy early adopters or customers.

 These stages are critical in the lifecycle of software development, each serving distinct purposes, such as feasibility (PoC), refining user needs (prototype), or initiating market interaction (MVP/MMP). However, when developing software for research purposes, these terms often fall short of capturing the nuances of creating a product for testing and use within a research setting.

Introducing the Research Viable Product (RVP) 

To bridge this gap, the term Research Viable Product (RVP) refers to projects at the crossroads of software innovation and research. An RVP is defined by its readiness and intended use in a research context, specifically designed to test hypotheses, collect data, and evaluate efficacy in research scenarios while complying with research ethics and applying academic rigour. Unlike an MVP/MMP, which prioritises early market feedback through minimal features, an RVP focuses on the core elements necessary for research integrity, including data governance, protection, and security standards.

For instance, software innovations such as DrinksRation [4], [5] and RADAR-Base [6] represent the RVP approach by prioritising research objectives over broader marketability or user interface design. Considering DrinksRation as a case study, this RVP was developed to investigate user patterns in alcohol consumption and its health impacts. Unlike a typical MVP, the DrinksRation was designed from the ground up to ensure robust data collection, scientific rigour for a randomized controlled trial, adherence to stringent privacy regulations, and facilitation of statistical analysis, all of which are key aspects of a research tool. This is not the case when we consider other existing terminology.

Why is the distinction important?

Distinguishing MVP, MMP, PoC, and Prototype from RVP is not purely semantic; it addresses the core challenges and objectives specific to research-centric software development. By focusing on hypothesis testing, data integrity, and adaptability to research settings, the RVP acknowledges the unique ecosystem within which research software is developed.

Moreover, by involving participant input from the earliest stages and adhering to the highest data governance standards, RVPs offer clarity in the development process in research contexts. This approach not only ensures the relevance and reliability of the research conducted but also enhances the potential impact of the findings.

Future steps in research software development

The introduction of the RVP signifies a shift in how we should approach software development within research settings. It is challenging to focus on the unique demands of research integrity, participant involvement, data security and professional assurance above traditional development milestones.

As the term RVP develops, fellow researchers, developers, and stakeholders are encouraged to engage in the dialog. How can we better adapt our development processes to meet the intricate demands of research? What challenges and opportunities do you foresee in adopting the RVP terminology?

 References

[1]       A. M. Davis, E. H. Bersoff, and E. R. Comer, “A strategy for comparing alternative software development life cycle models,” IEEE Transactions on Software Engineering, vol. 14, no. 10, pp. 1453–1461, Oct. 1988, doi: 10.1109/32.6190.

[2]       R. Jain and U. Suman, “A Systematic Literature Review on Global Software Development Life Cycle,” ACM SIGSOFT Software Engineering Notes, vol. 40, no. 2, pp. 1–14, Apr. 2015, doi: 10.1145/2735399.2735408.

[3]       I. Cosden, “What is a Research Software Engineer?,” Ian Cosden Blog. Accessed: May 06, 2024. [Online]. Available: https://cosden.github.io/what-is-an-rse

[4]       D. Leightley et al., “Evaluating the Efficacy of the Drinks:Ration Mobile App to Reduce Alcohol Consumption in a Help-Seeking Military Veteran Population: Randomized Controlled Trial,” JMIR Mhealth Uhealth, vol. 10, no. 6, p. e38991, Jun. 2022, doi: 10.2196/38991.

[5]       D. Leightley et al., “Drinks:Ration - The role of a smartphone application in reducing alcohol consumption in a veteran population seeking formal mental health support,” London, UK, 2022. [Online]. Available: https://kcmhr.org/pdf/2022_ration_report.pdf

[6]       Y. Ranjan et al., “RADAR-Base: Open Source Mobile Health Platform for Collecting, Monitoring, and Analyzing Data Using Sensors, Wearables, and Mobile Devices.,” JMIR Mhealth Uhealth, vol. 7, no. 8, p. e11734, 2019, doi: 10.2196/11734.

Citation:

Leightley, D. (2024, June 25). Navigating the software development landscape: Introducing the term Research Viable Product (RVP). Retrieved from osf.io/5n37j