Don’t Give Us Viable Product (MVP): We Want Joyful Product (MJP)!

Minimally Viable Products (MVP) are a myth or, if you prefer, a mental model. Wrong most of the time but sometimes useful.

Original Image: Making sense of MVP (Minimum Viable Product) — and why I prefer Earliest Testable/Usable/Lovable by Henrik Kniberg

Like Prometheus and the Fire or Icarus and the Sun, MVP is a powerful mythology that helps shape our understanding of the world. A tribute to these myth is that we still relate to them thousands of years after their creation, even if their initial context is long gone.

As a product manager, embracing and using the MVP myth would make sense. But should you?

In the case of MVP, this myth was created in the context of start-ups to minimize waste and help these newly born organizations and teams find product market fit in small, iterative, agile steps.

A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.

If you are not in such a context, pursuing an MVP approach will be impossible and detrimental to your team, product, career and users. I discovered this the hard way when my team and I were re-platforming the shipping rates engine for more than one million merchants.

Initially, it could be easy to get frustrated at what appears as slowness and red tape. I think this chain of events was caused by my unwillingness to embrace the complexity, scale and depth of the problem space I was exploring.

Coming from smaller organizations with a smaller user base, my original approach was to adopt the MVP framework and deliver incremental value. I quickly discovered 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 potent 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 can experiment, fail, learn and grow. To reflect this, each craft (UX, Engineering, Product) have rituals to ensure the usability, speed, scalability and value of what will be launched.

I consistently tried to nudge, convince, charm, and influence decisions to force the MVP approach. In a way, I was a blind MVP believer mainly because I applied this successfully in other ventures and was also coaching and helping entrepreneurs adopt it.

So what happened?

At some point, the project was almost cancelled, and only four persons, a minimally viable team composed of one experienced representative of each craft (UX, two Engineering leaders, 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 could make it happen.

But for over 18 months, we had precisely… 0 customers, 0 users and, of course, nothing like a MVP. We developed: a feature flag to activate the new UI so that we can do user-testing, feature flag for the API (idem), feature flag to generate rates at checkout. We had a simulator that we could run against any checkout to check the accuracy of the new platform that we ran daily against all the checkouts. We had an automated converter from the old system to the new system that we ran about 15 times to generate new configurations and to run our simulations (migrating >1 million shop so that we can soft launch is ... a long process!). We discovered a gazillion of bugs and edge-case with our current system and we never succeeded to reach a 100% comparison but were ready to launch once our 99.96% accuracy goal was reached. Lots of things that do not meet the definition of an MVP ;-)

We were able to launch once we had all our quality control in place, the ability to demonstrate to our stakeholders that partner were excited (they were enjoying the product and our new API!), new users were able to accomplish their goals (shipping rates per product and shipping rates differing per location!) and we maintained backward compatibility for the existing users and apps at migration time (we called this a slowly breaking change!).

The culture of the organization prevented the application of the MVP model because the stakeholders knew both the complexity of the problem space and the impact it could have on our customer's businesses.

Limits of the MVP model

The MVP mental model was created in a world of scarcity. There was no recipe for start-ups, and start-ups were 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 more broadly available. The cost to develop software is lowered daily with the generic availability of open-source libraries, generative AI and cost-effective cloud solutions with a pay-per-use model. Moreover, most, if not all, organizations have adopted agile methodologies to ship faster.

The Minimally Joyful Product (MJP)

What is a Joyful 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 Joyful 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 expectations. It sparks Joy for its targeted users: the one your product or feature help succeed.

It is applicable to new features, upgraded features as well as new product.

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 as well as 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?

How can you create a MJP?

Let's follow Marie Kondo method:

Said simply, you have to remove what is not needed and what is causing negative feelings to your users: flows that are  hard to understand stuff,  weird, hard to find , hard to activate. For this first part, it is very close to the definition of MVP: you try to cut scope as much as you can.

The key difference is the quality of the product: it is not only useful (MVP) but it also spark joy (MJP) for the user! It includes, in particular, the quality your users expect, the messaging they expect from your brand (cheeky? serious and strict? direct? etc.) as well as the reliability and performance they expect.

Sparking Joy is a bar raiser for the quality of your first release and great enabler for your UX team: let's aim higher than the strict functionality and consider the feelings and emotions caused by your products on your target users.

Question & Answers

Do you have an example of MJP?

A positive example would be Zoom's success during Covid-19. While lots of others great solutions existed at the time (WebEx, Google Hangout, Facetime, etc.)  that have been around for years, none were able to capitalize on the strong need to connect during the pandemic. None of the competing solutions were trying to spark joy: they were very serious solutions for businesses with a lot of friction to adopt and use.  The alternate solutions were complex to use, only working in specific environments (your work, Google, Facebook, Apple, etc.), not intuitive (never working well?) for non-technical users, not fun to use (effect, background, etc.).

When should I use the MVP model?

Often, startups don’t have customers and they have a lot of flexibility. Using the MVP in this context makes a ton of sense.

Use the MVP model when you have similar context outside of a startup for instance: launching a new offering with a new name (no string attached!), launching a feature to non-customers (they will have no expectations from a previous experience).

When should I use the MJP model?

If you already have customers and have product market fit and if you target the exact same customers, you can not use the MVP tactic. You already have product-market fit! Your users have expectations regarding your product and services and launching in the wild an MVP is not one of them.

They rely on your solution daily. And they expect an easy-to-use, robust product. They also want to enjoy the experience. If not, competitors will joyfully welcome them and help them solve their problems.

Take your own experience in consideration. As a user of numerous product living in a world of abundance (not living in isolation in a monastery), you are faced with more enjoyable alternatives. 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 products and enjoy it with your friends or co-workers.

Conclusion

The MVP model is not enough for established companies. Your current users ex-expect quality, ease of use and joy. Companies and product managers should have higher goals than functionality and usability: they should aim for Joy and ship a Minimally Joyful Product.

Feedback is a gift 🙏🏼: don't hesitate to share your thoughts!

You can comment on this article or reach me:
- email: ben@radicaloptimist.org,
- LinkedIn