Over the past few months I’ve had several conversations around the topic of the Minimum Viable Product [MVP] and prototyping as though they are, in some way, fundamentally different beasts. Personally, I see one as a subset of the other and view them both as part of a necessary continuum that helps maintain alignment and reduce risk during the new product development journey. Initially, you want to be sure that you’re building the right thing. Later, you want to deliver reliable functionality that makes good on the promise. In my mind, an MVP is simply one kind of prototype that happens to be focused on customer-centric issues related to desirability and viability.
© lucadp / 123RF Stock Photo
The purpose of an MVP (or more likely series of MVPs) is to produce something that allows you to learn what you need to know about your customers for the minimum amount of expended resource; be that effort, money or whatever. At the same time it needs to bring something to the table that is of value to the end-user; even if that is delivered via some intermediate ‘rough around the edges’ solution. It should represent a minimum feature set that both delivers value and validates an associated behaviour. Viability is demonstrated through a transactional exchange. Success is, therefore, crucially about action rather than intent.
This is fundamentally different to a wireframe, CAD model or mock-up that delivers no usable feature set at all; rather just the promise of one. Despite that, such tools are important precursors to MVPs and help reduce risk – primarily the risk of building something inappropriate. Thereafter, a sequence of MVPs should extend this risk reduction process by continuing to examine user-product interaction and validate each successive hypothesis and assumption.
A prototype, as defined by Wikipedia, is “an early sample, model or release of a product built to test a concept or process or to act as a thing to be replicated or learned from”. An MVP, then, is a prototype built with the distinct purpose of validating a hypothesis linking the customer/user, their problem, the solution and critical underlying business assumptions.
In relation to software development, it might seem that there is some commonality with the Beta release. However, the Beta normally has a more complete feature set and its primary purpose is to test the (almost finished) product in a targeted subset of the user community and their operational environment. The focus is on finding bugs that have made it through the testing already carried out by the development team. This is not the same as deploying an MVP. Beta testing is about verification (it does what we said it would). MVPs are about validation (it does what is needed) and this, necessarily, precedes the Beta.
In my view, prototypes can be built for either purpose. Prototypes are often created to engage with customers/users and help to convey ideas and cement understandings. In that context they might well function as MVPs and examine one or both of the drivers of desirability and viability. Additionally, though, prototypes are commonly used to verify feasibility and, in this context, may be entirely ‘under-the-hood’ focusing internally on such issues as scaling, bandwidth, interfacing, structural integrity or similar performance requirements. These types of prototype can be essential risk reducers in the development and integration of complex systems. In this case, the exchange of prototypes can really help collaborating parties align critical interfaces and functional dependencies.
In the end there is a simply a continuum of sketches, models, mock-ups, prototypes (incl. MVPs), build-test-rework iterations, pilots and successive releases as concepts solidify and the product matures. What is key is that there is ongoing engagement, learning and adaptation.
“Build it and they will come – is not a strategy, it’s a prayer.”
– Steve Blank