Ian Lamont wrote a great post about minimum delightful products based on an email I sent him. I thought I’d elaborate on the thinking.

One of the most popular ideas to emerge in the software industry in recent years is the concept of a “Minimum Viable Product (MVP).” By focusing on building an MVP you reduce the chances that you’ll build a product customers don’t want. You can think of it as the basis of a broader methodology that leverages customer and user research throughout the development process.

At face value MVP is a great idea because the concept addresses a major anti-pattern in product development: building too many features and the wrong features as a result of spending too much time in development without shipping or getting real feedback from customers and users.

Focusing on “minimum” is generally simple. It helps to correct against the tendency to build features because they are “cool” even if it’s unclear whether or not people want them.

Adding the idea of “viable” counter balances the effort to be minimal by focusing attention on the fact that below a certain threshold the product becomes unusable and/or unpurchasable.  Figuring out what a customer considers viable can be tricky. But, theoretically iteration, research and dialog will get you there.

Using a merely viable product is like visiting someone in an intensive care unit. They’re alive, but not fun to spend time with.

For certain categories this is straightforward. For example, an enterprise business system will usually win on underlying technological innovation, features, and sales/marketing. If you can get just enough features to start selling, then you have something viable. You’re off and running.

But for many circumstances, achieving a MVP simply isn’t enough to succeed.

For consumer products, SMB apps, software tools, hardware, retail, and other categories “viable” isn’t compelling. Using a merely viable product is like visiting someone in an intensive care unit. They’re alive, but not fun to spend time with. As a result, I see more and more companies who focus on MVP produce products that fail to achieve their goals.

The alternative is to focus on creating a Minimum Delightful Product (MDP).

The idea of minimum is just like it is in MVP: build only what you need. The interesting part is making the product delightful instead of merely viable. Delightful products users fall in love with. They immediately become part of a user’s life or work. When a product is delightful it just makes sense. It works the way you’d expect and the experience is highly satisfying. Delightful products are adopted faster, get better word of mouth, and create higher satisfaction.

But it begs the question, what makes a product delightful? This is a question that I’m sure has been pondered by many others wiser than me, but I believe delight is the result of three elements coming together:

1. Product gestalt
2. Design
3. Quality

Product Gestalt

Most products achieve delightfulness first and for most through their core “product gestalt” — for lack of a better phrase. (I think Alan Cooper may have coined this in The Inmates are Running the Asylum, but I couldn’t find the exact reference.)

The product gestalt defines the soul of the user experience. It’s the combination of UX and functionality that makes the product fundamentally wonderful. Usually the gestalt is the part of a product that remains relatively constant over time:

• The simple search box and results page on Google
• The friends list and news feed on Facebook
• The way that Adobe Dreamweaver could round trip between HTML and WYSIWYG
• The SAP API model
• The basic architecture of apps and a multi-touch UI on the iPhone and iPad

You can’t achieve a great gestalt by simply accumulating the right features. It comes from the right elements working together so users stop thinking about the technology and simple achieve their goals.

When the gestalt is great the product feels inherently complete and right even it doesn’t have all the functionality you may want as a user. One of the temptations with the MVP approach is to build a bridge that only goes halfway across a ravine and then to ship it so you can get iterative feedback. The feedback amounts to “this bridge sucks” even if a bridge across a ravine is a brilliant idea. Without the end-to-end experience, the product simply feels broken or nonsensical to the user or, in the case of the bridge, very dangerous.

By completeness, I don’t mean all the features you can imagine. Minimum is still critical. I think of completeness in the terms that Ken Schwaber, who invented Scrum, used when he talked about shooting a tracer bullet through a product in Agile Project Management with Scrum.

A tracer bullet gives you the smallest amount of functionality you can from end-to-end so the whole product works. Instead of shipping Facebook with the news feed but no friends. You do friending and the news feed, so you get the whole experience, but you leave out all kinds of features that might make both of these core components better.

Design

Gestalt is by far the most important component of delightfulness. The next component is graphical design. I believe deeply in the value of design, but I think it’s secondary to gestalt. Graphical design doesn’t mean lots of flourish. It came be very simple such as the layout of the Google search box and SERP or something as rich as OS X. As humans we have always found happiness and joy from beauty. Products that are beautiful are delightful.

Quality

Finally, the last element of delight is quality. A brilliant gestalt and beautiful design lose their value when the quality sucks. Unfortunately, all too often MVP becomes VCP (very crappy product). Ironically this comes from losing sight of a very core agile concept: when something is done it’s done. Put differently, if a feature is built it should work without problems. The feature may not include all the functionality you can imagine, but what it does include has to work well.

Arguably the very core of the iPhone gestalt is the multi-touch screen. When it was first built, the original plastic screen achieved the gestalt and design, so the iPhone went in production. But then at the last minute, after carrying the phone around for few weeks, Jobs decided that the plastic screen was not high-enough quality; it scratched too easily. With only 6 weeks left to actually ship the first phones, he demanded the team change to glass, and through a herculean effort they made the switch and shipped on time.

The iPhone is one of the single most successful consumer technology products. Imagine if the Apple team built the iPhone using a highly iterative process based on MVP. Surely they would have shipped the plastic screen. What other things would have they have skipped? Forget the app model and just put on fixed functionality? Get multi-touch mostly working but also throw on a fold out keyboard just in case? How many crappy versions would we have had to suffer through to get to the amazing product that was the 1.0? (Perhaps looking at the history of other handset makers will give you a sense.)

No doubt Apple did a lot of testing and prototyping, but at the same time they set themselves a very high bar for what they actually shipped. They didn’t ship until they got the gestalt right (multi-touch screen and app framework), the design was beautiful, and the quality was there.

Yet with all that, the 1.0 left many things out. Batter life was poor, the screen resolution could have been better, the camera functionality was minimal, the traditional smart phone apps (contacts, mail, phone, calendar) were no better, some would argue they were worse, than the market leader at the time – the Blackberry. Also, there was no real marketplace of apps, no front facing camera, etc. Did all these gaps make in “minimum”? I would say yes. But minimum didn’t sacrifice delight.

Conclusion

In software one has more latitude than hardware. You can more easily iterate and change. So software people may dismiss the iPhone example. But many software products as well as other products such as retail stores and consumer services would be well served by focusing on MDP not MVP.

Before you get too excited about hacking stuff out and getting live fast, take a step back and show some respect for your users. Work through the problems associated with creating a delightful product at the same time you keep the functionality to a minimum and come to market as fast as you can within the constraints you face.

Finally, keep in mind that while iteration and feedback are invaluable, creating great products doesn’t simply happen by absorbing customer feedback and A/B test results. It also comes from insight and craftsmanship.

Not every engineer designs great products, just like not every painter paints wonderful pictures. No amount of iterative testing will replace the genius of inventing and designing brilliant products that are delightful to use. So don’t be afraid to honor the craftsmanship that you and your team put into your product and the desire to give users something wonderful or, even better, magical.