“Minimum Viable Product” or MVP should be pretty familiar to anyone who’s been keeping an eye on the developments in business and software development practices over the last few years, particularly in Silicon Valley and the lean startup movement. If you spend any time on Medium, you’ve probably read an article with a title like “7 Ways to Minimum Viable Product your Life in Just 30 Days”. In fact, I might go ahead and write that article!
Minimum Viable Product
But I digress. When I started talking about minimum viable products with some of my coworkers that are not developers, I did find that many weren’t aware of the concept so briefly the aim with a minimum viable product is to get as quickly and cheaply as possible to the most basic version of your product and get feedback on its value, flaws, potential improvements, etc before spending the time and money required to build a full-featured product. A sort of rapid prototyping (but may not even be a prototype!) Or, to quote Eric Ries:
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
There are some nice examples in Eric Ries’s book The Lean Startup such as how Dropbox got started with nothing but a video.
Cutting A Slice
Anyway, I actually wanted to pick up on a point from Carl Woodward’s blog here where he highlights the risk with minimum viable products of creating “the worst version of all features” and instead advocates creating a “pretty good slice” which he characterises as follows (with my paraphrasing):
- Polished – not to the highest level of polish but feels close to finished and pleasing to the eye.
- Onboarding – so that users can quickly understand what the feature is about. (Like Dropbox’s famous video)
- Blank slate – gives the user a sense of what will be there once missing content is added.
- Fully-ish Featured – Any graphs, info, etc that make the feature complete are present and working.
- Decent Copywriting – not yet perfect but decent!
An interesting concept that’s worth some more thought. In the project I’ve been working on using Firebase, I wonder whether I should’ve in fact kicked off at the other end. I’m only just getting to the core feature from the user perspective (an innovative interactive data visualisation). I have a sketch of it but probably I should have started by building a polished version of that and showing it to some potential users for feedback rather than getting sucked into working out some of the back-end data storage and security that mostly happens out of view of the users.
Oh well, nothing’s wasted! What do you guys think? Anyone taking a different approach that’s working well? Let me know in the comments!