
Customers hate MVPs – Make it simple, loveable, and complete instead (2017) - notoriousarun
https://blog.asmartbear.com/slc.html
======
danShumway
Minus the buzzwords, here's what this article is saying: when you build an
MVP, you should bias towards cutting features rather than cutting polish or
introducing bugs. If your MVP is filled with bugs, it isn't actually viable.
You should also focus on making an MVP that people actually want. If it isn't
solving a real problem ("loveable"), it's not actually a product.

In other words, increase the polish of your initial releases by making them
smaller and including fewer features. That's valuable advice.

But if I can rant for just a minute:

Do you need a completely brand new concept or paradigm or acronym to say that?
No, you don't. This is mostly just playing semantic games and allowing WP
Engine to subtly imply that they're better at building polished products than
other companies.

How do you make something simple? You make it do less stuff. That's what
"minimal" means. What does "loveable" mean? It means you're solving an actual
problem -- you have a real Product. How do you build an SLC? You radically cut
down on the number of features you plan to ship in an initial product, to the
point where you have time to polish them in your initial release. That sounds
a lot like an MVP to me.

If WP Engine just put up an article saying, "our software is always very
polished and very usable, even in the first release", nobody would care. The
way to make people care is to pretend that you've found a completely new
paradigm for building software, when all you really mean is, "we're quite good
at building MVPs that people like."

The article isn't talking about new concepts, it's just debating what other
people intend when they say individual words, and I couldn't care less. It's
like saying, "we don't focus on making our product 'fun', we focus on making
it 'delightful'." Okay, but what does that _mean_ beyond the fact that a
business manager somewhere thought it tracked better with potential buyers?

~~~
oblib
What I got from Startup School was that an MVP didn't have to do anything at
all. It just had to demonstrate what it "will" do. It's basically a "mockup".

~~~
danShumway
Huh, that's really interesting.

I don't have anything against mockups, but that's almost the opposite of what
I and engineers I know think of when we say MVP. The point of an MVP as we use
it is to not plan in excessive detail about what your final feature-set will
be, because you don't know what customers will and won't find valuable until
you have a product in their hands. Get the smallest, most specific version of
a useful product released, and then after that you can figure out what future
iterations should do.

How are you going to release an MVP to customers that doesn't actually do
anything? Why would anyone download or use it?

~~~
loopz
Too much software mindset. You can build a no-code solution, see how potential
users interact with it, and learn from that. You can gage interest just by
presenting something to a focus group in a somewhat interactive way. MVP could
even just be a poll. No need for a "product" or even a demo.

If you can build a prototype fast and deliver fast, that could be valuable,
but is often waay before evaluating what to build in the first place. There
are success stories building something and iterating on that. If you yourself
is multi-talented, have the time, clout and love your software, there might be
some odds others might like/need it too. The latter is associated with most
failures though.

So be a business, not a software delivery function.

~~~
danShumway
Sure, you don't need to code anything. You can build a no-code solution, see
how potential users interact with it, and learn from that. But your no-code
solution still needs to be a minimal feature set that people can actually use.

If I'm building an MVP for a restaurant, maybe there's no code at all in that
system. Maybe I'm manually taking everyone's orders and serving at most one or
two dishes on a street corner. But I'm not just showing people pictures of
food.

Your no-code solution still needs to be a solution, it can't just be a promise
that there will be a solution at some point in the future. An MVP doesn't mean
code, it means: Build the smallest possible product (whether that involves
code or not) that actually solves someone's problems in the real world, and
then put that product in their hands so you can see what they do with it.

A poll is not a product. No customer is going to pay you so that they can take
a poll.

~~~
loopz
You may not generate much income with initial MVP, or whatever you want to
call it. The point is to learn while minimizing costs, risks and time to
market. To expect greatness without work, is folly..

Your example with the restaurant is a perfect example: Have someone execute
the MVP manually. Map routines that works great, optimize and document
outcomes. This becomes spec for initial automations.

The alternative could be someone in a corner office applying systems thinking
and predicting everything required in the system. This tend to overcomplicate
system designs and make them less amenable to adapt over time.

