Minimum viable product: what it is and what it isn't

When we propose developing a minimum viable product (MVP), customers will often ask us to clarify what that means and the value it will deliver. Here, Duong Nguyen, Business Analyst at NashTech, outlines how we define, develop and learn from MVPs, and how we avoid some of the potential pitfalls associated with them.

What is a minimum viable product (MVP)?

The MVP concept itself was defined in 2001 as part of Lean Startup, and popularised by Eric Ries and others several years later. It emphasises the impact of learning on product development. When we propose an MVP approach in the early phase of engagement, we're talking about a version of a product or system that has just enough features to:

• Validate a concept with users before committing budget to full product development
• Attract or satisfy early-adoption customers
• Allow provision of feedback to influence full product development

What value does an MVP deliver?

The key premise is creation of a usable product that can be offered to customers. Observing their interaction with it provides much more reliable feedback than simply asking them how they would use a product in theory, or what features they would like it to have. An MVP also allows you to gain insight into customers' interest in your product without developing it fully. The sooner you can find out whether your product will or won't appeal to customers, the less effort and expense you will spend on a product that may not succeed.

The NashTech way: an MVP allows time to experiment

• Launch a new product or system as quickly as possible with must-have features to meet business requirements and keep within budget
• Validate new ideas or features with real end-users, to understand which features and capabilities must be part of the final product
• Make changes or adjustments to original ideas or features to improve a product or system so that it better meets business needs

There are two key stages to develop an MVP.

1. Ideas

• Choose the right technology platform
• Define a high-level solution architecture for the new product that fits in their existing (or target) technology ecosystem

We use the high-level functional requirements generated during this step ('epics' or 'user stories' in Agile terms) as the basis for scoping the MVP and estimating the build phase.

2. Build

We produce an estimate and a project plan for MVP requirements collected. The estimate and project plan cover the activities involved in building the MVP from detailed requirements analysis, design and coding through to testing to make sure the MVP is of sufficient quality. We analyse the user stories defined in the MVP scope to support implementation of the features. This approach - part of the sprint backlog refinement - helps to accommodate changes during elaboration. Once the MVP is launched, our client can learn about the product, measure customer reaction (positive and negative) and decide which features to subsequently build or adjust. We help our client to understand the customer reaction and to:

• Identify the functional requirements
• Prioritise the backlog
• Estimate and implement the new features (or changes) to continuously improve the product or system

Avoiding common misunderstandings and pitfalls

The most common and important misconceptions relating to MVPs include:

Misunderstanding the purpose of an MVP.

It's easy to think that an MVP is simply the smallest amount of working functionality that can be delivered. This ignores the fact that an MVP provides the opportunity to learn about the business viability of the product. We always stress the learning aspects of MVP, which are especially important for a Lean Agile approach.

Confusing MVP with PSI (potentially shippable increment) or MMP (minimum marketable product).

An MVP is about doing the minimum amount of work to close a learning loop, while the PSI and MMP concepts are about delivering a collection of features that solve customers' problems. This may seem like semantics, but ensuring team-wide understanding and common purpose are critical to a project's success.

Prioritising 'minimum' over 'viable'.

This approach will deliver an MVP very cheaply, but won't it be of sufficient quality to provide an accurate assessment of whether customers will want to use the final product. At NashTech we never cut corners in developing software: we work with our clients to ensure that every MVP includes these key elements:

• Functionality - the MVP's features deliver clear value to users
• Design - the MVP's design meets the highest industry standard
• Reliability - rigorous testing ensures production-quality reliability of the MVP
• Usability - the MVP is intuitive to use

The MVP is the first and last product increment.

It's not the case that once the MVP is delivered, no further changes to the product will be made. We ensure solid governance and transparency of progress, and use customer feedback received about the MVP to guide further development phases as needed.

How NashTech can help

Using MVPs as part of our ROAD method ensures we build products and systems with only the required features (viable and sufficient). This supports rapid delivery of business value and continuous improvement - and allows our clients to manage projects within budget. To find out how NashTech's delivery method featuring MVPs can help your organisation bring products to market more efficiently, visit our software development services or email info@nashtechglobal.com and a member of the team will be in touch.

We help you understand your technology journey, navigate the complex world of data, digitise business process or provide a seamless user experience.