I read a popular article recently arguing why anti-lean startups are back because lean isn’t a viable way for ambitious startups tackling new domains, like artificial intelligence, to take moonshots.
Hmmmm…
As a practitioner of lean startups achieving high growth in Fintech, I’m intrigued with counter-arguments to the methodology.
The article states getting paying customers is an anti-lean advantage:
“Anti-lean ventures, which have what lean startups sometimes lack, customers willing to pay for them. This fact alone upends the usual freemium model!”
Actually, points can be made that lean startups are particularly good with validating market (willingness to pay) risk.
Many lean startup experiment designs like ‘Wizard of Oz’ or ‘Concierge’ tests provide results to market demand learning goals AND get customers to pay before even building a product.
Freemium is a choice to prioritize user growth over immediate revenue. It doesn’t have anything to do with following lean startup principles or not. While the result in the number of IPO’s with freemium business models (and many more acquisitions) show validity to the growth approach, freemium companies aren’t necessarily lean, and lean companies certainly don’t have to use freemium.
Product risk is hard for lean.
“There is no notion of a buggy but usable v1.0 electric car; at the failure rate of a typical MVP, such a vehicle would harm thousands of people.”
Yeah, it totally makes sense that a vehicle that harms thousands makes for a terrible MVP. It isn’t viable.
The dialogue of moonshot startups’ claim towards anti-lean tends to lend itself not to market risk, but the immense technical (product) risks they face.
That’s a bit easier for x.ai since market risks are validated by proxy because people have been concierge testing personal assistants for centuries. There is very little risk here.
But the lean startup route isn’t about getting customers to pay or being better at validating market than product assumptions.
Lean is the practice of identifying your riskiest assumptions, and (in)validating them with the least amount of resources possible (time and money), in order to progress to a more certain successful outcome.
Nowhere in this are the practical tools or hard definitions of the amount of time or resources an MVP should be. These stereotypes are results of techniques that work well for internet startups. Different lean startup techniques and definitions are needed for different business models. Lean’s methodology must be adapted to its constraints.
Really though, the enemy here isn’t lean.
I bet we’d agree the enemy is spending our precious time and money on degrees of uncertainty that are unnecessary when there’s a less risky and faster path towards realizing (or discontinuing) the vision.
The point of lean is asking the right questions and designing the right experiments to answer them, with few resources and the highest degree of confidence that creates progress on a vision. It is a most difficult and uniquely human skill. They are the foundation tenants of the lean startup. Of Science.
Which takes us back to the core of the article’s argument: “there’s nothing wrong with lean, but when you’re pushing the boundaries of science, it fails miserably.”
Really though? Let me introduce NASA’s Apollo venture as written up (in this ‘updated’) July 21, 1969 article in the New York Times:
Apollo Mission Pioneers Lean Startup, Reaches Moon! How’d they do it?? The New York Times report summarizes:
- Project Mercury passes success criteria of putting a man in orbit and bringing him back!
- Gemini Space Launches validate the ability for humans to orbit the earth in technical spacecraft maneuvers.
- Saturn I missions prove rocket MVP sustainable to develop the more powerful and larger Saturn V manned rocket!
- Unmanned Apollo 5 is able to validate ascent and descent hypothesis of rocket and return module.
- Unmanned Apollo 6 fails success criteria of structural and thermal launch tests providing important data for product pivot.
- Apollo 9 is able to de-risk the ability to detach and rendezvous maneuver of lunar module by astronauts. Running its experiments near earth.
- Apollo 10 validates manned lunar and command module performance orbiting the moon and back.
- Meanwhile on earth, Neil Armstrong and team pass success criteria navigating and landing in lunar atmosphere using ‘hack’ 1/6th moon gravity simulation MVP. Genius!
- Apollo 11? #OneSmallStep
Phew. ~35 Launch MVPs, countless others on the ground—and there you have a lean moonshot. Literally.
It wasn’t cheap in time or in money, but it was iterative.
“Not everything can be solved in 3 months.”
So true. But with lean principles, NASA was able to increase their velocity of learning, run separate MVPs, minimize risk, and beat Soviets to a moon landing before the decade was out. Coming from behind.
The Russians with their ‘anti-lean’ approach? Well, they might have glanced over a risky assumption or two:
“According to Chaikin, Russia’s massive N1 moon rocket was never put on a test stand to see how its engines reacted together when firing. This led to a devastating explosion during a test launch.”
Ultimately, the Russians went 0 for 4 with N1 launches, never making the N1 successful.
Was there ever a time where de-risking with speed and efficient use of available resources was more relevant than the space race?!
The literal moonshots proved the viability of the underlying theories of lean in technology decades ago. Ambitious visions of AI and other categories of moonshot startups are fantastic. But the credit for our progress, and the products of tomorrow, will continue to build on these foundations.
