Build a Minimum Loveable Product | Hacker News Reader

Build a Minimum Loveable Product

preetamnath.com

48 pointsgrwthckrmstr26 comments

Open articleView on HN

I am pretty sure this is copied from a blog post i wrote a long time ago[0].

I know this because he's used the illustrations my brother drew for me by hand...

@author: you've also missed the point of my article and why I think an MLP is worth considering.

0. https://tinytracker.co/blog/minimum-viable-product-vs-minimu...

Seems common nowadays. I saw a thread a few days ago where Nbdev did the same with terms they claimed to coin.

It doesn’t look like this article has outright copied yours though... the nice thing to do would be to ask permission to use your figures and link back

I always thought that MVP by definition must be a complete product, but existence of articles like yours and Intercom’s Cupcake approach[0] makes me wonder what exactly do some companies out there consider as MVP. Some sort of incomplete prototype?

[0] A great read too: https://www.intercom.com/blog/start-with-a-cupcake/

I noted below, that product people like Marty Kagan, consider a MVP to be a prototype where you test hypotheses. Worst case it can be discarded and a "real" product will be built after testing. It is a bit unfortunate in this that the "P" in MVP stands for Product.

Yes, it's copied, and it doesn't acknowledge that the ideas came from your article (even though it attributes the drawings to you with a "Source" link).

I think you should submit your article to HN as well.

I completely disagree, it's like the author misinterprets the point of MVPs from lean startups, and then argues against the misinterpretation.

MVP is a mindset. It's recognizing that the biggest risk most startups face is no one will want what they built.

An MVP is the smallest product you can build to test if anyone will want it.

If your product is "a podcast app with better ux" than you don't need to test whether there is a market for podcast apps. You already know there is. You're testing whether UX is enough of a market differentiator that people will use your product over other options. And to do this you need to build a "podcast that has a better UX than current podcasts".

If your product is "a crm with better reporting insights for companies that cold call" then maybe UX isn't as important as validating that these insights are valuable enough to some customers they will use product despite its lack of features and polish.

This often involves human ingenuity instead of software. One of the best examples of an MVP is Zappos, where the founder went down to a local Footlocker and took photos of all the shoes. He then uploaded them to his blog, added some margin on the price and had a buy button which emailed him whenever anyone clicked it. He’d then just run down, buy the shoe, add ship it over to the buyer.

A simple blog was turned into a e-commerce MVP and his idea was slowly validated.

At work we had to start calling things "minimum lovable product" a while back. Seems like corporate newspeak to me. It's the same idea as MVP - build just what you need to work, with a little better branding.

I think the author's first illustration shows this pretty well. They show an MVP as constructing the whole semi part by part and the MLP as using a wheel barrow, then a truck, then a van, then the semi. Only, that second illustration is obviously what MVP means. Use the fastest thing you can build that does the job. That's the wheel barrow until your load is too big. MVP and MLP actually mean the same thing - just people feel like "lovable" sounds better, when in reality it just obscures the meaning.

The author is right about one thing though. It matters what you're doing. If you're building a podcast app you've got to do a lot better than existing podcast apps to make anybody switch. You'll need to be much more polished. If you're making new you can be a lot rougher because people have no alternative. This isn't really an argument against the MVP idea though, it's more like the observation that UX has different importance for different products.

I would still suggest someone making a podcast app start with the MVP though and build that up until it was good enough to win users.

The term feels different to me.

MVP has more than a whiff of the half-assed and barely functional.

This is true, but that mostly comes from plenty of successfully founders talking about how their first products were half-assed and barely functional.

The whole point is answering the question "when should you close your IDE and start trying to sell your product?" and many of us who believe in the tenants of lean startup would answer that question with "as early as possible".

Totally agree, the other illustration where MVP supposedly only concerns functionality is not how I, or we in my company, ever define MVP. We use the other one to explain MVP to our customers. How can a 'product' be viable with only functionality?

In my personal observation, working in a cross functional team which includes frontend and backend developers, and ui/ux designers, an MVP only consisting of functionality just wouldn't be considered. Perhaps the author is used to environments where those disciplines are siloed.

If you're building a new podcast app, all you need is one feature that makes people love your app. People often use apps that have far fewer features than their competitor but do one thing very well. In this sense, I think the "love" part is even more useful to focus you in developing something unique about your app that will help you build a user base even if you don't have all the bells and whistles.

I think the author strawmans MVP: clearly a single tire or a burnt pizza is not viable for hauling stuff or eating.

Yup, he's overdoing it a bit there. But on the other hand, one could argue that many implementations of the idea of an MVP end up being like a single tire.

Does that mean that the MVP idea is flawed? No. But if the interpretations of the idea end up in flawed end results, it's time to look for new ideas that are easier to understand, even if it's through juxtaposition.

Over the years, I've noticed lingo different disciplines use to get their way without having to make rational arguments. For example, designers I've work with tend to abuse the idea of antipatterns. I personally noticed "minimum lovable product" make its way into this list last year as a way for product managers to avoid cutting features they want without having more rigorous justification.

The image to show the difference between the MVP and the MLP just show the difference between a non viable product and the MVP. The MLP is the MVP. To be viable it needs to be usable, reliable, etc. This idea seems to be trying to redfine an well known idea just because people are implementing the idea poorly.

If I could change one phrase in the developer vernacular it’s MVP to <Justifiably/Actually> Useful Product. MVP so often manifests as “a product that we need to deploy NOW, definitely won’t scale, but it exists and therefore is superior to nonexistent solutions”.

I've had so many endless discussions about what is viable, I've come to regard that word as deeply unhelpful to the development process.

My benchmark of MVP readiness is: can we expect useful feedback from a customer by demoing this? Some people want to demo a picture and some want to demo a near finished product.

For commercial products, I think the most useful interpretation is that a "viable product" is one that someone is willing to buy. That means implicitly that it has to provide value for the end user. One could also stretch the goal a little by saying that it means you can build a cashflow-positive business around the product. That implies both willingness to pay/end user value provided and an adressable market that can support operating the business. This latter definition avoids the case where a product fits just one single user and noone else.

I like Marty Kagan’s approach. The problem with an MVP is the the P. An MVP should be called prototype instead, which is used to test hypotheses. It needs not necessarily translates into a product and can have a very technical basis later.

Yeah, Cagan is big on "product discovery" which is validated learning about what people want in a solution to the problem you're solving.

He also just calls MVPs "experiments" - his main loop for product dev is Build - Test - Learn

If we combine straw manning and yak shaving, do we get straw yakking? Because that may be the real value of this article.

Couldn’t this be simplified to 3-4 sentences? Why so much ink spilled?

Your second question is "ink spilling" too.

The internet is 80% bloat

When I am seeing the title, it reminded me of that I want to build products that I fall in love with (and hopefully other users as well, but if not, then at least there’s me :) )

Reply on news.ycombinator.com