Other folks have already made the correct point that the author has just come up with a new initialism for what MVP actually means, but I'd like to add that describing your product as "lovable" is gross manipulative arrogant marketing speak. With _very_ rare (and probably unhealthy) exceptions (Apple springs to mind), customers don't love products - they just use them, or at best appreciate them.
"Lovable" derives from the hipster-developer trend that started around 2010, where endless web, CSS, or app frameworks were tagged "Made with love in <cityname>", or "Made with love by <author>".
So silly. Like, was the gcc toolchain made with cold indifference? Were linux and git made with Scandinavian longing? Was emacs made with a certain sense of ennui?
> Were Linux and git made with Scandinavian longing?
He’ll never tell you. He’ll just stare sullenly at you on a crisp November evening through the frost-coated glass of your remote log cabin until slowly he’ll raise one hand bearing his middle finger, without breaking eye contact or changing his expression.
“Pass that along to Jensen Huang” he’ll whisper. Then with a surge of the creeping blizzard outside your window, he’ll be gone forever.
Lots of folks build software for the heck of it and I'm in full support of any poetic license any author wants to take with their work product. We could all do with a little more silliness. If you were involved with the Ruby community back cica 2005 - 2012, you may remember how beloved _why was and their attitudes around programming and creativity.
I think I'll need to start saying I write code with American cynicism or Californian gusto.
I've been thinking about this a lot while building my MVP. Initially I wanted to make a product people can love, then I remembered someone saying that people use software as if it were a toilet: you use it and forget about it, it's not there to be admired. No one cares that "it's made by a passionate team of dreamers."
So my goal is to create an efficient tool that gets out of one's way, rather than a hipstery "software that you want to cuddle with" or other nonsense. I am designing a toilet. I couldn't even tell you what my actual toilet looks like, but it gets the job done.
Depends on the weight of the word love. My sense that love can be expressed to products because they are delightful in use. I’ve said it many times that I love Figma, or I love using Google sheet. Is that the same love that I have for my daughter — hell no. But the word does convey well in the regular vernacular what it means for me to use those products. I’m not opposed to using love in this way the author means which is they like it enough to return, probably be advocates for the service, refer people, and probably put down some money to use it.
My experience is that the expectation of "lovable" tends make the development process far more toxic. Whatever your definition, "love" is a relationship that takes investment from both sides. Customers will interact with dozens of different applications on a daily/weekly/monthly basis. Having a relationship with any or all of them is a significant burden to the customer. Think about the appliances in your home. Do you love them? Do you even want to?
"Lovable" is also toxic to product developers. Any usage that doesn't build a relationship starts to look like a failure. If you're making tax software, people aren't going to love it no matter what you do. Even if you manage to build that "loving" relationship with the customer, do you really want to invest that deeply maintaining it with every customer (including the demanding ones)? Remember that if they love your software, they're now invested in you not changing it and they'll expect the norms of that relationship in all interactions with you. If you fail to meet those expectations, some of them will go out of their way to talk about it. If you do meet those expectations, their "love" may actually scare others away from using it to avoid being associated with them. Think of the stereotypes about people who like Vim, Rust, or Excel. Maybe that's what you want, but it shouldn't be a universal development goal.
If the people building the product view building and using it as a chore, it’s going to show.
So I took “love” as their brand of Amazonian “customer obsession”.
There needs to be someone (often a founder, head of product, etc) who is the visionary for how the product can be awesome for customers. And hopefully that leader is able to infuse the entire product development experience with that energy.
MVP: My demo ended up in production and now were trying to scale SQLight to 1000s of concurrent users help!
If you want to build an MVP im all for it. It is 100% throw away. Don't try to "add a feature" don't try to "expand" ... You cut corners in design and spec Im gonna cut them in engineering. Let's all take the lessons we learned and build something good after.
I do think you can build products and services that people will capital-L Love, even forgiving some warts too, but the bar for that is very high. I’m very skeptical of tech businesses not led by engineers for exactly this reason (the incentives don’t align with a level of quality people will care deeply about).
I just finished an MVP for a free tool to help delegated tasks get done. I was wondering if I did it all wrong, but like you say, I would have a very hard time describing a management tool like Upfollow.app as “lovable”—I’d be happy with appreciation.
I read it the other way. It's not that customers "love" it, it's that they don't hate it.
In other words it's "love able" as distinct from "loved".
But yo pick on the L is to miss the point. M implies "not there yet" whereas C indicates "its all you need.".
I have a small product which does 1 job really well. Every 5 years or so I give it a visual overhaul. Every couple years someone suggests a feature which would make it better, but equally lead it into a much more complex space.
Its Simple, Complete, and has been used by some folks for over 20 years. To make it "better" would destroy what makes it "Lovable".
Every day here on HN we get announcements of new things. Most are starting out and of course there are lots of suggestions, which the author usually agrees with. Clearly they're showing M. Usually iys not really V for one or more reasons.
So to me at least MVP and SLC are very different concepts. Kudos to developers who strive for simplicity, completeness and elegance.
“Delight our users” (or customers) - similar bullshit. The only time I was “delighted” with software was when I played a new, very engaging video game. That is, something entirely for entertainment. Nothing else.
The classic “big reveal” style of communication - hiding the important thing until half way through. Don’t bury the lede! It confuses and distracts the reader who is looking for how to frame and read everything else.
“SLC = simple, lovable, complete. Let me tell you why this is better than MVP.”
It was so annoying that I just skimmed through until I found the bolded terms, realized I disagree with the hot take and closed the tab without further reading. Maybe I'm wrong to do so and missed out on some invaluable piece of advice, but if the message is this boring, confusing and wasteful of the reader's time, maybe that's not on me
I'm actually going to disagree with this post because it's a tangential problem to what MVPs are supposed to be for. If you're operating on a shoestring budget in a competitive environment (i.e. most pre-money startups), you don't know if your idea is worth making "slick", so you build the minimum usable feature set that will get you feedback from actual customers. I've seen far too many developers (and hardware engineers) go down a path similar to what the author is proposing, only to find out that they spent a bunch of time making a simple, complete thing that no one actually wanted.
Start with MVP, see if it resonates, then you can spend the time to go for SLC.
> “MVPs are too M and rarely V. Customers see that, and hate it. It might be great for the product team, but it’s bad for customers. And ultimately, what’s bad for customers is bad for the company.”
I think the author agrees with you in part— MVP’s are objectively better for product teams to get feedback faster.
I agree with you that the idea of an MVP can’t be dismissed in all scenarios. Get it “viable” enough that it feels complete. Get feedback and move from there.
If you try to build "Simple, Lovable, Complete" then you're likely taking too long to ship.
Success with MVP looks like this: "Frank in accounting says he hates it, and thinks it's ugly, but says he'll use it because it saves him ten minutes every day. And he wants to talk with you today about why it sucks so much right now."
Exactly! You don’t want love, you want users to be compelled to use the product for whatever reason. I don’t love a hammer but it’s a super compelling option when I have some nails…
I've seen that exact argument made and put into practice, though. i.e. the unironically promoted approach of "add a button for a feature you think users will want, and then show an error message when they click it after collecting metrics"
Some people have a really delusional definition of "viable"
This completely fails to address the significance of the word "viable" in MVP - it's only meaningful if we define what it's viable _for_.
In a startup it may be "viable to test a hypothesis", in a running business it may be "viable to implement a new workflow". In either case the logic of the MVP approach holds - do the least you need to do to learn what to do next.
One could argue that "simple" in their SLC is analogous to "minimal", and "lovable" to "viable".
A 2017 is missing in the title (guess it matters as this was a total different point in the agile hype cycle) Wonder why this recently pops up recently[1]
Readit News
So silly. Like, was the gcc toolchain made with cold indifference? Were linux and git made with Scandinavian longing? Was emacs made with a certain sense of ennui?
He’ll never tell you. He’ll just stare sullenly at you on a crisp November evening through the frost-coated glass of your remote log cabin until slowly he’ll raise one hand bearing his middle finger, without breaking eye contact or changing his expression.
“Pass that along to Jensen Huang” he’ll whisper. Then with a surge of the creeping blizzard outside your window, he’ll be gone forever.
I think I'll need to start saying I write code with American cynicism or Californian gusto.
https://www.bloomberg.com/news/articles/2017-10-03/fda-decla...
You're familiar with Richard Stallman, yes? :-)
So my goal is to create an efficient tool that gets out of one's way, rather than a hipstery "software that you want to cuddle with" or other nonsense. I am designing a toilet. I couldn't even tell you what my actual toilet looks like, but it gets the job done.
"Lovable" is also toxic to product developers. Any usage that doesn't build a relationship starts to look like a failure. If you're making tax software, people aren't going to love it no matter what you do. Even if you manage to build that "loving" relationship with the customer, do you really want to invest that deeply maintaining it with every customer (including the demanding ones)? Remember that if they love your software, they're now invested in you not changing it and they'll expect the norms of that relationship in all interactions with you. If you fail to meet those expectations, some of them will go out of their way to talk about it. If you do meet those expectations, their "love" may actually scare others away from using it to avoid being associated with them. Think of the stereotypes about people who like Vim, Rust, or Excel. Maybe that's what you want, but it shouldn't be a universal development goal.
If the people building the product view building and using it as a chore, it’s going to show.
So I took “love” as their brand of Amazonian “customer obsession”.
There needs to be someone (often a founder, head of product, etc) who is the visionary for how the product can be awesome for customers. And hopefully that leader is able to infuse the entire product development experience with that energy.
If you want to build an MVP im all for it. It is 100% throw away. Don't try to "add a feature" don't try to "expand" ... You cut corners in design and spec Im gonna cut them in engineering. Let's all take the lessons we learned and build something good after.
Minimum viable product still means it's a viable product. If it's 100% throwaway, it wasn't viable.
In other words it's "love able" as distinct from "loved".
But yo pick on the L is to miss the point. M implies "not there yet" whereas C indicates "its all you need.".
I have a small product which does 1 job really well. Every 5 years or so I give it a visual overhaul. Every couple years someone suggests a feature which would make it better, but equally lead it into a much more complex space.
Its Simple, Complete, and has been used by some folks for over 20 years. To make it "better" would destroy what makes it "Lovable".
Every day here on HN we get announcements of new things. Most are starting out and of course there are lots of suggestions, which the author usually agrees with. Clearly they're showing M. Usually iys not really V for one or more reasons.
So to me at least MVP and SLC are very different concepts. Kudos to developers who strive for simplicity, completeness and elegance.
If it's "not there yet", it's not Viable.
“SLC = simple, lovable, complete. Let me tell you why this is better than MVP.”
It ain’t hard, folks.
Every paragraph without a thesis statement loses another significant fraction of readers.
Start with MVP, see if it resonates, then you can spend the time to go for SLC.
I think the author agrees with you in part— MVP’s are objectively better for product teams to get feedback faster.
I agree with you that the idea of an MVP can’t be dismissed in all scenarios. Get it “viable” enough that it feels complete. Get feedback and move from there.
Success with MVP looks like this: "Frank in accounting says he hates it, and thinks it's ugly, but says he'll use it because it saves him ten minutes every day. And he wants to talk with you today about why it sucks so much right now."
The argument an MVP excludes actually meeting customer's requirements is pretty misguided.
Some people have a really delusional definition of "viable"
In a startup it may be "viable to test a hypothesis", in a running business it may be "viable to implement a new workflow". In either case the logic of the MVP approach holds - do the least you need to do to learn what to do next.
One could argue that "simple" in their SLC is analogous to "minimal", and "lovable" to "viable".
[1] https://news.ycombinator.com/item?id=37371502