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.
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:
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.
There are two key stages to develop an MVP.
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.
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:
The most common and important misconceptions relating to MVPs include:
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.
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.
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:
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.
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.
Get in touch today.