There are a lot of buzz on the “lean methodology” lately, such as Lean Startup, Customer Development, Agile Development approach, etc. Every now and then you will hear startups discussing about their first Minimum-Viable-Product (MVP) they are building. You had probably asked around what is actually an MVP, and heard many interesting variations on the definition of MVP. Some define it as “the product with the smallest imaginable features set,” some said “product with the minimum features required for it to function as intended,” or “cheapest way to develop your product,” etc. There is nothing wrong with these definitions. The problem lies in the challenges to interpret it correctly.
For example, how do you define “minimum” when it comes to the “minimum features required?” When you say “cheapest”, does it mean that you hire a cheaper, inexperienced team to build your MVP, or get someone more expensive but more experienced to focus on the right area? The danger here is sometimes, entrepreneurs miss a key opportunity to establish market differentiation by interpreting the “minimum” component of an MVP to mean “nothing challenging.” Worse, they sometimes create a product that’s not competitive by rationalizing that they can get ‘something like’ the core idea by replacing a feature with something easier to implement. I am not writing here about “the definition” of MVP. What I am suggesting here is to redefine MVP in a more structured and objective manner so that there is lesser chance for misinterpretation, and it will show measurable outcome that defines the success or failure of a MVP.
I personally believe that MVP should be based on business direction (and not technology). In laymen, meaning your MVP should be driven of what your customers want, and not what technology can do. In that sense, I would like to refer to the definition of MVP by Eric Ries,
“The version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Note that he did not mention specifically on how to create the product, what features to develop, which technology should use, etc. The key here is “maximum amount of validated learning about customers with the least effort,.” or the least you can build and still gain some useful validated learning. There is nothing requires your MVP to be incomplete, buggy, shitty-looking, unstable, or any of those other things. But (and this is a key but), it might actually be any of those things, if it can be and still meet the above goals (validated learning about customers).
Once we understand that the main objective is to learn about our customers, it becomes easy to decide how minimal the MVP should be. It is important to understand that the MVP is merely a tool for learning about our customers. It is not necessarily the final product. Thus, every decision about what to do with the MVP should be based on the specific hypothesis about customers that we are currently testing. In general, there are 4 classes of hypotheses,
- Are we testing a problem hypothesis?
- Are we testing whether customer will respond to our value proposition?
- Are we testing whether the price point is acceptable to our customer?
- Are we testing whether to add a new feature?
Whatever the case may be, you need to design the minimum “product” that is just enough for you to learn what you need to know about customers (based on a specific set of hypotheses). Anything more is a waste, and probably add more noise when measuring the results of your MVP.
Just for your information, this is the same process that scientists called operationalization, where they develop hypotheses about any phenomenon in the world, and then figure out the experimental design to physically test this hypothesis. These can be as simple as a pen and paper survey, or as complex and expensive as the hadron collider. The choice of operationalization is entirely dependent on the research question at hand.
In the book Lean Startup, Eric discussed about the various choices of MVP. Each of them requires different amount of time and efforts (from low to high):
- Customer interview
- Mock ups (or video)
- Wireframe
- Concierge (or smoke screen)
You will notice that most of it does not require programming or very little programming. The most important attributes of an MVP are:
- Measurable against your product hypothesis or customer assumptions.
- Fast and flexible to change or adapt or pivot after we learnt about our customers.
Custom programming might be the most flexible solution to create the product that you wanted. But it is also the most time consuming, and cannot quickly adapt to changes or pivots. Yes, I know we can have super coders or hire more coders, but you still wasted a lot of unnecessary efforts and resources during the market validation or MVP development stage. (Remember: You efforts might go down to the drain if your product hypotheses are invalidated. You goal is to maximize the amount of validated learning about customers with the least effort.) I would only go for custom programming to develop the first release of final product once the core product hypotheses are validated, with an objective understanding of what features customers want in the product, and what design and process work for them.
Some case studies
The MVP of Groupon is a WordPress site. How their MVP work? Every week the founder manually go out and collect vouchers from various merchants, scan them, and post them on their WordPress site. After that, they blasted them to their mailing list of selected customers. They will then measure who actually view their vouchers and download them. Their product hypothesis is not to test their product features, but to test whether their customers will browse through the discount vouchers and download them from the Internet.
Google is another example of a well executed MVP. The original Google search engine was simply a text box in the middle of a white page with a search button an a Google logo. Their product hypothesis is to test the killer feature of allowing users to easily find relevant information on the Internet by searching. They measure the MVP success by validated learning in the market rather than simply building features that they thought were a good idea. Imagine that if they had spent time on developing an integrated experience with Google Maps, Gmail, Latitude, etc. they would never be where they are today.
If you want to learn from more examples, please refer to Yuki’s slides on Lean Startup – What is MVP. I met Phil Morle from Pollenizer when I attended Lean Startup Machine last year. His presentation had inspired me with more techniques for MVP development. He shared his presentation as screencast after popular demand from the audience. (I am one of them.)
Conclusion
Long story short, MVP is not about programming or software development, but it is about your savviness in product management. If you look into Wikipedia, “An MVP is not a minimal product, it is a strategy and process directed toward making and selling a product to customers. It is an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning.” A good MVP depends on how cleverly and creatively you craft your product market validation plan, and execute your development and validation in stages to minimize market risk so that you create something that your customers want eventually.
There is a Part 2 of this article you are interested to read further.
Tips: If you are planning to build your own startup or develop a new product, you can try out the Startup Checklist Test. It will show you whether you have covered all the vital steps before you venture further, which includes whether you have a good MVP strategy.
