Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
Ben Nadel at cf.Objective() 2010 (Minneapolis, MN) with: Seth Bienek
Ben Nadel at cf.Objective() 2010 (Minneapolis, MN) with: Seth Bienek@sethbienek )

Don't Let The Minimum Lovable Product (MLP) Become The Enemy Of The Good

By Ben Nadel on

As someone who has spent more than a decade living and breathing a "design first" product development workflow, the original concept of the "Minimum Lovable Product" was such a breath of fresh air. In my mind, the Minimum Lovable Product - or MLP - was nothing more than an acknowledgment that design was important! That a product wasn't just a collection of features but, rather, an experience that could thrill and delight the user. Over time, however, I've seen design teams begin to conflate the concepts of "lovable" and "perfect." This confusion doesn't create better products - it merely prevents new features from being shipped.


 
 
 

 
Baking  
 
 
 

Baking "lovability" into a product isn't a "step" - it's not a moment in the product design life-cycle. Lovability is a mindset. It's a company culture. It's a unifying thread that's woven into all aspects of the product, from its design to its software and platform architectures and down through its support system. Lovability is a byproduct of love, not of features.

In fact, users probably won't even like the features you release. At least, not at first. And that's kind of the point: features get better the more they get used because that's when you can finally iterate. It's only after a feature is put in front of a user that you can get true feedback about what's working and what's not.

If you believe that a given feature is what makes or breaks a Minimum Lovable Product (MLP), then I believe you're applying love at the wrong layer. Love is not the size of the aggregate - it's the quality of the components. Love should be imbued in all of the features.

To paraphrase Michael Scott, who was, himself, quoting Wayne Gretzky, "Users won't love 100% of the features you never release." Release small features. Release them often. Release them with love. Then iterate.



Looking For A New Job?

Ooops, there are no jobs. Post one now for only $29 and own this real estate!

100% of job board revenue is donated to Kiva. Loans that change livesFind out more »

Reader Comments

@Glen,

I think the thing that gets me most about the MLP is that it's become a "card" that designers can play to prevent features from being released in anything less than the originally formulated idea.

ME: I'd like to release this part of the feature, then release this other part later.

DESIGNER: Sorry, the product has to be lovable.

ME: But, I think this feature would add value now. Let's have people start using it while we finish the rest of the code.

DESIGNER: Sorry, the product has to be lovable.

ME: (Channeling my inner Inigo Montoya): You keep using this word -- I do notta think it means what you think it means.

Reply to this Comment

Ask them to define lovable in measurable terms. Also, ask them to read the original blog posts on the subject. Lastly read Emotional Design.

In other words, try to make lovable a concrete thing. Be the subject matter expert in lovability. Teach them.

And just for good measure, try to debate their side of the issue with someone. There is downside in releasing features that are half baked. Practice empathy. Take the high road.

Reply to this Comment

Sorry, one more. They are forgetting the word Minimum. It's a crucial word. It means the LEAST amount of functionality that is still something users will love. Tiny features can be loved. Tell them, "this small feature is the minimum scope, let's make that feature lovable and ship it."

Reply to this Comment

@Glen,

That is a great point, remembering the "minimum" part of the MLP! I think that definitely goes out the window a lot of the time.

Unfortunately, at this time, "Take the high road" for me is generally just "backing down". This is actually something I was just talking about with our "Tsar of Happiness" at work:

I wish I had more confidence in my opinions. I tend to back down as soon as other engineers disagree with my viewpoint. Perhaps I can work around this behavior by asking more questions about the disagreement.

... it's a "known bug" that I'm working through :D

Reply to this Comment

@Glen,

Another way of saying all of this is "Pick your battles". However, there is no pie chart in that phrase.

Ha ha, that's great. But, the post is well taken. In my mind, I know what that 10% is -- I just need to not back down so often.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
NEW: Some basic markdown formatting is now supported: bold, italic, blockquotes, lists, fenced code-blocks. Read more about markdown syntax »
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.