A special thank you to the following people who provided early feedback to a draft of this post. Scott Belsky, Ryan Singer, Todd Lombardo, Wes Bush, Darius Contractor. An additional thank you to Julian Lehr, Lenny Rachitsky, Kyle Poyar, Ramli John, Rajiv Ayyangar, and Michael Houck.
One of the things that the current generation of tech entrepreneurs seems particularly fond of is attacking the “Lean Startup” idea. The conventional discourse around this topic pretty much goes like this:
“MVPs? It’s an outdated concept that doesn’t work in 2024 and you don’t really need an MVP if you’re ambitious enough about what you are building.” Or “Do you think Steve could have invented the iPhone had he followed the lean startup method? It only lands to marginal, local maxima..”
I was recently listening to interviews with none other than Lean Startup inventor himself, Eric Ries, on the podcast that Lenny hosted just a little than 3 months ago and, the more recent one on Greg Isenberg's YT channel, and it felt like everyone has read the Lean Startup but hasn't understood the key message.
I read it more than a decade ago, and I still ended up wasting too much of my time building something that no one wanted (but that’s another story). Nowadays, working at June I have the privilege of talking daily with founders, and I see that lots of them are still failing exactly how the book describes failing.
Which makes me wonder if all the prevailing skepticisms that permeate most aspects of the current tech Zeitgeist, starting at the press level, then down to the VCs and the entrepreneurs scene, is all just some sort of massive intellectual conspiracy devoid of any logical foundation.
But at the same time, I can’t help but think that this is not 2008 anymore (sigh). It’s a different world. People don’t work in cubicles, programming computers isn’t just a hobby for nerds, CS majors have more students than all humanities majors combined and 80% and 50% of the Top Fortune100 are now tech companies. I mean, if that means anything, the suspicions can all be indeed very well justified.
How can something conceptualized so long ago still be relevant in today’s world given that these last 15 years have changed pretty much everything we knew about the internet, technology and entrepreneurship in general?
As you can imagine, I authored this piece in my head multiple times before finally hitting the “publish” button. Way too many people have said way too many things on this topic. Given the plethora of opinions (most without real facts or data) already floating around, I thought that adding just another echo to the chamber wouldn't cut it.
So I decided to take on a different path. Share something personal that either came from my direct experience on the field or facts baked by numbers and actual anecdotes. Not with the arrogance of those who have told you that the “Lean Startup” was the ultimate silver bullet, but with the humble curiosity of someone who’s been in the trenches for over a decade and is now seeking to understand what is still good about the “Lean Startup” that makes it worthy for the newest generations of entrepreneurs and what, instead, is outdated and needs a bit of re-interpretation.
Building an MVP: 2008 vs in 2024
Ah, MVP.. the most misunderstood word in tech history.
I believe some folks in tech love to make simple things sound complex, maybe to seem more impressive. Here’s my attempt to cut through that noise and get to the heart of MVPs: what they truly are, what they aren’t, and most importantly–to explore whether Ries’ ideas of MVP from 15+ years ago still hold up today.
Imagine there is a spectrum going from 0 to 100; where 0 is your product today (just an idea on paper) and 100 is your product in 5 years (implemented to the last detail). If one could wave a magic wand and instantly go from 0 to 100, MVP wouldn’t be a thing at all because there would be no risk. But in the real world, going from 0 to 100 it’s a bet that takes a whole lot of time, energy, and above all—money. So, our common sense tells us that we need some sort of “milestone” in between 0 and 100 that reduces our upfront risks (in the present) while making us more certain that our ideal product (in the future) is exactly what people will want.
From this perspective, the MVP is the factual embodiment of a hypothetical X risk-factor included between 0 to 100.
The conundrum that most early stage entrepreneurs face is this: what is that “X” value so that A (0+X) guarantees us less upfront risks and B (100-X) that maximizes our validated learnings? Clearly this decision is a trade-off– the lower the X value, the less upfront risk we embark on, but the less we validate and the less certainty we have toward our final goal. The higher X is, the more we can validate our final assumptions, at the cost of undertaking much more initial risks.
Now, it’s also worth pointing out that this doesn’t suggest that MVPs aren’t an intermediate, incomplete version of your final product.
In other words, a 50% X-value indicates that you are willing to take on half of the risk, and not necessarily that you have to build half of the final thing. Products are complex creatures, with many layers, dimensions, and interlocking parts. More akin to discrete ecosystems than linear constructs. In crafting them, it is your job to pick the right elements and arrange them, as if they—as Alexander would say—create “wholes”. Great MVPS are self-sufficient systems that are not only complete and functional in their initial form but are also the initial building blocks that allow for the rest of the system to be bootstrapped and built upon.
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.
Yet, it’s shocking to me to see that many failed to understand even the very basic idea and the conventional discourse around MVPs to this day still revolves around arguments like:
“MVPs don’t work anymore. People’s expectations have risen up. We’re not in 2009 anymore. You can’t just put a crappy product out there and expect people to use it.”
And to be completely fair, there’s nothing wrong with that statement. It’s true; as consumers we are much less impatient than we were 10 or even 5 years ago. There are many more competing alternatives for the same tasks, and unless we see some clear speculative advantage, we are more resistant to change.
The point is that, as Eric and Lenny well-explained in the podcast, this has nothing to do with the notion of MVPs. It’s a mere observation of consumer behaviors and customer expectations.
MVP isn’t the same as Minimum Amount of Effort. It is exactly what it says: a minimum viable product, key word being “viable”. An MVP for a mission critical application or a cutting-edge piece of research isn't going to be cheap or easy, because for it to be “viable”, it will need years of R&D. Similarly, the MVP for an ancillary service in a less competitive market (say a niche vertical in the building construction industry) will likely need to be less sophisticated and (perhaps) have more error allowance.
The MVP is a tool. A tool to test a set of hypotheses. Whether testing those assumptions is a costly or cheap thing to do, it’s entirely subjective and up to you and the criteria you pick.
Then, why at the very idea of “MVP” most tech people recoil in disgust and immediately start thinking of an unpolished, crappy product? Why does in the collective imagination MVP equal half-assed, cheap, shitty products?
I have a theory.
In the 2008-2012 era, competition was low and software wasn’t as ubiquitous as it is today. It did make sense, for the first tech pioneers to ship an unpolished product fast, launch it early, and see how the market responded to it. Did the customers like it or not? Did they use it or not? And iterate their way to something that was useful and people were happy to pay for.
“If you aren't embarrassed by the first version of your product, you've launched too late”, did actually make tons of sense back then. For Reid Hoffman and many of his peers, having a flawless, polished product was an order of magnitude less important than getting a foothold in the market before anyone else and starting to get feedback.
Can we say the same, is it still valid for today?
It depends, but the answer is more likely to be a “no”, than a “yes”.
Does that have anything to do with the notion of what an MVP is? Frankly, no.
If you truly believe that having a polished design, and a high level of perceived quality is a criteria that you think matters to the point that you won’t have customers and get feedback otherwise, you are free to do so. And you might be right.
Just keep in mind that the more you invest in that area (hence, increase the value of X along that dimension), the more you need to be experimental across all the other vectors to control and minimize upfront risks.
I see a lot of entrepreneurs nowadays raising the bar for their MVP, taking much more upfront risks than the previous generation took. And I don’t blame them.
I think a lot of it has to do with the fact that the tech sector is now starting to look much more like any other industry. The tech market has reached a certain maturity and a lot has changed from the SaaS boom era of 2008-2012, compared to today.
For starters, the cost of producing software has been drastically reduced. The first generation of entrepreneurs is well aware of the burden of planning ahead to buy or rent servers and bare metal. They surely remember the headache of migrating to a new host and going over a checklist with over 250 items in it.
Today, need more computing power for your app? Simple, just spin up more instances on AWS. Need help for extra storage? S3 is at your fingertips, ready to scale with a few clicks
If you think about it, you don’t even need to plan for office space anymore — a coworking will give you a full office on demand. The same goes for the talent pool available. It’s easier than ever to find young developers, assemble a remote-first team and get a scoped prototype done in a matter of months.
It’s easier than ever to build, deploy and scale software, and as a result of that, paradoxically the cost of making a uniquely differentiated MVP has gone up.
For years, the prevailing advice to startups was, “do 1 thing extremely well”, and for a good reason: the first generation of SaaS winners all started with 1 unique feature that got them a foothold in the market that allowed them to eventually dominate it. Think of PagerDuty – it started out as a simple digital pager that turned out to be a massive company in incident management ops.
Does that playbook still work today? Starting with “1 thing done very well” often just means that your MVP can be built within a month or week, and that likely means that there are already multiple clones on the market. Moreover, unless it’s a burning problem in an underserved segment, the expectation customers have is that you also solve the other 5 or 6 adjacent problems/issues for them to justify a switching cost.
Unlike 10 or 15 years ago, to build a sufficiently differentiated MVP a team needs to deal with a lot of complexity and undertake much more economic risks right from the get go.
Think about a product like Figma. Their core thesis was that design should be collaborative and accessible for everyone. To truly embody this vision, it was crucial that their design tool seamlessly integrate into an environment people were already familiar with: the browser. On a more practical level, this ambition translated into creating a browser within a browser. The company spent the first 4-ish years trying to build a series of disconnected projects to replicate photo editing functionalities within the browser, leveraging webGL, asm.js, and all sorts of low-level sorceries to bypass conventional browser limitations and communicate directly with the hardware.
Figma obviously took bigger risks than most startups dare to, diving deep into tech challenges no one else wanted to touch. But it paid off. They smashed through those barriers and tech hurdles, setting the stage for everything they’ve achieved since.
Operating & Pivoting: 2008 vs 2024
Eric borrowed the term "pivot" from basketball, not inventing the term but repurposing its analogy for startups. In basketball, a pivot is when a player keeps one foot firmly planted on the ground while moving the other foot to reposition themselves without traveling.
In the context of startups, this translates to keeping the foundational vision of your business grounded—while shifting another aspect, like your product offering or customer segment, to find a better position in the market, which Hiten Shah articulated well.
Immediately after MVP, “Pivot” is the second most controversial word of the Lean Startup method and for clear reasons. Deciding when to pivot or stay the course is a challenging process that the vast majority (50% of every YC batch) of founders encounter at some point or another. Choosing to pivot prematurely without enough evidence can mean missing opportunities. Waiting too long to pivot can mean wasting time and resources on a product that does not deliver.
The decision to pivot, and the very nature of these strategic shifts, is deeply influenced by the context in which a startup operates. Over time, as the startup ecosystem has evolved, so too has the approach to pivoting.
The Lean Startup method has always loudly advocated for the importance of pivoting, a stance that has historically led to considerable controversy. Critics frequently see this push to pivot as a license to failure, yet I believe it's important to delve into the original context of this idea to assess its relevance and application in today's environment.
Most entrepreneurs today don’t remember the Dot-Com bubble of 1995 or the Dot-Com crash that followed in 2000. As a reminder, the Dot Com bubble was a five-year period from August 1995 when there was a massive wave of experiments on the then-new internet, in commerce, entertainment, nascent social media, search, etc..
The idea of the Lean Startup was conceived on top of the rubble of the 2000 Dot-Com crash. A period in time where the internet and software delivered through the internet was a whole big experiment.
In a time when the software industry was a massive greenfield full of opportunities and value yet to be unlocked, it was common practice for entrepreneurs to treat startups as “experiments”. This was because the cost of lingering on a potentially failing idea—despite not being entirely sure—far outweighed the risk of starting anew and possibly overlooking a bigger opportunity.
We can all agree that in 2024, the entire software industry is much more saturated and opportunities for breakthroughs are much rarer. Entrepreneurs are much-less driven by short-term heuristics because it takes much longer and much more work to see if an idea will ever work out. Nowadays, the significance of marketing and sales has dramatically escalated. Success now demands a serious approach to these areas, a contrast to the early Lean practitioners who enjoyed the advantages of easier distribution.
Does this imply that the idea of pivoting has become antiquated? Certainly not. However, the approaches to pivoting have mutated.
If before, startups could quickly switch paths when hitting a dead end, now it’s clear that they need to think harder and move only when they're onto something solid. In other words, it’s more reasonable for teams to pivot not just because their first idea isn't working, but because they've found one that is.
Overfunding and the VC game
After the Dot-Com crash in 2000, venture capital dried up. Funds launched during the boom were underwater, angel investments vanished, and many corporate VCs shut down. VCs were no longer pushing startups to spend big and “swing for the fences”; they were now urging them to cut down their spending. It was a tough time for startups looking for cash.
With risk capital at a premium and the public markets closed, startups and their investors now needed a game to save cash and survive long enough to start making real revenue. And to do that they needed a different method than just “build it and they will come.”
The "Lean" approach emerged as a way for founders to keep their vision sharp while running their operations without burning through cash too fast. It was the answer to a specific startup problem at a specific time.
Today, the VC landscape has completely changed. And not just because there's tons of money everywhere, but specifically because investors have gotten much better at understanding the game of outliers and disproportionate returns.
In a world where capital is much more abundant, companies are exposed to the opposite risk: overfunding. This was especially evident during the pandemic when interest rates were low, and there was a hiring spree across the tech industry. Many startups, flush with capital, overhired and expanded rapidly, not always in line with genuine growth or actual needs. Instead of setting the best engineers to work creating the best product, they're busy recruiting and dealing with bloated teams and company growing pains from the get-go. They faced immense pressure to deliver huge returns, leading to a "go big or go home" mentality that often sidelines healthy innovation.
That said, even in an era where securing funding is comparatively easier, there's immense value in maintaining the ability to operate a startup efficiently and at a high velocity.
Needless to say, this principle holds even for well-funded startups; having a substantial amount of capital doesn't necessitate rapid cash burn, especially on hiring. This isn't just frugality; it's strategic. It’s the mythical man-month that every entrepreneur and the scarcity of top-tier talent suggests that simply adding more people doesn't linearly increase productivity.
For startups, especially those in their nascent stages, agility is a critical asset. Founders knowledgeable about the pitfalls of rapid scaling understand that a more significant headcount can become a liability when – for example – a pivot becomes necessary. After all, it's much easier to change direction in a speedboat than in a cruise ship.
This is why Stripe, with $20 million in the bank from seed and Series A rounds, still took 6 months to hire its first 2 people.
Rejecting the Lean Startup method
Is the lean startup approach always the right move? Of course, no.
It's important to recognize the scenarios where it might not be the best fit. For starters, if you're not worried about the risks you're taking, the lean method might not be relevant for you. This could be because either:
- You're flying solo, building something for the sheer joy or challenge of it, unconcerned about market validation or proving hypotheses. If that's your vibe, I've got nothing but respect, and forget everything I said earlier
- You're part of a bigger outfit with the resources and leeway to bet big. This is the case for larger companies or divisions that can take calculated risks
Or, the exceptionally well-funded top 1% ventures of the market. These companies operate under a different set of rules, typically led by teams with impressive track records. A friend describes these as "blockbuster startups"– akin to major film productions with stellar budgets, celebrity-like leadership, and major press spotlight on them.
These ventures either achieve remarkable success or fail spectacularly; there's rarely any middle ground. A prime example of this is Quibi. A company founded by Hollywood veterans that raised nearly $2 billion before its launch, only to shut down within six months. Or Powa Technologies - A UK-based fintech company that aimed to transform mobile payments. The company was once valued at $2.7 billion but went into administration after failing to deliver on its ambitious product promises.
Conclusions
For the other 99% of startups out there——resist the prevailing narratives of success. Get practical. Validate your ideas. Seek the truth rather than confirmation and don't fall into the trap of copying strategies from those operating in a completely different realm, oblivious to your existence.
Stay grounded in reality, do the simple things extremely well. Spend lots of time speaking with customers. Get really good at customer interviews. See how people use your product. Figure out smart ways that minimize upfront risks. Optimize for the problems you want to have. Build something so compelling that users can't help but use it deeply, quickly surfacing their own ideas for how it could be even better. Use your taste, your instincts but always test and challenge your hypothesis early and often. Don’t overcomplicate things with unnecessary frameworks. Don’t listen to the latest methodologies that the latest social media gurus are selling you and... for God’s sake, use the Lean Startup method.
