Alternative to the MVP: Simple, Lovable and Complete | Hacker News Reader

Alternative to the MVP: Simple, Lovable and Complete

blog.asmartbear.com

78 pointsrmason18 comments

Oddly enough, this has always been my understanding of the word MVP - simple but complete. I'd be surprised if there good engineers who make the mistake mentioned in the article.

Yeah, for me "viable" has always meant complete, worth selling as a product.

"MVPs are too M and almost never V"

yes, viable is the hard part. just like "loveable" will be the hard part of SLC.

next month's article. "SLCs make me SC(sick)"

Admittedly I've never worked at a startup. I've always taken MVPs as a releasable proof of concept. Reminiscent of the "tracer bullets" discussed int The Pragmatic Programmer.

If you're trying to prove a market, yeah, an MVP would look like the skateboard -> car image. If you're trying to prove a technology, it would look like an internal combustion engine strapped to some tires. If it was a passenger vehicle, it would look like a carriage with some engineers pulling it with ropes like horses. The "Not like this" looks like a poor implementation of "waterfall."

Agreed entirely. If the customer isn't happy then either you set your bar for "minimum" too low, or you've proven that your product isn't viable.

It's not that customers don't like MVPs, it's that customers don't like shitty unfinished things.

Big corps have departments doing MVPs these days, no need to be a startup.

Unfortunately, some (big co) use it as a buzz word and rarely go back to iterate on the MVP. Just make it as inexpensive as possible, it feels like a cheap version of watergile.

We were often badly abusing all three terms: minimum, viable, and product. Probably that last one most egregiously.

So I put a moratorium on that terminology both internally and in our external communication. Now we use "Minimum Viable Experiment". Because it implies that we've established a stable hypothesis, that we've considered what a test and validation plan should look like, established completion criteria, and nobody starts prematurely projecting expectations of sales onto an experiment.

The product discovery and development processes are entirely outside that experimentation process. Though one clearly feeds it and the other is fed by it.

This has been very successful in keeping expectations aligned and in check consistently internally, externally, and with our investors/board. Even just making the change in language forced a conversation to explain it and that by itself was worth the small shift in terms.

This just seems like nothing but fluff:

Simple = Minimum

Complete = Product

Lovable = Viable

People (including me!) just suck at knowing what an MVP is, and tend to release 2-3 connected MVPs at once.

Yes but its hard to plug your company by saying: "we do X like everyone else, but trust me: we have this" but easy with: "we don't do X, we do X' because these bad things happen with X".

Particularly if X, or things that have been labeled X have been cause for concern.

Such trival considerations as X' == X don't always get the attention they deserve, as seeing this requires an amount of understanding of the problem and not just the fustrations of using X.

*insert generic engineer gripe at how common it is that the people making the purchasing decisions - the target of marketing - don't have said amount of insight.

tl;dr: yup pure fluff

> But no customer wants to use an unfinished product that the creators are embarrassed by. Customers want great products they can use now.

The reason MVPs are so valuable is the word "viable". If your customers truly demand "great products they can use now", then that's what viable means for that customer group.

> Startups are encouraged by the great Reid Hoffman to “launch early enough that you’re embarrassed by your v1.0 release.” But no customer wants to use an unfinished product that the creators are embarrassed by.

The article is a response to famous startup advice, continuing the conversation of just how "minimal" should be an MVP.

I like the lovable (or as someone said in the comments, compelling) part.

Thinking of customer development, would it still be risky to build an SLC and then validate your hypothesis? Presumably, since you've focused on both lovability and complete-ness, it won't just be a figment of your imagination?

It's semantics and all about how you interpret MVP.

My MVPs typically are pretty much complete applications. I can't see it being any less whilst still being new and innovative.

The Google Docs example is not a good one because Google had millions of users already at the time.

In other words bake not a subset of a cake, but a smaller cake.

I heard a variation of this once: an MVP for a car is a skateboard, not 4 wheels and an undercarriage.

Found where I saw the cake analogy specifically: https://blog.intercom.com/start-with-a-cupcake/

Reply on news.ycombinator.com