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...
I think you should submit your article to HN as well.
[0] A great read too: https://www.intercom.com/blog/start-with-a-cupcake/
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 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.
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.
MVP has more than a whiff of the 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".
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.
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.
A simple blog was turned into a e-commerce MVP and his idea was slowly validated.
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.
He also just calls MVPs "experiments" - his main loop for product dev is Build - Test - Learn
