It's called “Ship” not “Shit” | Hacker News Reader

It's called “Ship” not “Shit”

blog.heyimcat.com

105 pointspantonepicker22 comments

The one thing people seem to forget: MVPs are supposed to be experiments. You do an MVP to figure out whether it's worth your time to build a product for a particular market (i.e. whether there is "product-market fit"), or whether you should pivot to something else. You make them minimal so you can afford to do more of them, because it's unlikely your first one will work. You make them viable because, if they aren't, your experiment won't tell you anything (people won't use it, even if they need what it does.)

If you already know your product is something people want (e.g. something a bank would just give you a business loan for), you obviously don't need to do an MVP, because there's already product-market fit. Starting a pizzeria? Front-load your investment and make a really great pizzeria; buy huge ovens, etc.

If there's literally nobody serving your market, such that it's unclear whether it's even a "need" or not—please don't spend years building the perfect solution to the "problem." Find out if it's a problem first. Build a prototype. Show it to people. Get them to say they're willing to pay you for it. That's what an MVP is.

(And, as soon as you've found your product-market fit, and decided which product you're going to build? Stop thinking of that product as an MVP. It's a real product now: make it good.)

I remember reading once that part of Apple’s success was owed to their shunning of lean principles, that they only ever ship complete, mature products. I would say that couldn’t be further from the truth: the original iPhone was about as minimum-viable as a category-defining hardware product could be.

It did only a few things (web browsing, media playback, email) better than anything else on the market, and left out nearly everything else that wasn’t critical to that core functionality (Exchange support, software ecosystem, copy and paste). If anything, the original iPhone was a demonstration of lean principles applied extraordinarily well: A bare minimum of functionality executed at eye-poppingly maximum quality.

The difference with Apple is that even when they do minimum, they polish that minimum offering very well. I know exactly the kind of stuff the article author is talking about, and most of it undercuts whatever ideas are being tried out.

Exactly. The iPhone might have been a minimum-feature product, but it surely wasn't Minimum Viable Experience.

> I remember reading once that part of Apple’s success was owed to their shunning of lean principles, that they only ever ship complete, mature products.

I think I read that, back when the original Macintosh was being developed, some people from Apple toured a Toyota factory to see how things were done there.

Since Toyota pioneered lean, it sounds more like Apple embraced lean principles than that they shunned them. OTOH, this would have been a number of years before Apple was anything like the success they are today.

EDIT: Also, do lean principles have anything to do with not shipping finished products? I thought lean was all about things like minimizing inventory.

I'm using too broad a term there. I should have been saying lean startup principles, as popularized by Eric Ries.

Ah, I see. I'd never heard of them or him.

I think I shall now exit this discussion and go enlighten myself.

This reminds me of my workplace.Unfortunately at my work-place people tend to confuse MVP with agile and TDD and then let all the bugs fly around pre-production and viola we go live with known bugs all around and hence depreciating customer confidence.

Quality is often overlooked here, b/c someone else proved that it can be done in 20 days and everyone wants it done in the same 20-days ,no-matter how bad the product goes out of shape :)

With time, this pattern only seems to worsen as there is less money being made day-by-day!

An MVP is an ugly lean-to (not even shack - http://en.wikipedia.org/wiki/Lean-to), it is 100% functional. Building it means getting airdropped into a completely unknown forest with an axe and nothing else (in this analogy the unknown is your market, and only an axe because you have no programmer resources except what you can wield by hand for a few hours), a few pieces of tarp, and 8 hours until freezing night temperatures set in. And maybe wolves.

It's not a minimum viable house, minimum lovable house, or whatever else. It literally is the absolute smallest thing that can POSSIBLY meet purely physical requirements such as protection from wind or holding some warmth so that you can, ahem, not die, and which you have any hope of building with no resources, and from nothing, using nothing. This is why it is absolutely crucial to know how long it takes to build, and why people focus on it.

In the market, it is the absolute smallest thing that anybody can use to achieve anything.

It doesn't matter what this designer thinks of MVP's, because when a designer starts getting involved, you are way outside of MVP territory. This author is an interior decorator criticizing a survival guide.

To the author: I don't know if you program, but if you want to experience the meaning of MVP, try coding something up enough for anyone to achieve anything using it. I guarantee you will not miss the time you spent not getting the design (aesthetics, love, etc) right.

On the other hand, you will die in the cold if you have nothing but a beautiful photoshop mockup to look at. That is the meaning of MVP.

This reminds me of the Humbug in The Phantom Tollbooth, who is described as "[someone] who always managed to be the first with the wrong answer" and later tries to argue that it was the question itself, not the answer, that was wrong.

It's a shockingly good lesson that I seem to re-learn every six months or so. Being first is never a virtue in and of itself. MVPs that sacrifice quality for speed (instead of sacrificing scope) always end up as painstaking rewrites at best, and slow slogs to failure at worst.

Something I think most miss is that taking on this technical debt is ok when you don't know which direction to go [0]. Get something to market to learn, not to be "first" or "right".

[0] https://www.youtube.com/watch?v=pqeJFYwnkjE

As an aside, this reference makes me happy. The Phantom Tollbooth was one of my favorite books when I was younger, just brilliantly written. So many good lessons about life (the Humbug being a great example). Another great one that is somewhat applicable here is Canby, the regular visitor to the Island of Conclusions, who attempts to be as much as he can be of all things (hence his name), which leaves him not very much like any of them, instead of picking one thing and mastering it.

Is this really a problem in the design/startup community or does it just appear to be so as judged by the loudest bunch? I'm not in the community so maybe I'm just not exposed to it directly, but these criticisms are awfully similar to what was happening before the first DotCom bust.

There is really and truly a problem. I've worked full-time for several start-ups (I'm working full-time for one now) as well as consulted for several more. I've also networked with a lot of startup founders and know many other people in the industry. From my limited experience it seems endemic - the kinds of people who flock to this apparently easy money are the kinds of people solely focused on winning the startup lotto quick. Not the kind of people focused on building good businesses. This means you get all sorts of short-sighted approaches to things. When those are inevitably frustrated by complicated realities (eg. when business isn't as easy as people were led to believe by movies and books) you then see founders/managers scramble to justify these bad practices. I've watched companies loop like this until all their funding went down the drain and then the founders go and do it again somewhere else. It's one of the big myths that needs to get busted - Adam and Jamie we need you! I'm trying to do my small part on the daily.

