(Vladimir Blagojevic has created a terrific introduction/guide to Minimum Viable Products for those that aren’t familiar with the term.)
Adrian’s post pointed to a wonderful diagram by Jussi Pasadena (@jopas)—an adapted version of this diagram is included at the top of this post—about what I think is a common misconception as to what a Minimum Viable Product is, focusing too heavily on the basic functional building blocks of a product or service offering.
I’ve previously termed this idea as the Minimum Inspiring Product. Other’s have circled around this same concept with different terminology: Minimum Lovable Product, Minimum Delightful Product etc. In essence, I think we’re largely referring to the same thing—that while it’s critically important not to get carried away with overbuilding, it is important to include in a product or service elements that delight.
Somewhere in the conversation around Jussi’s diagram I saw someone mention that, in its original form, the diagram suggests that the “emotional design” element is less important than the functional aspects of an MVP. The commenter countered that, in fact, the “emotional design” aspect should hold additional emphasis than the functional in the early stages of a product’s development. (If anyone can find/remind me of the originator of this idea/adaptation, please let me know so I can accurately attribute it.)
I think there is some merit in this argument. A review of Ben Tollady and Ben Rowe’s UX Australia presentation Can you wireframe delight?, to which Jussi attributes inspiration for the diagram, supports this. In their presentation, they make the distinction between “surface” and “deep” delight. (I’d recommend checking out the Slideshare of their presentation. embedded in the link above. for a more detailed exposition of the difference.)
I would argue that “deep delight” falls within the “emotional design” aspect of Jussi’s diagram. That is, delivering that delightful experience that encourages and rewards repeat usage requires us to deliver a strong sense of emotional satisfaction, if only to overcome the shortcomings of early versions of a product that typically don’t have all the features or that fall short in delivery in some areas (congruent with the “minimal” aspect of the MVP process).
So how might we be able to deliver on delight early in an MVP exploration process?
At its core, a delightful service must come from a perspective of creating genuine value for our stakeholders/customers. What problem are you really solving for your stakeholders/customers (what is the job to be done)? Are you (truly) looking at the problem-space/solution-space from their perspective? How are you producing something that is valued (customer needs/attention), that is aligned with your values (vision/purpose)? Both design thinking and Lean Startup methodologies start from this position.
Here at Zumio we believe that products and services that respond to the market drivers of human-ness, authenticity, responsibility and co-creation have a greater chance of also eliciting delight. That is to say, a truly delightful product or service responds more deeply at stakeholder needs and creation of value beyond that which is “extracted” in a transactional view of the world/product development.
In terms of operationalisation, Pollenizer’s excellent Startup Focus book suggests the idea of a “Wizard of Oz” approach—where you create the illusion of a more fully functioning product early on, without necessarily building out the full infrastructure to deliver on this. (Vladimir’s guide also includes reference to this concept.) While at one level this advice is focused on functionality (the lower rungs of the pyramid), I think it can also be applied to get further up the pyramid more rapidly.
Thus, the “Wizard of Oz” approach enables us to produce (or at least find the locus of) the “deep delight” that Ben+Ben point to earlier in the process of discovery and customer/market validation. Then we can be confident to invest in the infrastructure that supports this aspect of value creation, not just the operational side of things.
(A key challenge here is to not end up in a situation where shortcuts taken in validation don’t hamstrung a service from scaling if it is successful. It doesn’t mean you shouldn’t have a plan as to how the service will scale from the “Wizard of Oz” phase, so that this can be actioned if the value proposition is successful. I’ve seen businesses that end up so busy patching things together behind the scenes after early success that they are unable to invest the effort required to flesh out the infrastructure to successfully support scaling. But that’s probably a topic for another time…)
Kudos to Jussi for a wonderful, simple visualisation that supports these ideas, and makes the case for a more considered appreciation of what a successful MVP means.