In my previous post on User Stories, I introduced the concept of Minimum Viable Product (MVP).
In 2001, Frank Robinson first mentions the term to describe that smallest release that Maximised ROI vs Risk for the company that made it.
This product release included shipping, marketing etc and customers using the thing you build.
Discoveries were recommended as a way to understand your customers deeply, and use iterative prototyping and testing to validate that your solution really would be viable.
In 2011, software was more commonly released online, and evolved continuously. Just think about how the apps you use have evolved over time!
This is when Eric Ries (from The Lean Startup) changed the definition to refer to the smallest thing you could make or do, to Test Your Hypothesis.
He moved the focus from big releases to learning faster.
Validated Learning
He used Validated Learning, the process to declare our hypotheses, identify risks and assumptions, then create tests that help us reduce risk. The aim became smaller successful releases, testing your ideas faster, developing higher quality software more predictably, all leading to reduction in time spend and cost.
Explanation of above image:
In the top row, you can see the traditional method of development. In this case, all you can offer users are wheels, spare parts, the machine frame, and an assembled car. You will spend a lot of time and a substantial amount of the budget for assembling, but there is a chance, that the final result will not satisfy the customers (i.e.: the market will not need your product).
The second method is based on creating an MVP product. Concentrate on the user's problems (to get from one point to another) and introduce to them the MVP solutions. For example, one might begin with the skateboarding example.
This post first appeared here, and used information from Jeff Patton, syncdev.com, gearheart.io
If you want to hear Jeff Patton talk about MVP, I highly recommend this video.
Comments