Following the Lean Startup Method
june.so
june.so
For exactly this reason, although the lean method still works, it is no longer a 'revelation' or an 'edge'. It was a revelation when the cost of validation was low. Now using the lean method is just a triviality: you constantly need to validate your ideas. As the cost of validation increases dramatically the importance of other success factors (like insight, strategy, deep knowledge) increase.
Also: don’t forget business model validation. Having great tech that sellers won’t sell, or customers can’t buy is a tremendous waste.
https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation
> The point is not that all maps are useless; rather, the point is simply to maintain critical thinking about the discrepancies: whether or not they are either negligible or significant in each context, how to reduce them
If you say you're "doing agile," you don't have to put the effort into writing rigorous requirements. If you say you're "doing an MVP," you don't have to put in the effort into building a rigorously-engineered product. Neither model is supposed to be about being lazy. They're supposed to be about making trade-offs between different kinds of rigor.
Agile is supposed to unlock the ability to truly re-plan after each sprint and make very different decisions about your product direction. It's only a positive tradeoff if you are being rigorous about looking at your results, generating alternative paths, and assessing them. Otherwise you just end up with no documentation and a shitty architecture.
MVPs are supposed to be prototypes that reveal the answer about a specific hypothesis that is critical to your strategy. It's only a positive tradeoff if you are rigorous about what knowledge you don't have about your customers and technology, and build exactly the thing that will answer the question. Otherwise you just end up with a half-baked and buggy product.
Together, they give you the information you need to head in the best direction and the means to do so. But only if you're taking all that time you were originally spending on system design, rigorous documentation, and product quality and putting it towards stuff that tech teams aren't usually as comfortable doing.
Put differently (to put the misunderstanding to rest): MVPs aren't alpha- or beta-versions of software; don't treat them as such.
- Technical debt /migration costs when mvp matures / more bugs - High support costs, since MVP often doesn't solve everything lot of manual work needs to be done. - Often making promises of future features to close sales - This leads to high emotional costs, continue asking of clients when promises are fullfilled.
Now of course you can create a very stable solid product, properly tested with perfect data structure. But that's highely unlikely to happen with an MVP, due to the nature of the approach.
Also very hard to get exact feature set right.
These things are solvable, but I don't think they are always properly adressed by the advocates of the approach.
I think this is more to do with "move fast and break things" than MVP specifically.
> Now of course you can create a very stable solid product, properly tested with perfect data structure. But that's highely unlikely to happen with an MVP, due to the nature of the approach.
The interpretation I've always had is that an MVP is the smallest subset of useful features to take the product to market. How you reach that subset is entirely up to you, and in my opinion, you should take time and do a good job, not rush.
In my experience, if you solve only the problems you have, you'll be fine as far as long term maintenance goes. Hacks and corner cutting are inevitable but you'll be doing a lot less of it if you can stave off the desire to invent new abstractions.
an MVP is the smallest subset of useful features to take the product to market in order to prove or disprove its viability
and the reason you want to keep it to the minimum is to minimize the time and money invested in it so that you can throw it away if it doesn’t work and then try a different product. You’ll probably have to do this several times before succeeding so your budget for each should be about 1/10th of your available time and money.
Maybe your MVP doesn't require full HIPAA compliance, or nine nines availability, or the ability to manage users via a front-end, or...
Typically people do want software that's intuitive to use and doesn't crash, so you don't want to ignore those requirements, but most of the others are for grabs.
This implies your MVP is tightly coupled to your ideal customer profile, your GTM strategy etc:
Which audience will want to pay for this specific piece of functionality, despite all of its flaws (why opt for a non-established supplier? What's the out of of the ordinary part of the service that makes me willing to buy this? ...)
An MVP is built to validate a business hypothesis, and you should try to do the minimum to do this. Technical debt is unavoidable, as you usually don't know upfront what all the requirements will be within 5 years from now. Trying to architect upfront for this will usually fail, as most of your assumptions will be wrong anyway.
My #1 tip is to try to build a composable system where you assume the majority of the components will have to be replaced multiple times over a cycle of n years, so make them easy to throw away and start over...
And for longevity of a project emotional stability & grit is key. That's something the lean startup method completely ignores.
tldr, nothing new, everything existing on saturated market, but with "AI" added to the company description. What AI will do exactly is not specified.
All of them did come to less saturated markets than what we have now.
The point is that 10-20 years ago market were much less saturated, so some lean startup could build quality product and strive in half empty niche. Since then there is so much money and people were injected into software/tech, that it is very hard to find not saturated niche for lean startup(meaning little funding).
Now, I would agree that Tesla wasn't lean. But the point of your comment as I understood it was that lean or not, in a world of saturated markets, you must have massive marketing. I think that's demonstrably not true, and gave examples where I think it's clear that innovation was more important than marketing.
it was innovation outside of tesla. If battery capacity/cost wouldn't improve, tesla would still be producing short range roadster for rich people.
There are pivot points in different markets, when some breakthrough happens, and first mover is having huge advantage, but it is rare and unreliable event, since you can invest in area, but break through won't happen.
> I think that's demonstrably not true, and gave examples where I think it's clear that innovation was more important than marketing.
And your examples are not correct, Amazon was not on saturated market, tiktok and iphone were launched by corp with likely significant marketing budgets.
There are likely examples of success and Cinderella stories, but the question is in success rate. On unsaturated markets such rate will be 10%, while it will be 0.01% on saturated markets.
Say, I am lean dev in area of AI, and I am building something innovative, how can I find customers and squeeze through the crowd of hype and tens thousands startups and tools?
Once you've proven some level of market fit with a lean approach, you're much better positioned to get investment. Lean doesn't mean completely bootstrapped. The problem that lean seeks to avoid is burning through investor cash making mistakes in getting market fit that you should have made before investment. By the time you get investor money, you should be ready to make the next level of mistakes. :-)
I just checked, and the book is completely missing this point how did they get to these customers in my brief reading. This is Vision->Learn->6 months after launch section in the book.
> The problem that lean seeks to avoid is burning through investor cash making mistakes in getting market fit that you should have made before investment.
I agree, but the point is that marketing part is much more important now than then, and completely missing in literature, there is no "lean marketing" paragraph or book, and I am not sure if it is reliably possible.
In saturated markets what works is marketing and branding. Basically occupying a different part of the mind as all other products. It's also very fun and exciting to do.
The biggest thing I learnt before turning my business and making it work is that most business education / videos out there are out of date.
The real trick to business and the only example of this is what I heard Paul Graham mentioned once in an interview: doing something naughty.
Amazon started off by cheating wholesale book dealers. Facebook started with mass scraping. LinkedIn started with mass spamming. Snapchat started for sexting. YouTube started with piracy.
Doing something naughty is what gives you the competitive edge.
Seems to apply here
>Showing my first, most loyal customers a MVP ruined my image/branding. Instead of looking professional, I looked like a cheap blog.
>Selling a MVP to these people made them never return as customers. While I stand by the base quality of the product, it didn't have the shine we see in Apple products.
>I see sites in my space that are far worse, and much more popular because of the shine/marketing. I really have the best website from an objective standpoint. The discoverability is a real issue, I mostly grow organically or from SEO.
tl;dr I showed my 95% finished product to the thought leaders, they thought I was unprofessional and couldn't be trusted. Still trying to gain that trust back 10 years later.
That is: what you thought was the important part of the 95% and what the potential customers thought, differed too much.
Sidenote: I wouldn't be surprised if you closely followed what customers stated and still ended up somewhere they didn't care for.
It's a bit like yelling "not real socialism" / "not real capitalism" every time someone gives a good counter example to your prefered ideology
If you get far enough along where you're not able to iterate with well-regarded design partners out of the gate, you've messed up somewhere along the minimum and/or viable spectrum.
As the minimum viable product approaches the complexity of a complete product, the difference between the two shrinks to the point that the concept of MVP isn't all that useful anymore. That's the actual case against Lean Startup in 2024.
To be clear, I personally think MVP is still an immensely useful concept, but Reid's own 0-100 scale makes it hard to understand that. There is no 100. Most SaaS, and user-facing software in general, must be developed and maintained perpetually. It's not about approaching 100, it's about approaching a limit at infinity.
Today's MVP identifies a local maxima that's a composite of two axes: user experience, and technical debt. If that sounds surprisingly similar to the original definition, that's because it is.
I think this is an excellent way to summarize this.
I'm one of the anti-MVP persons out there, and my point is that more often than not people tend to use MVP as practice ship something half baked, not truly trying to build something viable or trying to validate anything. Then the response is crickets. In many professional domains, people are busy and not willing to spend time or evaluate solutions that are half way there to provide any value.
For startups with limited resources, more practical advice would be focus on building great core experience for a specific user group. You narrow the scope, build less but something better and different and shows the value for that group fast, whatever it takes.
You could call this a MVP but I'd just call it building a product people want to use. The MVP term is unnecessary.
Some ways maybe the success of Lean Startup also means that it's just a normal to build things iteratively. I don't think anyone is recommending here go back to the days shutting yourself in a basement for 5 years and then shipping 10,000 copies of it on a CD to all the RadioShacks.
Isn’t the difference here just semantics
From my understanding the premise of the article is that over the years there’s too much negative sentiment around the term MVP.
This negative sentiment comes from too many people building a half assed product instead of a kick ass half
When that happens maybe it's just time to retire the term and move on. These days it's common to validate products as you build them. You can critically think what a good product looks like in your space and aim for that. Then iteratively improve from there. Not sure what the MVP term really contributes to the practice.
The term exists to represent a snapshot within the longer life a of a product
Its purpose is for you to understand how far do you need to go with building to start getting your first believers on board, while making progress towards a broader long term vision
[1] https://blog.georgovassilis.com/2022/07/10/team-topologies-f...