It sounds like people are trying to built something that just good enough to be bought by Facebook, Google, Microsoft or Yahoo so they can bailout, perhaps give a few talks and may rake in a few thousand Twitter followers.

That's exactly what they're doing. It's called "an exit strategy", and apparently any self-respecting startup ought to have one.

A lot of things about the products we see become clear when one realizes that the primary focus and goal of a exit-seeking, toilet-paper[0] startup is to get bought for a lot of money, period. The product itself is a lie, it doesn't matter what happens with it - its only task is to attract new users fast - i.e. be growing, which is a proxy for "we could be profitable in the future". If the startup maintains this growth long enough, there's an increasing chance that someone will come and buy the company. The product gets killed, founders write some audacious blog posts in which they thank their (former) users for giving them the opportunity to have those coctails at the acquihire party ("it was our journey, we couldn't make it without you..."). Everyone is happy, except the users, who get screwed. Again. Live. Die. Repeat.

Of course most of the toilet-paper startups won't sustain growth long enough and will just disappear somewhere along the way.

I sometimes wonder why we (as users) keep tolerating this. People lying in our faces that they care about us and our problems, that the product is really meant to help us. Fool me once, fool me twice... but we've been fooled since the dot-com and we still haven't learned.

[0] - https://news.ycombinator.com/item?id=8319102

MVP is about cutting out non critical features, not quality. Without the quality you just end up being slower at iterating and the whole process falls apart.

But it ends up cutting out on quality, because people are used to put up with quite a big amount of crap. If it weren't the case, a whole great deal of business models wouldn't ever panned out.

Has anyone ever produced a maximum viable product?

Or even tried to produce one?

All you really need is a long view. You can ship something with, say, two features now, but done in a way that anticipates the other 10 features you'll implement later. Planning should take a while. And when it's done you can ship bit by bit without screwing up your timetable or the product's integrity.

MVP, MLP, MUP or whatever you want to call it needs to create value for at least one person.

Value + People

The product needs to increase the number of people extracting value from it, increase the value your product creates or both.

Facebook creates some value for a billion people, thats why it is valuable to the tune of $203.58B.

The question is what is the smallest amount of value you can create with the smallest input for one person to test your idea that you know can scale to as many people as possible or continually increase the value for that one person.

And your product doesn't need to be code initially.

I firmly believe that MVP culture the writer is referring to comes from Venture Capital, as a way for VC's to ping the market state faster at the cost of individual startups.

In aggregate they get more data and more likelihood to get find a single success faster, but you as an individual startup are far less likely to find success.

catchy title and this was a great reminder of finding the balance between speed and quality. Many answers that I was looking for have been presented through user growth and interaction. Without getting my app up there, it would be very difficult to come to that conclusion. I have also found that building a solid foundation can save time in the future even though it may cost more time currently.

A super simple example would be writing lines of code. Making sure all the tags line up properly and everything is commented out will allow the app to flow more efficiently in the future. Go-fast/efficiently

Reply on news.ycombinator.com