Minimally Viable Products are a myth or, if you prefer a mental model. Always wrong but sometimes useful. Original Image: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable by Henrik Kniberg Very much like Prometheus and the fire or Icarus and the sun they are powerful analogies and ideas that shape our view of the world. A tribute to their power is that, thousands of years after their creation, we still relate to them even if their initial context is long gone. As a product manager, it would make sense to embrace and use the MVP myth. But should you? All these myths have an historical context that is key to their understanding and also key to decide if you should pursue these myths … or not. In the case of MVP, this myth was created in the context of start-ups as a way to minimize waste and help these newly born organizations and teams find product market fit in small, iterative, agile steps. A ( ) is a version of a product with just enough features to satisfy early customers and provide feedback for future . minimum viable product MVP product development If you are not in such a context, pursuing and MVP approach will be impossible and detrimental to both your team, product, career and users. I discovered this the hard way when my team and I were tasked with the complete replatforming of the shipping rates configurations for … one million merchants. Coming from way smaller organizations, my original approach was to adopt the MVP framework and deliver incremental value. I quickly discovered that this was a mistake: successful organizations have safeguards to protect their customers. Most of these safeguards are part of the company culture. And culture is more powerful than your product manager desires ;-) The safeguards are processes, tools and organizational systems that protect product teams from themselves. They limit the blast-radius of any product launch while maintaining a safe space where the product team car experiment and fail, learn and grow. To reflect this, each crafts (UX, Engineering, Product) have rituals to ensure the usability, speed, scalability and value of what will be launched. Initially, it could be easy to get frustrated at what appears as slowness and red-tape. In retrospect, I really think that this chain of events was caused by my unwillingness to embrace the complexity, scale and depth of the problem space I was exploring. I was consistently trying to nudge, convince, charm, influence any decision in order to force the MVP approach. In a way, I was a blind MVP believer mainly because I applied this successfully in other venture and was also coaching and helping entrepreneur to successfully adopt it. So what happened? Well, at some point the project was almost cancelled and only three persons, a minimally viable team composed of one experienced representative of each craft (UX, Engineering, Product) worked on the project. Once we took the time to reflect on what we needed to build, the minimal functionality and the enjoyable user experience, a team was reassigned to the project and we were able to build it. But for more than 18 months we had exactly … 0 customer, 0 user and of course no MVP at all. Are you a blind MVP believer? MVP is what is defined, in philosophy, as an orthodoxy: you are either a believer or … a non believer. And by the way, the holy text has already been written: do not expect to change it or reinterpret it. Like any orthodoxy, a single mental model to apply for product development can only lead to stress, burnout, stagnation, less innovation, less diversity and less fun. This is why I believe it is time to introduce another mental model linked to product development. MVP is very specific to a certain culture and context. If your organization does not have the culture or context relevant to MVP, don’t try to use this orthodoxy. The Minimally enJoyable Product (MJP) What is an enJoyable product, can you explain? Based on my experience in a highly successful organization with a great culture and incredible growth, here is the proposed definition: A Minimally enJoyable Product is a product which scope is the one needed by the market at launch and with a quality and user experience that matches or surpass the one expected by users: it sparks Joy for its users. What is Joy? I will use a great definition written by C.S. Lewis: “Joy, which is here a technical term must be sharply distinguished both from Happiness and Pleasure; the fact that anyone who has experienced it will want it again… I doubt whether anyone who has tasted it would ever, if both were in his power, exchange it for all the pleasures in the world. But then Joy is never in our power and Pleasure often is” C. S. Lewis This definition is interesting because it contrasts Joy with pleasure and even happiness. It is also an experiential definition: you have to experience it. Can a product bring joy? Please think about it: when is the last time you experiences joy using a product? Why? Was this experience crafted for you? Why Joy? The MVP mental model was created in a world of scarcity. There was no recipe for start-up and start-up where few. We now live in a world of abundance. Start-ups are legions and the recipe for success is now well documented. Capital is also broadly available. The cost to develop a software are lowered every day with the generic availability of open-source libraries and the cloud remove the need for costly servers with a pay-per-use model. Most if not all organizations have adopted agile methodologies to ship faster. In a world of plenty, as a customer, which product will you chose: A product that is valuable and usable? A product that is valuable, usable and brings you joy? How to use the MJP model and how does it differ from the MVP model? Quality Most of the time, startups don’t have a clear culture or definition of quality. This is why the first hires are high-potential and self-motivated individuals with experience. The most senior people ensure the quality but this is an "as you ship" activity. The minimal quality is not defined and will be part of the MVP learnings. Most of the startup do not have a "design framework", not product management methodologies, no or few "playbooks" , "standard operating procedures" and "service level agreement". Customers expectations By definition, start-ups don’t have customers. Really. They are seeking another myth, the Product Market Fit. If you already have customers, you can not use the same tactic. You already have product market fit! Your users have certain expectations regarding your product and a MVP is not one of them. They rely on your solution on a daily basis. And they expect an easy to use, powerful product. They also want to enjoy the experience. If not, competitors will joyfully welcome them and help them solve their problems. What happens to products that do not spark joy? In a world of abundance, and not living in isolation in a monastery, you will be faced with alternatives that seems more enjoyable. Friends will start to invite you or recommend these products. And at some point, you will test it and experience joy. Then you will switch product and enjoy it with your friends or co-workers. Marie Kondo is famous for her Konmari method: Image source: Yourtango.com Once you have done this, you can give it, recycle it or … stop paying for it in the case of software as a service or similar service products. It will remain a nice memory like your first videogame, IRC, ICQ, MySpace and all these products who where sparking joy at some points in our lives but they now have disappear. Only pleasant memories remain. A positive example would be the Zoom success because of Covid-19. While other group-video conferences have been around for ages, most of them were not sparking joy: complex to use, tight to google, tight to facebook, tight to apple, not working at every occasion, no fun background to play with, etc. Conclusion The MVP model is not enough for established companies and as a consequence for start-up who expect to disrupt the incumbents. In times of abundance and intense competition, products have to aim higher than bare-bone usability and viability. Companies and product managers should have higher goals: they should aim for Joy and ship a Minimally enJoyable Product.