------
dasil003
All of this could be said without trying to coin a new acronym. MVP already
covers these angles, and it feels like a bit of a strawman to claim it
doesn't. The hard part and simultaneously whole point of building an MVP is to
figure out the proper scope. This will vary a lot from product to product and
in different markets, and there's no magic formula. I don't see how adding new
abstract principles helps. Should it be simple, lovable and complete? Well
duh.

~~~
kasey_junk
The emphasis on complete is a new take. The entire idea of an MVP encapsulates
the idea that it will change into something in the future.

Just changing the mental goal to something that can live on its own with no
further development is an important difference. Does it need a new acronym? I
don’t know but I never liked MVP anyway.

~~~
mikeg8
The reason shooting for completeness is not ideal is because it’s usually a
waste of time. Very rarely can founders guess the compete solution to their
customers problem out of the gate. It’s the mismatch between what the company
_imagines_ the complete solution should look like versus integrating customer
feedback to make “complete” solution more people will pay for.

------
torpfactory
The big problem with MVP is that it is now simply one more corporate buzzword.
Many using the term may have heard the 30-second description from a colleague
and now repeat it freely. Like a game of telephone, what was said and what was
heard about MVP keep changing. As such, it has lost most of its meaning and
has no firm definition. It's an easy target for a piece like this, given the
circumstances.

At least in my organization it had no useful definition. Usually the term MVP
would be thrown around by management as reasoning for any number of decisions.
Taking too long to understand a core technology limitation - my lucky MVP ball
says just get it sort-of working and ship it. Regressing on performance to
meet an arbitrary timeline - just make it MVP (in our organization this meant
ship on time, no matter the content). Reducing cost by shipping completely
untested designs - that's what MVP is. Not that any of these examples couldn't
or shouldn't be viewed with the MVP rubric, but it didn't seem to mean
anything in particular.

------
glofish
I don't agree with the content. The whole premise is to mischaracterize what
an MVP is supposed to be.

The figure they have there where they compare a half car with no wheels (MVP)
to the scooter (SLC) is quite telling.

That half car would never be considered a Minimally Viable Product, a half car
with no wheels does not work at all - how is that viable? The scooter would be
an MVP.

~~~
danShumway
The Spotify team is explicitly saying in that chart, "example 1 is not an MVP,
example 2 is."

And then WP Engine is turning around and saying, "see, example 1 shows why
MVPs don't work. Instead you should build example 2 which is a totally
different concept we invented."

I don't know why, but that really rubs me the wrong way. How does someone look
at a two-diagram infographic and take away the exact opposite lesson that it's
trying to teach?

------
oblib
I have to agree with the author. The MVP concept was new to me when I attended
Startup School a couple years ago and while I understood what it gets at (not
spending too much time or money on a concept that no one may want) it feels
too much like selling a "promise" of what something will be, and it assumes
that promise can be fulfilled.

To me, an MVP felt like showing someone a battery powered skateboard while
telling them what you're really working on is an electric car. You may get
investors, and that's great, but you may also spend years finding out you
can't scale the tech to build the car.

~~~
stronglikedan
It's more like the MVP is a basic electric car. You can sit in it, start it,
and drive it. However, it doesn't have a radio or sunroof, and maybe not even
a trunk or passenger seat.

I'm not sure the author understands what an MVP is. I parse the title as _I
hate MVPs, because I hate what I don 't understand_.

------
mabbo
Interpretation of language is the problem here.

What is "viable"? What is "minimal"? The author's complaints are that
customers are upset with the MVP. Well, that's because it was so minimal that
the customers don't see it as viable. There's not enough viability to make up
for the minimalism. Using the product is not a good deal for the customer.

So what's the answer the author provides? Use different language that can be
misinterpreted. Here's what will happen with SLCs:

"Oh, that doesn't have <feature X that 1% of users want, but VP likes>, so
it's not COMPLETE yet, so it's not an SLC".

"We don't need to add <X> because that's not SIMPLE, so it's not an SLC, just
ship without <critical feature that 90% of users need>".

"You know, it's good, but I just don't _love_ it yet. Can you just give it
some more work so that it's an SLC?"

