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.
“Made with love” is just cringe though, and after having become pervasive also can’t be taken at face value anymore. That aside, if a product is made with love, it will show by itself. No need to declare it in case someone wouldn’t notice.
You can be silly and original. Being another team of young engineers that really love coffee and call themselves code artisans is anything but original.
It's like the widespread humanistic art style that 99% companies have adopted in the 2010s to show they are not another faceless corporation, but instead are a friendly business where you matter.
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.
MVP lauches and the PM is at my desk. Hey we need these 5 features that you told me I would want but I swore would never be in the product.
MVP launches and the PM is at my desk. Hey this thing that I would have found if I took a paper prototype out on the street and showed it to random people would have been apparent ... well now we need that.
Hell I have told PM's that their print on demand product needed a dirty words filter. They told me I was wrong. Guess what the first feature was post launch in a panic. It's not like I haven't said "If you're launching in Germany you need to take checks" and then had someone come back when the sales numbers were dismal till they started taking checks. (And dear god someone tell me that Germany is past this).
Candidly most MVP's miss the minimum and viable because the people who are defining those things are making guesses with out doing a lot of research. Ethnography, Usability, all these things are much cheaper than development, and yet we dont do them...
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]
For successful companies the rules are different. They can’t afford to push out crap to see what sticks because their customers will get pissed. If you have no customers, you need to iterate much more quickly until you find something that can viably get you some customers. Or you can do an SLC as a startup if you are VERY confident you are doing something people will love. That confidence can pay off, but playing the odds it usually doesn’t.
If I was going to re-brand a great idea with a legitimate tweak in emphasis it would be “dogfooding”: the denotational semantics are almost right, but the term combines the wrong emphasis (force yourself to use something intended for others, almost never a recipe for great work) with a mental picture that is less than appetizing.
pg has written about this so extensively and effectively that it would be a waste of any readers time for me to footnote: go read all his essays with an emphasis on the earliest ones if you haven’t: they’re great.
I’m not the writer someone like pg is by a long way and so I’m both making the argument less well and don’t have a great alternative proposal, but I bet someone on HN has a good name for this.
Instead I’ll share a memorable quote from a world-famous chef that stayed with me: Thomas Keller has two restaurants in Northern California: The French Laundry and Bouchon. He’s quoted as saying that “The French Laundry is where I create meals I like to make, Bouchon is where I make meals I like to eat.”
What’s an alternative to “dogfooding” that describes the process of building some simple, lovable, and complete by building something that you yourself prefer to any existing substitute or alternative?
The article seems to be attacking MVPs which are not "viable". In the included graph of the development of a car I have seen version which show exactly the preferred path of development skateboard --> scooter --> bike ... as an example of an MVP! Here the author uses a new initialism "SLC" to describe this preferred path of development and the only reason seems to be some experience dealing with non-viable MVPs.
This is the core problem with MVP in many cases.... engineers end up having to put an engine, seats and doors on a skateboard rather than clean slate at every step.
Forget the factory. A skateboard, a scooter and a car are not similar enough for this to make much sense.
Tesla pulled off an MVP, the Roadster, that actually made sense: they built a drivetrain (which was their actual innovation) and sold inside someone else’s car. It was minimal: they focused on what would distinguish them (it was a fast EV!) but didn’t have much else going on; it was viable (one could drive it and have fun); and it was a product (one could actually buy it).
But it was a car, not a skateboard or a scooter. It demonstrated that they could build an electric car that was fun to drive and had respectable range. An electric scooter wouldn’t have done that, and might not have had much to distinguish Tesla from, say, Mission Motors. Scooters have been able to go large distances with small amounts of fuel for a long time.
I’m working on doing a total replacement of an existing system that’s been in use for a decade.
Right now I’m focusing on the logic and internals and have no UI work done.
I’ll release a MVP without the UI because the users are very adapt at backend query and would much rather get off the current system than delay waiting for me to do a total front end.
That’s our MVP and I’ve total buyin from the business
Nothing wrong with MVP when everyone is aware of what that means.
Because love vs hate is completely wrong way to view the product - unless it’s some pointless fluff. Users can be compelled to use a product because it solves a problem for them, but it may have features and bugs that cause them to hate it. Which is a great signal to invest and fix those bugs.
The most negative result from mvp isn’t hate - it’s indifference.
minimum viable product, it’s right there in the name. If you customers hate it, then it’s not really viable, is it? And if they do, but they use it anyway, then mission accomplished… I’m really not down with this article.
lol just reinventing the wheel imo — MVP really just means “minimum product people are willing to pay for (and sometimes just use)”
It’s correct to say 98% of your target market won’t want to use that product. That said, the 2% that do will help iterate and refine for the remaining folks.
To get the initial folks identify the problem and folks willing to work with you. Sure, that’s about it.
“Simple, lovable, complete” sounds nice, but that sounds like features. Good luck building a car, word doc, space ship, new drug, etc with that lol those are products, not independent micro-services
