Minimum Viable Product vs. Minimum Delightful Product

Minimum delightful product

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.


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.


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.


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.


  • Kevin Berrey

    “The gold medal goes to the simple dive done well.” A former Saturday Night Live writer and performer Ali Farahnakian applied this quote to writing good sketches and jokes and it struck me while reading your piece as an apt metaphor for honing the elements of a Minimum Delightful Product. Cheers

  • Cezary Pietrzak

    Adam, I love the idea of MDP as it’s something I’ve thought about for a while. As you point out, it’s not enough to put out a crappy product that just works only because it will minimize the time necessary to launch. People today have growing expectations for startups and increasingly shorter attention spans, so if a product doesn’t delight from the start, it’s facing an uphill battle to gain traction. Aside from the MDP elements you described (gestalt, design, quality), I’d argue that having a great go-to-market strategy is part of (or complementary to) MDP. There’s so much competition in the market today that both good and bad products are getting lost in the mix. And even if you’re able to craft a beautiful product experience, people may still not notice the difference on a functional level, so a big differentiator will be the way you convey your message and select the right audience.

  • Anonymous

    Cezary, This is a great point. When talking about an MVP or MDP, we should be talking about a “whole product” not simply the features, but also the experience around the product acquisition through support. 

  • Arkadiusz Dymalski

    Interesting post. I believe that the concept of Minimum Desirable Product and Minimum Feasible Product might be interesting for you

  • Emarson Victoria

    Great article. I fully subscribe to this idea. Key issue among MVP community is agreeing on what is ‘Minimum’. And the danger of sending out the product out faster means there is not enough to test and validate against in the first place.

  • Paul Pedrazzi

    Great article. I have seen so many teams use MVP and iteration as an excuse to ship junk. Required reading. Thank you.

  • skmurphy

    Ian Lamont’s blog post on the Invantory site was taken down when they shuttered Invantory. You might link to this post instead.

    If the premise of your article is that startups should not be content with a minimum viable product I think few entrepreneurs would disagree. But I worry that if you don’t ship until you believe you have achieved minimum delight you may raise the bar too high and never actually learn enough without early customer feedback to achieve the gestalt that a great product embodies. An MVP is not designed to prevent a delightful product, it’s designed to start the real conversations with your customers that allow you to create one.

  • Brian

    You said: “But for many circumstances, achieving a MVP simply isn’t enough to succeed.”

    That’s not true. You should have said “But under no circumstances is an MVP enough to succeed.”

    The goal of an MVP is to get quantifiable learning (success is in the application of that learning).

    Building an MVP is an iterative process: Build-measure-learn-build… So it’s inaccurate to imply that you build a minimum product and hope for success. You seem to be saying that the goal of your MVP is business success. That’s not to be expected from your first MVP.

    The point of a MVP is to reduce risk, learn quickly, and apply that learning to build one high quality MVP upon another.

    If your goal is to build a great user experience, build an MVP to test your hypothesis: Users will find that XYZ constitutes a great user experience. Validate that hypothesis for the least risk. Build an interactive prototype or whatever. Iterate. That’s the spirit of MVP.

  • Mark P.

    Brilliant, thank you.

  • Vivek Binepal

    Cool advice, thanks :) Cheers

  • Matthew Krickeberg

    I think the problem is the vaporous nature of ‘viable’. The distinction between minimum viability and minimum delight seems in most cases negligible and a bit of hair splitting. To me, viability is a spectrum which includes, on one end, junk. But at the other, it can, and should, be delightful. A product that doesn’t instill the user with at least a spark of delight is not at all viable. The bridge that spans half the distance (or 99.9% of the distance, for that matter) is not a ‘viable’ bridge, and unless the point of the trip was to find a beautiful bridge, just getting to the other side is something of a delight in itself (however fleeting).

    Beyond that point, I think Brian summed it up beautifully.

  • Anonymous

    Thought I’d reply to Brian, Matthew and some of the other questions that people have raised.

    The unifying thread in the comments to this article is that MVP should be interpreted as “getting iterative customer feedback as you build your product.” Another way to think about this is that MVP is not a thing it’s a process. The conclusion is that if people were to start focusing on delight then they would stop iterating, stretch out development cycles, increase risk, and likely fail. Moreover, viable doesn’t preclude delight, so if delightful is required for viability, than it fits under MVP.

    However, if building MVPs as a product development strategy is reduced to merely “get customer feedback as you build your product,” it’s not a particularly innovative idea. It’s simply a new name for something that good product developers have been doing for a very long time. A broad array of methodologies have been deployed to do this in the software industry and many other industries (e.g. 3D design models, usability studies, paper prototypes, contextual interviews, ethnographic studies, focus groups, work modeling, etc.)

    As I see it in practice, MVP is something different than simply “doing customer research.” It seems to generally be interpreted as build and ship something customers can actually use and get feedback on that. In the literature, some people argue that a paper prototype can be an MVP. But at that point, again, MVP just becomes a du jour term for market research by any methodology. Put another way, if MVP simply means iterative market research, than there is no debate. Market research and iteration on ideas during the course of a product creation process is a good thing. But, I don’t think that’s how most people interpret it in the real world.

    If we accept that to qualify as an MVP, some usable product even if it’s only at a very basic level, has to actually be shipped to some customer for feedback, then it begs the question do all products and all markets lend themselves to this approach? Is it truly universal? Should every startup approach every product creation problem this way?

    The argument I’ve tried to make is that we shouldn’t rigidly adhere to this process in every situation. Moreover, there is good evidence that some of the most successful products built have not started with a minimal version shipped to customers first. The example I use above is the iPhone. Now one could argue that there were probably many prototypes of the iPhone that circulated within Apple before it was shipped. But that comes back to the point above, if we interpret MVP as shipping a product to a customer, which is surely implied by the use of the word “product,” then we should ask why the first iPhone was not a much more simple product when it shipped. Perhaps the first iPhone was “minimally viable.” But that’s hard to imagine, and Apple’s failure to really change anything material in the core design and functionality since the product was first released would argue that the first iPhone went well beyond viability to something more. I argue that has something to do with delightful.

    My point above isn’t to argue that we should abandon MVP as an approach. It’s a good approach in many circumstances. Instead the goal is to challenge the current dogma that it is the only approach. To think this way is limiting, and it ignores the reality that some great products do not follow the proscribed MVP path, and some problems/markets do not lend themselves to this approach.

  • pelaprat

    Fair enough about products being delightful, but…

    The example of Apple’s iPhone is pretty poor. You admit that “there were probably many prototypes of the iPhone that circulated within Apple before it was shipped.” There were. It took them years and untold expenditures to develop the iPhone.

    You then “ask why the first iPhone was not a much more simple product when it shipped?” Well, because Apple isn’t a startup and could afford to spend a fortune taking the time to iteratively develop the iPhone you ending up seeing on the market. Moreover, the first iPhone for the market was NOT an MDP (even as you loosely define it). It was certainly delightful, but not Minimal.

    If you’re going to argue that an “MDP” strategy is a smart one for consumer apps, SMB apps, etc. that are built by *small companies and individual developers,* you had better keep in mind the fact that they need to get to market quick to survive. And that they don’t have Apple’s resources. And that the things they put on the market will actually be Minimal.

    If you’re going to blankly claim that “some of the most successful products built have not started with a minimal version shipped to customers first.” you had better provide examples OTHER than Apple.

  • Pingback: Too Many Features Will Kill You via @Contactzilla()

  • Michael Warkentin

    Just a small correction to one of your points – when the iPhone launched, there was no “app model”. There were a few built in apps, and that’s it. If you wanted to run any custom apps, they were going to have to be web apps.

    The App Store came a year later:

  • Ed

    With all respect, the article makes me feel reading about MVP as it would be some kind of junk, and to me it’s not.

    I think I understood the objective of the article and I perfectly agree. But I think we don’t need to create a another term like MDP. Just to share my view,I always thought that MVP was a viable and good product, I never associate it with low quality. MVP to me is just a product with reduced scope of features, but high quality.

  • Shawn G. Chittle

    You are 100% correct. Jobs did not approve 3rd party apps at first and was talked into much, much later.

  • franzsee

    The MVP is about testing your business model, not building a product that is just good enough. By testing your business model, it may mean your customer relationship, your distribution channel, your key partners. Don’t you just love how the name “Minimum Viable Product” is so misleading? :) If you try to understand it using the context clues on its name, you’d definitely get it misunderstand it :)

    But regarding your MDP. Makes sense. But it sounds a lot like MMF (Minimum Marketable Feature – from Lean Software Development), instead that the focus is more on the UX than marketability/selling.

  • Vesa M

    I never thought delightfulness or UX would not be part of MVP.

  • Ryan Kulp

    Great post.

    I wrote another spinoff of the ‘MVP,’ except called mine “Minimum Viable Knowledge” to reflect on the concepts of domain expertise, and how much is needed to build something disruptive / that matters.

    Check out mine here:

  • ricklamers

    Brilliant blog post, I really believe that creating a strong product/service is vital to getting traction. MVP and Agile have its purpose for avoiding the creation of useless features or even worse, a useless product.

    But redefining MVP to MDP seems to make perfect sense. If you ship a MVP that doesn’t delight or gets user’s attention you won’t get to the product or service that will form the core of your company.