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.
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.
Or even tried to produce one?
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".
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.)
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!
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.
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.
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.
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