I've seen it happen. "Minimum LOVABLE product" made it's rounds at my company
once. Yes, they called them "MLPs" having no idea about My Little Pony or the
various communities who care deeply about such things. It did not bring us
joy.

The true answer lies not in changing the words but in deeply defining what you
mean and getting everyone to agree on them. It means working closely with your
customer and asking _them_ if you're ready to launch with this minimal set of
features (for now). It means earning trust and quickly iterating based on
feedback.

Buzzwords gonna buzz. Ignore them. Just sit down with your customer and solve
their problems.

------
mywittyname
Remember how Telsa started by building skateboards before moving to scooters,
bikes, then cars? No? Oh that's right, they started with cars, but outsourced
the design and production of components that were not their core competency,
then slowly replaced those outsourced designs until they had something
entirely their own.

What product is complete when launched? I can't recall anything. Most of the
products I know and love got to that point through a series of small,
incremental, improvements over time. And this is exactly the foundation the
MVP paradigm seeks to lay out: get something out the door that's useful, and
get feedback from customers to make those incremental improvements.

~~~
gofreddygo
> they [...] outsourced the design and production of components that were not
> their core competency, then slowly replaced those outsourced designs until
> they had something entirely their own.

This is interesting. Any references to read more on this ?

~~~
mywittyname
I'm referring to the original Roadster being built on a heavily modified Lotus
chassis while the Model S was ground up design. The fact that older Roasters
can get upgrades from the Model S suggests a good deal of component sharing
for the drive trains.

I'm not sure if anyone has written anything extensive on it.

------
jameslk
The premise of this article is based solely on this statement:

> The problem is that customers hate MVPs.

But I don't see much in the article to support this claim.

------
commandlinefan
So... "Don't try to be realistic about what can reasonably be accomplished,
instead do everything completely right the first time". Well, ok, thanks for
the advice, I guess.

~~~
vikramkr
I love that they complain that MVP is not a good approach and that SLC is
better and clearer, but "simple" and "complete" can be antagonistic forces and
create the same amount of ambiguity as the interaction between "minimum" and
"viable." I imagine you are looking at complete and read it as saying
everything must be done right the first time, while the author likely would
respond with "no you are missing the point it should also be simple." But I
might agree with your interpretation, as would a lot of other people, meaning
its ambiguous and potentially less meaningful.

At least the ambiguity in MVP is less, it's the minimal product that is
viable, which presumably does have an empirical, if perhaps unknowable,
answer. It's a clear target. What is simple and complete though? I dont think
theres a clear target there.

------
dkersten
If your customers hate MVP’s then you got the V wrong. The whole point is it’s
the minimal things that’s Viable and how much that is depends on the product
and market. For some products, the minimal thing that’s viable really is
minimal, for others it’s rather complete. IMHO the point of MVP’s is to do the
least work necessary to make the customer happy with the product (ie not was
to big time on unnecessary or nice to have things that can come later), not to
build a minimal thing.

------
Traster
I hate these corporate brand management exercises masquerading as real
technical insight. We get it, it's important to your company to be viewed as a
thought leader in order to attract talent and customers. The way you do that
is by _doing_ things, not half-arsing a blog post. If you have nothing
meaningful to say, don't say it.

------
troelsSteegin
What is the difference between "viable" and "complete"? Complete, as in
"Simple, Lovable, Complete", is about your customer's ability to derive net
utility from using your product for their job to be done. Viable, in the MVP
context, I interpret as signalling a credible offering in a market. The
audience for viable is investors in your business, or customers willing to
invest in a relationship with your business, in the expectation that your
product will get to a point later of being distinctively useful.

Viable is promising, complete is useful today. The question is which approach
will best fund your company to the point of operational self sufficiency. As
an engineeer, I would far rather make SLC products. However, if I am racing
for mindshare in a market or with investors, I have to think MVP.

SLC is harder to acheive. As Pascal sort of said, "If I had more time, I would
have written an SLC".

~~~
9wzYQbTYsAIc
> What is the difference between "viable" and "complete"?

