"What Ries and the Lean Startup advocate is picking an X value so that you have to build as little as necessary to validate your long-term assumptions. Neither the book nor the method prescribes whether the “X value” should be high or low on the spectrum. This decision is entirely up to you, influenced by your market and your criteria for evaluation."
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.
Y - the concept of frequent validation differentiated the stuff I’ve worked on that’s done well from the stuff that didn’t. Put a different way: the items that we didn’t get good validation on had to landed with a thud in market, or needed to make sizable changes before they were accepted. The items we validated effectively had to make the same changes, but we got there in smaller steps with less pain.
Also: don’t forget business model validation. Having great tech that sellers won’t sell, or customers can’t buy is a tremendous waste.
One of the most important life lessons I've learnt is to not conflate the model for the reality it tries to capture but also not waste a good model because it doesn't perfectly capture the underlying reality. In this case, poor understanding of both the model and the underlying reality means that people will dismiss both the lean startup methodology and MVP as a technique when both are incredibly powerful tools aimed at exploring if and how a product might be successful.
Absolutely. It's become almost trite at this point to note that "all models are wrong; some models are useful," but it's true and the MVP is one of the better ones. The difficulty is the same one Agile has - the model has become more useful as an excuse to avoid rigor than as a way to get better outcomes or understand the world.
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.
> 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.
Put differently (to put the misunderstanding to rest): MVPs aren't alpha- or beta-versions of software; don't treat them as such.
> 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
- 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.
To me, an MVP is about reducing functional and non-functional scope: which requirements (functional and non-functional) can I take away from my solution, while still having built something people want?
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...
> 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.
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.
Yeah but those ideas don't work well together, the whole idea of MVP is to move fast, since you don't know if it's worth investing time in those features yet. So it also doesn't make sense to fully develop it to maturity in that line of thought. So practically that's what happens.
I think marketing is more critical choke point in current saturated markets.
And if company needs lots of fund to promote product, it doesn't really matter if product is lean or not.
The automotive market before Tesla, the smartphone market before the iPhone, bookstores before Amazon, social media before TikTok, etc. And those are just high profile examples, there are thousands of new businesses launched every year into existing, "saturated" markets and not all of them fail. Sure, marketing is a component of success but innovation can and does succeed, every day. And of course the lean startup approach doesn't apply only to innovative businesses, it's just a philosophy for proving out your market and solution by experiment rather than by theory.
tesla and iphone are not for lean startups which we are discussing.
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).
I understand the point, I just disagree with your hypothesis. The automotive market was overwhelmingly dominated by a few massive players. Tesla pushed into that market with innovation, not mass marketing. Do they even have advertising now? Yet they have the top-selling model in the world in the Model Y.
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.
> Tesla pushed into that market with innovation, not mass 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?
If you read The Lean Startup, you'll have the answer to your question. AI startups don't generally provide AI, they solve some problem using AI. Now, if the only advantage your AI startup has is that your solution costs less at scale, then you're right, lean isn't going to work well for you. But if your solution is significantly better even at small scale than those available in the "saturated" market, then the lean approach is to get your solution out there in some kind of minimal form, to some small group of customers. You just need to prove that there are people who will pay a price for your product/service that you can imagine making money eventually, even if you have to do some things manually to start that you will automate in software later. The book gives examples of this.
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. :-)
> If you read The Lean Startup, you'll have the answer to your question.
> then the lean approach is to get your solution out there in some kind of minimal form, to some small group of customers.
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.
Well since we're on HN just take a look through the latest YCombinator batch. Some are attempting to break into saturated markets but others are entirely novel.
I think the lean startup method as described in the book doesn't work anymore. It works well at the beginning of a wave when things are unknown. Maybe with ai products it's still doable.
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.
My strong 'Anti-Lean Startup' take. I partially blame that book on my first failed company. I passively maintain that company now. Sure I was 23 years old, but....
>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.
There is a lot of luck in figuring out what’s minimum viable. even if you listen closely and deliver what the customers say, there is a good chance they won’t like it when they get it.
But this isn't redefining the term. Running experiments to discover what's most important, then focusing on building to solve for that is the whole point.
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.
While I'm a huge fan of the lean startup method, Ries was heavily associated with the R E S I S T movement and ultimately ended up creating resistbot. Kinda lame imo.
The author argues that the notion that an "MVP is an outdated idea" is a misunderstanding of the definition of MVP, but I think the author is missing the the point that those folks are trying to make.
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.
> 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.
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.
It's is but that's the issue. The term is misused and misunderstood. Meaning variety of things and activities. How the definition has emphasis on building something quickly and cheaply, can do more harm than help.
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.
I think whether we want to call it first great core experience, v0.1, first iteration or MVP there is always a point in time for every product where you’re ready to start having some users
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
Why should money cost money? It's created literally out of bits being flipped in a computer. It's marginal cost is essentially zero. The only thing affecting its price should be the risk profile it's loaned against, not the cost of obligated associated liquidity.
How to test hypotheses? Because I need a framework for testing business hypotheses like how developers need the Angular framework for front end web development.
So essentially MVPs need to demonstrate higher quality now, attesting not only to the product, but to the capabilities of engineering organisations. Team topologies [1] is an organisational paradigm that solves a major issue with tribes locking themselves up in silos, while contributing to quality on both product- and platform- levels.
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.