When The Lean Startup was recommended to me, it came with an argument attached. We need to go to market faster with every new idea, the person said, and this book explains why. That's usually how it arrives, as a case for speed: stop planning, build something small, get it out there.
It's a good book. It's also fifteen years old, and it was written for a world where building software took months and cost real money. That world ended in the last two years. A student can now produce a working product in an afternoon. So the fair question is whether the advice went with it, and in particular whether speed still counts as an advantage when everybody has it.
I went back through the book the way it gets passed around, as a handful of things it's supposed to tell you, and checked what happened to each one. Some expired. Some got stronger. And the best evidence says the book's most valuable lesson is the one nobody pitched to me: knowing when to stop.
Speed stopped being an advantage once AI made building cheap. What the evidence supports is the part of the book people skip: decide in advance what would prove you wrong, and stop when it does. That part is worth more now, not less.
01 · The bookWhat you're told when someone says go read it
Before checking what aged, it helps to be exact about what's being checked. The book people recommend and the book Eric Ries wrote overlap a lot, but they aren't the same, and the gap between them is where this piece ends up.
Ries published The Lean Startup in September 2011, and it grew out of a failure. At his startup IMVU, the first product took six months to build, and nobody wanted it. The method is his answer to that. It's a way of finding out whether anyone wants a thing before you spend six months building it. Half of it came from Steve Blank, his mentor, who had already worked out what he called customer development, the habit of going out to learn what customers actually need before building much of anything. Ries turned that into a method with a name, a vocabulary and a loop at its center.
The book was also a response to a drop in the cost of building. Cloud servers from Amazon, free open-source software and new, faster ways of running software teams had just made it far cheaper to build and test a product than it had been in the dot-com years, and the book is an argument about what to do with that. Keep that in mind, because the same thing has just happened again.
Its core idea fits in a sentence. A new business is a set of guesses about customers, so the job is to test the guesses cheaply and learn from what happens, rather than to carry out a plan. Ries's own phrase for it, which he repeated unchanged in May 2026, is that "learning is the unit of progress."
The five things it's supposed to tell you
Out in the world, that idea travels as five pieces of advice. Here they are the way people pass them on, each with what the book actually says.
- Build the smallest thing that works before anything else. That's the minimum viable product, the MVP. In the book an MVP is the smallest experiment that teaches you something real about customers, and Lean Startup Co., Ries's own company, says he never meant "minimum" as a measure of quality.
- Get it in front of customers fast. Shorten the cycle, and don't polish. The book does push speed, but toward something specific: a real customer's reaction, before you've spent six months on a product nobody wants, the way Ries did.
- Build, measure, learn, repeat. The loop is the method. It's the center of the book and the part Ries says still holds, and it's the part that drops out when the book gets summed up as a case for speed.
- Measure what you learned, not vanity. Sign-ups and press aren't progress; a tested guess is. The book calls the real thing validated learning, and warns against vanity metrics, numbers that go up and feel like progress without testing anything.
- Change direction when the evidence says so, and don't be precious about it. Pivot or persevere. The book is enthusiastic about changing direction, which it calls a pivot, but it pairs that with a fixed long-term vision, so what changes is the route, not the destination.
There's no newer edition
The first thing people ask, once they've decided to read it, is whether there's a newer version. There isn't.
The book has been in print unchanged since September 2011. No revised edition, no anniversary edition, not even a new introduction. The publisher lists a hardcover, an ebook and an audiobook, all with the same 2011 date. The paperback you can buy today is a 2017 reprint of the same pages.
Ries kept writing. He just wrote different books. The Startup Way, in 2017, carried the method into large companies. His newest, Incorruptible, came out in May 2026 and isn't about startups at all. It's about why successful companies go bad from the inside.
His own position on the old one is a clean split. The principles hold, he says, and the tactics were always tied to the economics of the year they were invented. I think that's fair. It's also a large concession, because almost every tactic in the 2011 book assumes building is slow and expensive, and that's the assumption that broke.
So the book never got corrected. The world around it did, and the timeline below puts the two side by side.
One bar for the book, the same pages from September 2011 to today. Under it, a dot for each thing that happened to the idea, placed by date.
Tap a dot for what happened and where it was written up, or the bar for the book.
the book, the same pages throughoutsomething that happened to the idea
How this figure was made
The twelve: the four trials and their two papers in Management Science and the Strategic Management Journal, Mollick in Harvard Business Review, TechCrunch, Stripe, Blank's two pieces, and Ries's book and podcast. Six dots carry a year only and sit at mid-year; the 2017 paperback is the tick on the bar, a reprint of the same pages; the bar ends at October 19, 2026, the day the sources were last opened. Every date is a publication date, so a dot marks when something was written up, not when the thinking changed. Drawn by the page from the JSON build_fifteen_years.py wrote.
Fifteen years of argument have been aimed at a book that never moved, which at least makes the five claims a fixed target. The rest of this piece takes them one at a time, starting with the only place any of them has been properly tested.
02 · The evidenceSomebody actually tested this
Most business advice is somebody's opinion with a story attached. You can't check it, so you take it or leave it depending on how much you trust the person telling it. People have argued about this book for fifteen years in exactly that way, almost entirely on anecdote. For that reason, this section carries more weight than any other in the piece. It's the one place where some of the five claims were measured instead of argued.
Researchers took founders at the very start, split them into two groups at random, taught one group to run the business as a series of tests, and followed both groups to see what happened. They've now done it four times, with 759 businesses between them. The result wasn't the one I expected.
The main thing the method does isn't help people build faster. It helps them quit sooner. Founders taught the testing approach were more likely to drop their idea during the study, eleven more in every hundred than founders who weren't, and they did it a few weeks earlier. That's not what the book gets recommended for.
Eleven in a hundred sounds small until you see what it's eleven out of. In both groups, most founders kept going. The training moved the line by about one row.
Each group scaled to a hundred founders. A filled dot dropped the idea during the study; a hollow one kept going.
Tap a grid for its group, or the gap for the paper's estimate.
dropped the idea during the studykept going
How this figure was made
109 of 377 untrained firms (28.9%) and 152 of 382 trained (39.8%) dropped their idea during the study, Figure 1a, and the grids are drawn to those shares. The paper's estimate once trial and instructor are allowed for is 9.8 points (p = .001, Table 2). The four trials on their own: Milan 2016, 116 firms, 3.5 points, p = .647, which the authors call weak and not very precise; Milan 2017, 250 firms, 9.6, p = .044; Turin 2018, 132 firms, 15.8, p = .084; London 2019, 261 firms, 9.7, p = .035. The trials followed firms for up to 16 months, 9 in London, so a firm that quit later counts as keeping going. Drawn by the page from the JSON build_hundred_founders.py wrote.
How the trials worked
The first trial ran in Milan in 2016. Camuffo and colleagues recruited 116 businesses at the very beginning, through a course for people just starting one, and split them into two groups at random. The randomness is the point. If founders had chosen their own group, the keenest might all have picked the method, and any difference afterward would tell you about keenness, not the method. With chance deciding who went where, the only thing that differs between the groups in any consistent way is what they were taught.
Both groups got the same tools: talking to customers, a simple test version of the product, a one-page map of the business. The difference was what one group was taught to do with them. Treat the business as a set of guesses. Write down why you think it will work, turn that into claims that could turn out false, and decide what result would count against each one before you test it. The other group used the same tools however it saw fit. The first trial's paper spells out the difference. Trained founders were taught to set a threshold for each test before they ran it, such as the share of customer interviews that had to agree before a guess counted as supported, and the untrained group was not. The three later trials taught comparable material.
Then the researchers followed both groups for up to 16 months, recording what each business did: whether it changed direction, whether it made money, whether it dropped the idea.
One trial of 116 businesses is a start, not an answer, so they ran it three more times. Milan again in 2017, with 250 businesses. Turin in 2018, with 132. London in 2019, with 261, followed for nine months instead of 16. The first trial on its own was too small to be sure of the effect on quitting. Each of the three later ones pointed the same way, and pooled, across all 759 businesses, the result is clear. A replication across several cities is rare in research on how businesses get started, and it's the reason I trust this result more than anything else I read for this piece.
How much the training raised the share of founders who dropped their idea, trial by trial, in percentage points, with the range each p-value implies.
Tap a trial for its own result, or the pooled row for all four together.
the trial's own estimatethe range its p-value impliesall four pooled, the finding
How this figure was made
As printed in Table 2, the intervention coefficient with its robust p-value, standard errors clustered at intervention, instructor and trial: Milan, 2016, 116 firms, 0.035 (p = .647), which the authors call weak and not very precise; Milan, 2017, 250 firms, 0.096 (p = .044); Turin, 2018, 132 firms, 0.158 (p = .084); London, 2019, 261 firms, 0.097 (p = .035); all four pooled with dummies for trial and instructor, 759 firms, 0.098 (p = .001). The paper prints no standard errors or confidence intervals for this table and its supporting information was not obtainable, so each range is implied by the printed p-value under a normal approximation: the standard error is the estimate divided by the normal quantile at 1 minus p over 2, and the range is the estimate plus or minus 1.96 standard errors (Altman and Bland, "How to obtain the confidence interval from a P value," BMJ 343:d2090, 2011). They are not the paper's own intervals, and a p-value printed to three places moves either end of a range by at most 0.3 points. Firms were followed for up to 16 months, 9 in London. These are regression estimates, not counts, so they cannot be read against the hundred founders' dots. Turin's p is above .05 and the first trial's range crosses zero, so the figure says the trials pointed the same way, never that each one replicated. Drawn by the page from the JSON build_four_trials.py wrote.
Why deciding first makes you quit
Why would a habit of writing down guesses make founders drop their idea more often? The paper can show that they did, not what went on in their heads, so what follows is my reading. I think it's the order of operations. A founder who hasn't decided in advance what failure looks like meets each disappointing result fresh, and there's always a reason it doesn't count yet. The customers weren't quite the right ones. The test version was too rough. Next month will be different. A founder who wrote down beforehand what would count against the idea has nowhere to put those reasons. The result clears the bar or it doesn't.
The other finding fits that reading. Trained founders also earned somewhat more revenue on average, about €7,000 more over the study, an effect the authors themselves call small. They credit it to better choices about which ideas to keep and more focused changes of direction. Choosing which idea to keep is the same decision as choosing which to drop, seen from the other side.
Which brings me back to how the book was recommended to me. The argument was that we need to go to market faster with every new idea. The best evidence anyone has gathered on this method says its measurable benefit runs the other way. Founders who learned it stopped the wrong ideas sooner. The book gets used as permission to start building immediately. On this evidence, its real value is permission to stop.
The bit about pivoting
"Pivot" is the book's word for changing direction when the evidence says your current idea is wrong. The trials counted the big changes, what the 2024 paper calls radical pivots. The book is enthusiastic about pivoting. Startup culture turned it into a personality trait, summed up in the slogan "pivot early, pivot often."
The first Milan trial seemed to back the culture up. Trained founders changed direction more, and in that paper the effect looked simple: the method meant more pivoting. With 759 businesses, the 2024 paper could see something one trial of 116 couldn't, and the authors present it as a correction to their own earlier result. The picture changed shape.
Trained founders were 8.3 points more likely to change direction exactly once, and 3.7 points less likely to change it more than twice. On changing it twice, there was no clear difference. The chart below shows the counts behind those estimates, every business in both groups, the ones that dropped their idea included.
How this figure was made
Counts read from Figure 1a on October 20, 2026, every firm in its group counted once, the ones that dropped the idea included: trained, 215, 107, 43 and 17 of 382; untrained, 231, 74, 40 and 32 of 377. The bars are those raw shares. The paper's estimates, from its text, its Figure 2 and Table 5: 8.3 points more likely to change direction once (p = .003), 3.7 points less likely to change it more than twice (p = .001), and no precise effect on twice. The first trial's own model of this did not converge (footnote 6). Drawn by tools/chart.py from pivot-shape.json.
Most founders in both groups never changed direction at all, 215 of 382 trained and 231 of 377 untrained. The difference is at the edges. Among the trained, 28.0% changed direction once, against 19.6% of the untrained. Only 4.5% of the trained changed it three or more times, against 8.5% of the untrained. So the method didn't turn founders into serial pivoters. It produced one deliberate change instead of several restless ones.
It's tempting to go one step further and say changing direction once is the winning move. The paper does report that among the trained founders, those who changed direction once did better than those who changed it more often. But that's a pattern inside one group, in the paper's appendix, not something the random split tested, so hold it loosely. What the trials do show is what the training produced, and it makes a better rule of thumb than the slogan. Change direction when you've learned something real. Once may be all it takes. By the third time, be suspicious of yourself.
What the trials don't tell you
Two limits come with all of this. The trials taught the method in a classroom, not from a book, and the method tilts against the most original ideas.
Every one of these trials ran inside an accelerator, with instructors teaching the method and a group of other founders reinforcing it. That isn't the same as one person reading a book alone. The evidence supports the method taught and enforced. It says much less about the copy on your shelf. No study found the method hurts outcomes, and none has tested the book in the wild.
The method's sharpest critic, Ethan Mollick at Wharton, accepts the testing loop and points to a bias in it. New ideas are often disliked by customers at first, so early validation is easier to win for an incremental product than for a genuinely new one. The method doesn't fail at random. It fails in a direction, against the most original ideas. His fix is to start from your own bet about why you'll win, something early customers may not be able to see yet, and design each test to check that bet, instead of letting early reactions pick the idea for you.
Ted Ladd, writing in Harvard Business Review in 2016, reached a similar place from another direction. Studying about 250 teams in an American cleantech accelerator program over 10 years, he found that the lean approach can work, but that a strong strategy mattered more than a large number of market tests. Put the two critics together and they make the same point, and it fits the trials. A test is only as useful as the guess behind it. The trained founders were taught to know what each test was for before they ran it.
03 · The MVPThe MVP had two jobs. One broke.
The minimum viable product is what people mean when they say they're running lean, and it's the claim that changed most in the last two years. Some say AI killed it. Some say nothing changed. Both are partly right, because an MVP used to do two jobs at once, and AI broke only one of them.
Start with what an MVP is. It's the smallest version of your idea that you can put in front of real customers and learn something from. Sometimes that's a stripped-down product. Often it isn't a product at all. One well-known early example is Dropbox's, a video explaining the product, which drew sign-ups before the product itself was built. What makes something an MVP is that real customers react to it and you learn from the reaction. Its size and finish are beside the point.
The first job was proof that you'd done the thinking. The second was the fastest way to learn from real customers. Cheap building broke the first and made the second better than it has ever been.
The proof job
Building even a small thing used to cost weeks, so if you'd built one, it showed you'd understood a customer well enough to know what to make. The effort was the evidence. A teacher looking at a student team's working MVP, or an investor looking at a founder's, could take it as a sign that somebody had done the thinking.
Steve Blank is the person best placed to say what happened to that job. He developed the customer research half of the method, the half Ries learned from him, and he has taught it at Stanford for 16 years, with the MVP as one of its central teaching tools. In July 2026 he said his own central teaching tool no longer works.
An MVP is now equivalent to a PowerPoint slide. Steve Blank · Poets & Quants, July 2026
His point is simple. When a student can produce a working product in an afternoon, building one stops proving anything. It costs nothing, so it demonstrates nothing. A slide shows that you can describe an idea. A working product now shows about the same.
He also watched what it did to his students. Teams began skipping the research step entirely and jumping straight to building, because building was now the easy part. The order the method depends on, find out first and build second, got turned around. And when his team tried using AI to generate customer interviews instead of talking to people, about half of the AI-generated interviews turned out to be made up.
That last finding cuts in a direction worth noticing. It isn't an argument against these tools. It's an argument for still going and talking to actual human beings, which is exactly what the method said in the first place. Blank isn't giving up on the method either. He's rewriting his course around what changed, and he expects that to take a year or two. Lean startup took about 25 years to reach the mainstream the first time.
The learning job
The second job was learning, and it's the one people miss when they say the MVP is dead. An MVP was also the fastest way to put the real thing in front of real customers, watch what they do with it, and make it better from what you see. A slide can't do that. It can show a customer what you mean. It can't show you where they get stuck on a Tuesday afternoon, what they ignore, or what they come back for.
This is the loop at the center of the book, and it's worth spelling out, because the book's reputation leans so hard on the first step. Ries calls it build, measure, learn. You build something small that carries one of your guesses about customers. You measure what real customers do with it, which isn't the same as what they say about it. You learn whether the guess was right, and decide whether to keep going or change direction. Then you go round again with a better guess. The product improves because each loop starts from what the last one taught you, not from what you assumed at the beginning.
Cheap building didn't break this job. It made it faster and cheaper than it has ever been. When the build step took weeks, so did every loop. Now the build step can take an afternoon, and a founder can put a working thing in front of real customers on Monday and a better one on Friday. If you read the book as a manual for running that loop, the last two years are the best thing that ever happened to it.
Speed did change one thing about the loop. A rough first release in 2011 read as early. Now that competing products are polished and the tools to polish yours are cheap, the same release can read as broken, and people remember. A 2018 piece in Quartz described an MVP hangover, a rough launch whose reputation outlives the rough product. So "don't polish" has aged worse than "get it in front of customers." The loop still wants real customers early. It forgives less of what you show them.
That raises a fair challenge to the word "minimum" itself. If building is nearly free, why build the smallest thing? The venture capital firm a16z, in a piece called "Notes on AI Apps in 2026," argues that in the AI era "fat startups win." A fat startup, in its telling, delivers the whole result a customer wants, combining the software, the data, any hardware and the human work into one product, instead of the smallest slice that can be tested. It's the strongest challenge I found, and it gets one thing right. Keeping things small was partly a way of rationing scarce engineering, and the scarcity is gone. But I don't think "minimum" was ever about the engineering budget. It was about how much you commit before you know. That hasn't changed. Building more before you've learned anything is still a bet, whatever it costs to place.
The trap
There's a catch in the good news, and the book saw it coming. A loop is only as good as what it learns from. Run it on friendly feedback, from people who like you or from a burst of early attention, and it will tell you you're winning. That's what the book means by vanity metrics. The warning is from 2011. What's new is that it's cheaper to fool yourself now, and faster. You can produce something impressive in a weekend, show it to friendly people, get warm responses, and mistake that for demand before the month is out.
Ben Yoskovitz, who co-wrote Lean Analytics, makes the same point about startups built with AI. His answer to whether AI killed the lean startup is no, it speeds it up. But he warns that "speed without direction is just chaos," and he reports that AI-era startups are showing high early churn, customers who leave soon after they arrive. It looks like product-market fit, the point where a product has found people who need it, but it's driven by novelty rather than need. That's the 2011 failure mode, running faster.
So the MVP had two jobs. The proof job broke, and it isn't coming back. A built thing no longer shows that you understand anybody. The learning job is cheaper than it has ever been, as long as what you learn from is real customers doing real things. Which moves the hard part of the loop from the build to the learning.
04 · The bottleneckThe expensive part moved
None of this makes the book wrong. The book was written in answer to one drop in the cost of building, and this is a second one. What changed is which step of the loop is hard, and that change is what ties the trials in section 02 to the loop in section 03.
In 2011, building was the bottleneck, so the whole method was designed to spend as little on building as possible. That constraint has largely lifted. About a quarter of the companies in Y Combinator's Winter 2025 batch, the group of startups the Silicon Valley accelerator took in that winter, had code that was roughly 95% written by AI. Jared Friedman, a managing partner there, said that a year earlier those companies would have built their products from scratch.
When building gets cheap, the difficulty moves to the parts that were always harder anyway.
- Knowing what to build. That still means talking to people who might pay you, and hearing what they actually say rather than what you hoped.
- Getting anyone to find out you exist. Distribution was the real constraint long before any of this, and it's the point the sources I read for this piece made most often.
- Judgment. These tools produce plausible work quickly, and deciding whether it's any good hasn't been automated. Diana Hu, a partner at Y Combinator, says you need enough taste and training to tell good work from bad.
Ries draws the line in the same place. In May 2026 he said AI does speed up the build and measure steps of the loop, and does nothing for the third. "Learning is still a human job," he said, and a founder who hands it to a model gets average work back and ends up moving slower for it.
Building got cheap. Learning didn't. And learning is exactly where the trials found the benefit. Both groups had the same tools, test versions of the product included, so the difference between them was never the building. It was how they learned from what they built: guesses written down, a bar each one had to clear, and a decision made before the result came in. The part of the method that got cheap is the part both groups shared. The part that didn't get cheap is the part that separated them. That's why I think the method got more valuable in the last two years, not less. Everyone can build now. Not everyone decides in advance what would make them stop.
Building got cheap. Learning didn't.
One number keeps me honest about how uneven this is. Stripe looked at solo founders who set up their companies through its Atlas service, and found solo founding at an all-time high. For the typical company started in 2025, revenue in its first six months was 23% lower than for companies started the year before. For the top tenth, it was 19% higher. More people are doing it, and the results are pulling further apart. Whatever separates the top tenth from the middle, it isn't access to building. Everyone has that now.
05 · The mapFive books, in the order I'd read them
Nothing replaced The Lean Startup. It split into specialties, which is why nobody can hand you a single title. These five cover it.
- The Mom Test, Rob Fitzpatrick, 2013. How to talk to customers without collecting compliments instead of facts. The most immediately useful book on this list, and short. A revised edition is on the way.
- Continuous Discovery Habits, Teresa Torres, 2021. The modern replacement for the research half of the method. It turns customer learning into a small weekly habit rather than a phase you finish.
- Testing Business Ideas, David Bland and Alex Osterwalder, 2019. A catalog of experiments you can actually run, sorted by what each one costs and how much it proves. The practical manual the original never included.
- Running Lean, Ash Maurya, third edition, 2022. The step-by-step version, best if you're on your own and want a weekly routine rather than a philosophy.
- Me, My Customer, and AI, Henrik Werdelin and Nicholas Thorne, 2025. The closest thing to a rewrite for right now. Its argument matches where this piece landed. When building is nearly free, how well you know your customer is what's left.
06 · The verdictsThe five claims, marked up
Here are the five claims again, the way they get passed around, with what fifteen years did to each.
| The claim | What changed | Verdict |
|---|---|---|
| Build the smallest thing first | Its proof job broke; its learning job got cheaper | Changed |
| Get it out fast | Everyone is fast now; still do it | Expired |
| Build, measure, learn | Building got cheap; learning didn't | Holds |
| Measure learning, not vanity | Fooling yourself got cheaper too | Stronger |
| Pivot or persevere | Once, deliberately, not again and again | Reshaped |
Read down the last column and the pattern is plain. The claims about building fast lost their edge once everyone could build fast. The MVP kept its learning job and lost its proof job. The loop held, with the hard part moved from building to learning. The claims about judgment, what counts as progress and when to change course, got stronger. The book was always about two things: moving fast and knowing when to stop. People recommend it for the first. The evidence is behind the second.
The same rule works on something you've already started. Steve Blank put it as a question in March 2026, for founders who began more than two years ago: what would you build if you were starting today, with today's tools, in today's market? Sunk cost, he argues, is what keeps people defending an idea that has gone stale.
If the answer is different from what you're building now, that's worth a quiet afternoon. And if someone hands you The Lean Startup as an argument for going faster, read it anyway. Then do the part they skipped. Before you build the next thing, write down what result would make you stop.
SourcesWhere all of this comes from
Researched in August 2026 in four parallel passes using AI research assistants, then a second, separate round that checked each claim against its source. Two attribution errors were caught and fixed in that round. A third check in October 2026, against the trial papers and the original articles, corrected five more claims, and for this edition the counts of who changed direction were read from the 2024 paper's own figure. I decided what stayed. Rewritten for the web in October 2026.
- Eric Ries, The Lean Startup, Crown Business, September 13, 2011, the source for the IMVU and Dropbox stories; publisher listing. penguinrandomhouse.com
- Eric Ries with Chris Dixon, "Missing the Bullseye Made the Lean Startup," Founder Stories, TechCrunch, September 23, 2011, on IMVU's first product going to customers in six months. techcrunch.com
- Eric Ries, The Startup Way, Currency, October 17, 2017, publisher listing. penguinrandomhouse.com
- Incorruptible, Eric Ries, Authors Equity, May 26, 2026. simonandschuster.com
- Eric Ries on what holds up and what doesn't, Startups for the Rest of Us, episode 834, May 26, 2026. startupsfortherestofus.com
- Lean Startup Co., its explainer on the minimum viable product. leanstartup.co
- Camuffo, Gambardella, Messinese, Novelli, Paolucci and Spina, "A scientific approach to entrepreneurial decision-making: Large-scale replication and extension," Strategic Management Journal 45(6), 2024. Open access. sms.onlinelibrary.wiley.com
- Camuffo, Cordova, Gambardella and Spina, the original randomized trial, Management Science 66(2), 2020. pubsonline.informs.org
- Ethan Mollick, "What the Lean Startup Method Gets Right and Wrong," Harvard Business Review, October 21, 2019. hbr.org
- Ted Ladd, "The Limits of the Lean Startup Method," Harvard Business Review, March 7, 2016. hbr.org
- Eric Ries, "How DropBox Started As A Minimal Viable Product," TechCrunch, October 19, 2011, adapted from The Lean Startup. techcrunch.com
- "The Man Who Disrupted Entrepreneurship Education Says AI Just Disrupted Him," Poets & Quants, July 5, 2026. poetsandquants.com
- On the MVP hangover, Quartz, November 2018. qz.com
- a16z, "Notes on AI Apps in 2026." a16z.com
- Ben Yoskovitz, "Did AI Kill the Lean Startup?", July 8, 2025. focusedchaos.co
- "A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated," TechCrunch, March 6, 2025, with Jared Friedman and Diana Hu, from Y Combinator's video "Vibe Coding Is the Future." techcrunch.com
- Stripe, "Top solo founder traits," May 28, 2026, from Stripe Atlas data. stripe.com
- Steve Blank, "Your Startup Is Probably Dead On Arrival," March 17, 2026. steveblank.substack.com
Related notes: "Nobody is lying to you," on what customer interviews can and can't tell you, and "You're only hearing from the people who stayed," on why every early signal flatters you.