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".
Scale, tooling, materials, what happens when things go wrong, etc are all different. Product people never seem to appreciate that bit.
2. Explain why it doesn't work.
3. Coin your own acronym to describe how most people actually understand the original term.
I call this the R3 pattern, for Restrict, Reject, Rename. :)
2. Liven it up with feelgood make-up
3. Overhype it to death
4. Glory
FLOG pattern FTW.
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?
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.
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.
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.
The most negative result from mvp isn’t hate - it’s indifference.
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