That’s where a lot of people get tripped up: development may have one idea
about what is viable whereas the business team has a completely different
idea.

~~~
loopz
...and customers have a third valid opinion on the same.

~~~
9wzYQbTYsAIc
Which should get subsumed into that business team as an accurate VOC.

------
goatherders
I worked at WPE years ago when the core product was still being improved upon
and enhanced and new ideas were still being shipped. I assure anyone reading
that the company shipped plenty of MVPs that turned out to not be Minimum, not
be viable and failed as products. That's not to be a criticism - I love that
the company tried new things and the product team wasnt afraid to put new tech
in the hands of customers. But there was no new paradigm or standard then as
this article from 2017 (which is right around when I left) suggests.

The author is one of the smarter people I've been around, in the tech world or
any other. And I've enjoyed his writing over the years. But I tend to agree
that this piece doesnt really make a lot of sense aside from ascribing a new
acronym to an established idea.

------
santoshalper
The author spends an entire article demonstrating that he or she does not
understand what an MVP is, then proceeding to tell us about a new invention
that is, in fact, an MVP.

Newsflash - an MVP is not a piece of shit. It's the simplest version of the
product that solves the problem.

~~~
richardjennings
It seems "Simple, Lovable and Complete" is the authors context specific
meaning of the Viable in MVP

~~~
pdubs1
It also seems really dumb, to me, for incorporating "Love" into a
business/engineering product/project stage-of-development naming convention.

Any good business person or engineer understands that objective, unbiased, un-
emotionally attached decisions and validations are antithetical to subjective,
biased emotions such as "love".

------
Adrig
I'm not going to rewrite comments that have been presented in this thread (I
usually use the name Main Delightful Product), but I'll make an argument for
ugly MVPs :

All products and features don't have to bring joy to users. Sometimes they
just are sick of their problem. The fulfillment of their pain don't translate
into appreciation of the product. Examples could be safety features (security
alarm, protective gear,..) or reliability enhancer (monitoring software,...)

Doing an ugly MVP will give you plenty of proofs of concept, and will provide
the majority of what users want : the solution to their pain point. Taking the
extra time to make it lovable will only impact marginally the perception of
value from your users

------
Ididntdothis
It seems when things like MVP, Agile or OOP are invented they are useful
observations. But as soon as they become popular they get distorted to the
point they don’t make sense anymore or are even damaging. At this point
whenever I read something about MVP it seems it’s mainly discussing semantics
and ideology. Time for a new buzzword cycle.

------
waylandsmithers
In my consulting experience MVP doesn't have much to do with whether the least
amount of work to make the thing possible is being done, but has mostly been
used as a negotiating tactic when fighting for scope-- "We'll save that
feature for V1, but we're going to focus on these features for MVP"

------
fenwick67
I don't want to move to Utah, thanks.

------
pdubs1
This article smells of a naive, inexperienced author.

"I hate the accepted industry abbreviation. Use my abbreviation! It's better!
Woo I'm so smart and and my opinion is so important."

How about... I hate SLC. Use MVP instead. (Or POC - Proof Of Concept)

"simple loveable complete" Please. Just... please.

This author sounds like another non-technical person trying to insert
themselves into an area (technology) where they lack experience.

Simple Entryism.

First they enter a domain, then they want to start making changes, whether
they are merited or not, and whether the person is knowledgeable/experienced
or not.

So sick of it.

1\. Stop trying to tell people what to do, sweetheart.

2\. Stop telling me what my customers want-- You don't know me, nor do you
know my customers.

3\. Stop acting as if you represent anything other than your own inexperienced
opinion.

"Love" does not belong in an engineer or business person's vocabulary, when it
comes to validating value.

"Love" is subjective and BIASED.

Good decisions are objective, data-oriented, lack bias, and lack emotional
attachment.

Please, keep gullible lovey-dovey hippies & "entryists" out of technology.

~~~
arunaugustine
The author is Jason who is the founder and CTO of WP-Engine which started in
2010. He sold two companies before that.

From the Author bio: [https://blog.asmartbear.com/jason-
cohen](https://blog.asmartbear.com/jason-cohen)

