I recently attended a course (the excellent LeanUX course held by my colleague Martin Christensen) and again the topic of what a MVP is or is not came up in a discussion. In the Lean startup-world an MVP is defined as the smallest thing you can make to validate a hypothesis which helps you decide if you should continue developing something or if you should stop. For more information about this, I suggest you read Eric Ries’ blog post on the topic. However, in (very) many companies and organisations the term is used to describe the first version of a product released to the end customers. This “version one release MVP” usually contains as little functionality and features as is possible without making the end customers too upset, disappointed or unwilling to pay.
Another colleague of mine, Henrik Kniberg, wrote a quite thorough and lengthy blog post about MVPs a while back where he touched upon the point I’m about to make. While quite a few people see the different uses of the word MVP as problematic, I see it as a symptom of a need for a better word for describing at least one of its currently used meanings, i.e. the “version one release MVP”. Luckily enough a good friend and coworker gave me the answer to that need a few years ago: He called the first release of the hardware product we were working on at the time the “Minimum Loveable Product”.
I have later come to understand that he didn’t coin the term and that there is no definite consensus on its definition (yes, I do see the danger and irony in taking a term and making an alternative interpretation of it compared to others, but bear with me – there is a point to this). The key to why I really like the term is the word Loveable. If you do release something that isn’t quite there yet, but has the potential to be in the future, your users really must love what they get in order for them to stick with it until the next release comes. It is not enough that it just works and that “more stuff will come”. There must be at least something included in the product that makes the users fall in love with it, or at the very least, make them feel that they really need it even at its current state.
Making the first release loveable is particularly important if the product you are making is something that the customers and users have the option NOT to buy or use (or continue using at any case). If the first release receives bad reviews or a bad reputation, there might not be many more releases. If the product idea in itself is bad, then that is probably a fair response, but if it is because the product was released with, e.g., exactly the same functionality or less than equally priced competitive products and nothing positive to differentiate it, then it might be released either too early or without thinking about the lovability of the product.
The idea that you should release early and often, I do agree with. However, for any product, there will always be a very first release. You can experiment with MVPs in the lean startup sense of the word, i.e. prototyping, wizard of oz tests etc., or use alfa/beta/pick-your-own-greek-letter-test to validate hypotheses, but a very first “real” release there has to be nevertheless. Somewhere down the road of product development, you and your team (or whoever is entrusted with making the decision) must agree that what you have is enough to meet “the public eye” so to speak. It will most likely be very far from the grand vision of the product (unless you are working in an organisation which has a “release and forget”-mindset in which case the first release will also be the only release). The product will live and evolve beyond that first release, but make sure that the product even in the very first release shows value to the users and customers. Make it loveable. Make it the “Minimum Loveable Product”.
Disclaimer: I am no longer at Crisp so therefore the comment section for this post has been closed. However, if you want to come in contact with me regarding any of the content, please email me at anneli.olsen [at] tinypaws.se.
