Minimum Viable Product
Customers want what they want not what you want for them. As such, the discipline of Minimum Viable Product is one I hope you learn more about soon. I think Eric Ries says it best, but I wanted to sum up my perspective for you.
MVP as a methodology enables designers to determine whether people want what they are building – in a manner that gauges acceptance and demand – yet preserves capital and time. This is accomplished by allowing designers to validate assumptions about their “product” in two important aspects: its value and the demand for it.
By definition, MVP is the version of a product that gets built through one cycle of a build, measure, learn loop – as fast as possible. Once the MVP is confirmed (keep in mind, it may take a few iterations), other lean methodologies can be employed to build upon it.
MVP = 3 things: value, use, & speed
Valuable – understand if your product is valued
Make an assumption about the value-exchange created by your product and test it thru iteration until it validated or dropped. Value is defined through the lens of the customer – not what you want for the customer. If no value is confirmed, no product should be created.
Usable – make your product usable and it will get used
MVP asks that you focus on delivering product experience – not on documentation or large feature sets. Usable is more broad a term than just usability. The real test is the usage of the product in the manner you anticipated, not necessarily its first pass at usability. Although you can’t get usage without usability, so be careful not to forsake usability for speed and minimum moving parts. Form and function must appear simultaneously – with minimum function allowing for a simpler form.
Speed – take your product to market quickly
By only building what is deemed most valuable in order of priority to the customer, and progressing through iterative builds, you ensure speed to market and successful releases. When you are wrong, you fail fast (and cheap). MVP assumes iterate until you find the ideal solution. Start small and add on based on customer need.
So how can you best focus on your (MVP)?
Getting to MVP is actually fairly simple. I suggest this path.
- Start with the features that allow the “app” to be deployed, and no more. Be disciplined here. Do not let your shovel makers and hole diggers get the better of you. Get to the orange juice quickly. You can work on other recipes soon enough.
- Launch to your defined early adopters (they are forgiving) and get feedback. Oh yeah, it stands to reason to work with people who want to work with you. If you know people do not like the taste of orange, avoid them. Finds the ones that do and test your MVP with them first. If you cannot “sell” the vision to your early adopters how will you do it with anyone else?
- Add what is relevant to extend value incrementally. OK, do not let the shovel makers and the hole diggers add a little bit at a time and test it. Make sure you are keeping true to the original “value” part of the app!
- Now just keeping doing that!
This BLOG by Alexander Osterwalder is very useful for helping you get started.
By the way, you should not use MVP as a start if you are not committed to proceeding with other lean methodologies afterwards that allow for a continued iterative process – lest you lose the “value” in your product. More on this at another time.
To your health,
The Team at imagine.GO
