Steve BlankModify

2026-06-16 21:00:57

We just finished the 16th annual Lean LaunchPad class at Stanford.

In those 16 years, the class has gone from a radical idea – that the Lean method could provide a more productive framework for new startups – to something that everyone agrees is a way to build new startups.

The class had gotten so popular that in 2021 we started teaching it in both the winter and spring sessions.

During the 2026 spring quarter the eight teams spoke to 978 potential customers, beneficiaries and regulators. Most students spent 15-20 hours a week on the class, about double that of a normal class.

This Class Launched a Revolution in Teaching Entreprenurship – AI Is Changing It
This class was designed to break out of “how to write a business plan” as the capstone of entrepreneurial education. A business plan assumed that all startups needed to do was to write a plan, raise money and then execute the plan. We overturned that orthodoxy when we pointed out that while existing organizations execute business models, startups search for them. And that a startup was a temporary organization designed to search for a repeatable and scaleable business model. This class was designed to teach startups how to search for a business model. I’ll summarize some of the learnings about the use of AI at the end of this post.

Several government-funded programs have adopted this class at scale. The first was in 2011 when we turned this syllabus into the curriculum for the National Science Foundation I-Corps. Errol Arkilic, the then head of commercialization at the National Science Foundation, adopted the class saying, “You’ve developed the scientific method for startups, using the Business Model Canvas as the laboratory notebook.” Now in its second decade and in 100+ universities, I-Corps has become a standard for science commercialization at the NSF, National Institutes of Health and the Department of Energy –  training 3,251 teams and launching 1,400+ startups to date.

Team Office Hours

If you can’t see the Team Office Hours video click here

If you can’t see the Team Office hours slides click here

If you can’t see a demo of the Team Office Hours app click here

Design of This Class
While the Lean LaunchPad students are experiencing what appears to them to be a fully hands-on, experiential class, it’s a carefully designed illusion. In fact, it’s highly structured. The syllabus has been designed so that we are offering continual implicit guidance, structure, and repetition. This is a critical distinction between our class and an open-ended experiential class.

Guidance, Direction and Structure – For example, students start the class with their own initial guidance – they believe they have an idea for a product or service (Lean LaunchPad/I-Corps) or have been given a clear real-world problem (Hacking for Defense). Coming into the class, students believe their goal is to validate their commercialization or deployment hypotheses. (The teaching team knows that over the course of the class, students will discover that most of their initial hypotheses are incorrect.)

Team Izhaar

If you can’t see the Team Izhaar click here

If you can’t see the Team Izhaar presentation click here

Team Trained on Me

If you can’t see the Team Trained on Me video click here

If you can’t see the Team Trained on Me presentation click here

The Business Model Canvas
The business model / mission model canvas offers students guidance, explicit direction, and structure. First, the canvas offers a complete, visual roadmap of all the hypotheses they will need to test over the entire class. Second, the canvas helps the students goal-seek by visualizing what an optimal endpoint would look like – finding product/market fit. Finally, the canvas provides students with a map of what they learn week-to-week through their customer discovery work. I can’t overemphasize the important role of the canvas. Unlike an incubator or accelerator with no frame, the canvas acts as the connective tissue – the frame – that students can fall back on if they get lost or confused. It allows us to teach the theory of how to turn an idea, need, or problem into commercial practice, week by week a piece at a time.

Team Artemis

If you can’t see the Team Artemis video click here

If you can’t see the Team Artemis presentation click here

Lean LaunchPad Tools
The tools for customer discovery (videos, sample experiments, etc.) offer guidance and structure for students to work outside the classroom. The explicit goal of 10-15 customer interviews a week along with the requirement for building a continual series of minimal viable products provides metrics that track the team’s progress. The mandatory office hours with the instructors and support from mentors provide additional guidance and structure.

Team Remainder

If you can’t see the Team Remainder video click here


If you can’t see the Team Remainder slides click here

Team Microprint

If you can’t see the Team Microprint video click here

If you can’t see the Team Microprint slides click here

Team Vital Health

If you can’t see the team Vital Health video click here

If you can’t see the team Vital Health presentation click here

Team Nimbus

If you can’t see the Team Nimbus video click here

If you can’t see the Team Nimbus presentation click here

AI In the Classroom

AI Embedded in the Class
This was the first year where all teams used AI to help create their business model canvas, build working MVPs in hours, generate customer questions, analyze and summarizing interviews.

AI has had some obvious and not so obvious impacts on our class.
First, here’s a summary of how our students used AI in both classes I taught this quarter.

If you can’t see the AI Use In Class slide click here

AI Tools Used
Claude + Granola – were the AI tools used by everyone.
Large Language Models Used
– Claude, Claude Code, Claude Chrome extension, Claude Cowork, Claude Design
– ChatGPT
– Gemini
Note taking
– Granola
– Twinmind
Presentations
– Perplexity
Building prototypes
– Replit
– Lovable
Creating Synthetic Users
– Listen Labs
– Viewpoints AI
Summarizing Research
– Google NotebookLM
– Notion + G Suite (not strictly AI, but used as part of AI workflows)
Other
– Ultralytics YOLOv8 (used by the SwarmShield H4D team for drone detection/tracking MVP)

AI Classroom Usage
Three of our students did a tutorial of how they used AI in the classroom.

If you can’t see the AI Classroom Usage tutorial click here

Impact of AI in the Classroom
The obvious and positive changes of AI were that teams were able to do customer discovery more efficiently. The not so obvious change was that creating products rapidly allowed teams to make bad ideas go faster. In the past, MVPs were a sign of a teams technical competence, but now spinning up something in hours that previously took weeks, means that an MVP is no longer evidence of critical thinking and hypothesis testing.

This meant student learning was unbalanced. A finished-looking product felt like success. Students confused a polished deliverable with the need to deeply understand the needs of all the stakeholders, as well as the need for Customer Validation. Team understanding was less nuanced. There was less depth uniformly across the teams about the problem they were solving and understanding customer needs. In this class it wasn’t the AI that was hallucinating –  it was teams. They pivoted late as they assumed that a polished product meant product/market fit.

Going forward we’ll have students come into class with a prototype but next time accompanied by the explicit hypotheses and experiments they’ll use to validate whether the prototype solved an actual problem.

On the other hand, students built some amazing Claude Skills and Gemini Gems. They were tons of untapped opportunities to build digital twins or test 10’s or 100’s of apps simultaneously.

More about this in a separate blog post.

It Takes A Village
While I authored this blog post, this class is a team project. The secret sauce of the success of Lean LaunchPad at Stanford is the extraordinary group of dedicated volunteers supporting our students in so many critical ways.

The teaching team consisted of myself and:

• Steve Weinstein, partner at America’s Frontier Fund, 30-year veteran of Silicon Valley technology companies and Hollywood media companies. Steve was CEO of MovieLabs, the joint R&D lab of the major motion picture studios.
• Lee Redden – CTO and co-founder of Blue River Technology (acquired by John Deere) who was a student in the first Lean LaunchPad class 14 years ago! I wrote a post about Lee’s journey here.
• Jennifer Carolan, Co-Founder, Partner at Reach Capital the leading education VC and author of the Hacking for Education class.

Our teaching assistants this year were: Roya Meykadeh, Aditi Mahajan, Alina Hu.

The teams were assisted by mentors: David Kopp, Mitch Singer, Pradeep Jotwani, Dave Epstein, Anil Kamath, Bobby Mukherjee, Rekha Pai, Venkat Krisnamurthy and mentor team coordinator Todd Basche.

2026-06-09 21:00:23

Incorruptible: Why Good Companies Go Bad… and How Great Companies Stay Great, by Eric Ries.

Every once in a while a book comes along that doesn’t just change your tactical thinking, but makes you see the world in a different way. Reading this book is like taking the red pill in the Matrix. 

Some will read this book, think it’s interesting and then get back to figuring out to how get their next big round of funding or how to deal with AI disruption in their large company.

But what they’ll miss is that this is the book that will rebuild the corporate and startup world after the next financial crash.

That’s exactly what happened when Eric’s work, Alexander Osterwald’s work and mine created the Lean Startup. Lean was a neat theory until the dot com bubble crashed and investors (those who still had jobs,) were hiding under their desks. Only then were startups and VCs amenable to a radically new idea about how to build new ventures.

The same will happen here.

Part 1 is a great tutorial on how corporations morphed from serving the people to serving only its shareholders. Worth reading deeply.

Part 2 is the nuts and bolts about what to do about it. How to build companies with governance structures that endure.

Part 3 is about the network effect of building this class of companies. It also has a chapter that buries the lead. Eric had the core ideas for the concepts in the book in 2019 when he started the Long Term Stock Exchange (LTSE). Never heard of it? Welcome to the club. Its core diagnosis was absolutely right: public markets reward short-termism. LTSE tried to solve a governance problem with an exchange listing. In hindsight it took all the accumulated wisdom in this book to understand what it will take to make meaningful change.

Its time may come and this book may be the catalyst.

This book will possibly be more important than the Lean Startup ever was – for you, your company and society as a whole. Read it.

2026-06-08 21:00:15

We just wrapped up our Hacking for Defense class at Stanford.

This was the 11th year we’ve taught Hacking for Defense, and the impact of asymmetric warfare, (drones, off-the-shelf technologies, etc.,) disruptive technologies (AI, commercial access to space) and a startup friendly DoW acquisition system – make it feel like a much different class than the previous classes.

---

Hacking for Defense is now in 70 universities, including 20+ in the UK – and this year in Poland and Germany – with teams of students working to understand and help solve national security problems.

This year’s problems came from the Navy, Air Force, Army Research Lab, Defense Innovation Unit, IQT, and NASA.

This quarter 9 teams of 42 students at Stanford collectively interviewed 1132 beneficiaries, stakeholders, requirements writers, program managers, industry partners, etc. – while simultaneously building a series of AI-driven minimal viable products and developing a path to deployment.

We opened this year’s final presentations session with a great talk about AI and defense – past, present and future – from (Ret) LTG Jack Shanahan. Jack was the Director of the DoD Joint Artificial Intelligence Center (JAIC). Watching his talk is a worthwhile use of your time.

If you can’t see Jack Shanahan’s video click here

During the quarter guest speakers in the class included Owen West – director of the Defense Innovation Unit, Mike Brown – partner at Shield Capital, (Ret) LTG Joseph McGee recent head of the Joint Staff J5 (strategy, plans, and policy,) and Hon Marise Payne Australia’s Minister for Foreign Affairs.

“Lessons Learned” Presentations
Each of the eight teams gave a final “Lessons Learned” presentation along with a 2-minute video to provide context about their problem. Unlike traditional demo days where teams show off, “Here’s how smart I am, and isn’t this a great product, please give me money,” the Lessons Learned presentations tell the story of each team’s 10-week journey and hard-won learning and discovery. It’s a roller coaster narrative describing what happens when they discover that everything they thought they knew on day one was wrong and how they eventually got it right.

While all the teams used the Mission Model Canvas, Customer Development and AI tools to build Minimal Viable Products, each of their journeys was unique.

This year we had the teams add two new slides at the end of their presentation: 1) tell us which AI tools they used, and 2) their estimate of progress on the Technology Readiness Level and Investment Readiness Level.

Here’s how they did it and what they delivered.

Team Noctua – Started with a problem that said, “Special operators can’t detect drones passively, without exposing their position.” They ended up understanding that a larger problem was, “Dismounted troops and base defenders lack a passive means to provide early warning detection of all types of drones, including those that are RF silent.

If you can’t see the Noctura video click here

If you can’t see the Noctura presentation click here

These are “Wicked” Problems
Wicked problems refer to really complex problems, ones with multiple moving parts, where the solution isn’t obvious and lacks a definitive formula. Most problems our Hacking For Defense students work on fall into this category. They are often ambiguous. They start with a problem from a sponsor, and not only is the solution unclear but figuring out how to acquire and deploy it is also complex. Most often students find that in hindsight the problem was a symptom of a more interesting and complex problem – and that Acquisition in the Dept of War is unlike anything in the commercial world.

Instead of admiring problems from inside a classroom our students get of the building and learn, discovery and iterate.

The figure shows the types of problems Hacking for Defense students encounter, with the most common ones shaded.

Team SwarmShield – The initial problem was framed as, the cost of using expensive interceptors to shoot down cheap drones. By the end of the class the Team realized the problem was building terminal guidance that lets a cheap, throwaway drone find and hit an attacker at night.

If you can’t see the SwarmShield summary video click here.

If you can’t see the SwarmShield presentation click here

Department of War Directory – This year the students had access to a Department of War Directory – essentially a phonebook of  ~5,700 names of “Who buys in the Dept of War?” The directory includes a tutorial on how the DoW buys and the various acquisition and funding processes and programs that exist for startups. It provides details on how to sell to the DoW and where the Program Acquistion Officers (PAEs) fit into that process.

 

Team Weapons Without Wait – The initial problem for this team was “Retool and scale defense manufacturing capacity to replenish critical munitions at the pace required by sustained, high-intensity conflicts.”  This is what I call a “boil the ocean” problem” – big and vast – and vague. By class end the team realized what was rapidly achievable (and needed) was affordable, certified munitions for small drones produced at the point-of-need.

If you can’t see the Weapons Without Wait video click here

If you can’t see the Weapons Without Wait presentation click here

It Started With An Idea
Hacking for Defense is built on the same methodology as Lean LaunchPad class I created at Stanford in 2011. It was adopted by the National Science Foundation (NSF) as the NSF I-Corps (Innovation Corps) to train Principal Investigators who wanted an SBIR grant. Now in its second decade and in 100+ universities, I-Corps has become a standard for science commercialization at the NSF, National Institutes of Health and the Department of Energy –  training 3,251 teams and launching 1,400+ startups to date.

Team IonX – IonX also started with a “boil the ocean” problem – The US needs a secure rare earth supply chain. They ended up with a problem more tangible and deliverable – Mineral processors across markets can’t identify and test better chemical reagent schemes.

If you can’t see the IonX video click here

If you can’t see the IonX presentation click here

Origins Of Hacking For Defense
In 2016, brainstorming with Pete Newell of BMNT and Joe Felter at Stanford, we observed that students in our research universities had little connection to the problems their government was trying to solve. We realized the same Lean LaunchPad/I-Corps class would provide a framework to do so. That year we launched both Hacking for Defense and Hacking for Diplomacy (with Professor Jeremy Weinstein and the State Department) at Stanford.

Team Cheese on the Moon – Started with a mandate to search for mineral deposits on the moon. By class end they realized that to do that lunar missions need to know what’s on and under the moon not only to mine, but to land.

If you can’t see the Cheese on the Moon video click here

If you can’t see the Cheese on the Moon presentation click here

Goals for Hacking for Defense
A decade ago, our goal for the class was to teach students Lean Innovation methods while they engaged in national public service. We wanted to familiarize students with the military as a profession and help them better understand its expertise, and its role in society. We also hoped the class would show our sponsors a methodology that builds problem understanding before writing requirements.

The class still does all this, but now that the DoW is buying from startups and defense venture capital is abundant, the class has turned into a national security incubator. Most of our teams form defense companies.

Team Fuel Forge started with the problem that combat units need to generate power and fuel locally. They ended with a more interesting observation that they could build networked, on-site hydrogen nodes to fuel drones in forward, contested environments where resupply is at risk,

If you can’t see the Fuel Forge video click here



If you can’t see the Fuel Forge presentation click here

Go-to-Market/Deployment Strategies
The initial goal of the teams is to ensure they understand the problem. The next step is to see if they can find mission/solution fit (the DoW equivalent of commercial product/market fit.) But most importantly, the class teaches the teams about the difficult and complex path of getting a solution in the hands of a warfighter/beneficiary. While the DoW has made tremendous strides in reforming how and who they buy from, students still need to know: Who writes the requirement? What’s an OTA? What’s color of money? What’s a Program Manager? Who owns the current contract?

Team Luminarch – Started with Tactical units lack the capability to visualize, manage, and adapt to the electromagnetic spectrum in real time. They ended with Tactical units lack low-cost, attritable RF sensors that can be deployed at scale, limiting their ability to detect threats, manage signatures, and communicate.

If you can’t see the Luminarch video click here

If you can’t see the Luminarch presentation click here

Team Tessellate– Started with the observation that drone missions don’t scale. And ended by realizing what’s missing is US multi-drone doctrine doesn’t exist and current drone warfare changes are happening faster than the software lifecycle.

If you can’t see the Tessellate video click here



If you can’t see the Tessellate presentation click here

AI In the Class Room
AI has had some obvious and not so obvious impacts on our class.
First, here’s a summary of how our students used AI in both classes I taught this quarter.

If you can’t see the AI Use In Class slide click here

If you can’t see the AI Rap Video click here

AI Tools Used
Claude + Granola – were the AI tools used by everyone.
Large Language Models Used
– Claude, Claude Code, Claude Chrome extension, Claude Cowork, Claude Design
– ChatGPT
– Gemini
Note taking
– Granola
– Twinmind
Presentations
– Perplexity
Building prototypes
– Replit
– Lovable
Creating Synthetic Users
– Listen Labs
– Viewpoints AI
Summarizing Research
– Google NotebookLM
– Notion + G Suite (not strictly AI, but used as part of AI workflows)
Other
– Ultralytics YOLOv8 (used by the SwarmShield H4D team for drone detection/tracking MVP)

The obvious and positive changes of AI were that teams were able to do customer discovery more efficiently. The not so obvious change was that creating products rapidly allowed teams to make bad ideas go faster.

In the past, MVPs were a sign of a teams technical competence, but now spinning up something in hours that previously took weeks, means that an MVP is no longer evidence of critical thinking and hypothesis testing.

This meant student learning was unbalanced. A finished-looking product felt like success. Students confused a polished deliverable with the need to deeply understand the needs of all the stakeholders, as well as the need for Customer Validation. For defense startups that means understanding a path to a CRADA, or to a research or production OTA. We needed to slow the teams down. Going forward we’ll have students come into class with a prototype but next time accompanied by the explicit hypotheses and experiments they’ll use to validate whether the prototype solved an actual problem.

More about this in a separate blog post.

It Takes A Village
While I authored this blog post, this class is a team project. The secret sauce of the success of Hacking for Defense at Stanford is the extraordinary group of dedicated volunteers supporting our students in so many critical ways.

The teaching team consisted of myself and:

• Pete Newell, retired Army Colonel and ex Director of the Army’s Rapid Equipping Force, now CEO of BMNT.
• Joe Felter, retired Army Special Forces Colonel; and former deputy assistant secretary of defense for South and Southeast Asia, and Oceania; currently Director of the Gordian Knot Center for National Security Innovation at Stanford which we co-founded in 2021.
• Steve Weinstein, partner at America’s Frontier Fund, 30-year veteran of Silicon Valley technology companies and Hollywood media companies. Steve was CEO of MovieLabs, the joint R&D lab of all the major motion picture studios.
• Chris Moran, Executive Director and General Manager of Lockheed Martin Ventures; the venture capital investment arm of Lockheed Martin.
• Jeff Decker, a Stanford researcher focusing on dual-use research. Jeff served in the U.S. Army as a special operations light infantry squad leader in Iraq and Afghanistan.
• Jillian Manus, a venture partner at Shield Capital and Senior U.S Venture Advisor for the European Innovation Council

Our teaching assistants this year were: Evan John Twarog, Varsha Saravanan, Breno Casciello, and Luke Andrews.

34 Sponsors, Business and National Security Mentors
The teams were assisted by sponsors and mentors.

National Security Mentors helped students who came into the class with no knowledge of the Department of War, understand the complexity, intricacies and nuances of those organizations: Katie Tobin, Kelly McGannon, Rachel Costello, Henning Heine, Josh Edwards, Marco Romani, Tom Schmitz, David Vernal, Rich Lawson, Dan Ruttenber, Ashley Perry, Sophia Vahanvaty, Rick Lu, Chris O’Connor

Business Mentors helped the teams understand if their solutions could be a commercially successful business: Doug Seiche, Jeremy Schoos, Adam Waters,, Matt Croce, Isobel Porteous, Eric Byler, Diane Schrader, Donnie Hasseltine, Mark McVay.

Sponsoring Organizations: Gordian Knot Center for National Security Innovation, Common Mission Project, Lockheed Martin, Boeing, BMNT, Defense Innovation Unit.

Thanks to all!

2026-04-28 21:00:48

This article previously appeared in The Cipher Brief.

For a decade the cybersecurity community was predicting a cyber apocalypse tied to a single event –  the day a Cryptographically Relevant Quantum Computer could run Shor’s algorithm and break the public-key cryptography systems most of the internet runs on.

We braced for a one-time shock we would absorb and adapt to. NIST (the National Institute for Standards and Technology) has already published standards for the first set of post-quantum cryptography codes.

It’s possible that the first cybersecurity apocalypse may have come early. Anthropic Mythos now tilts the odds in the cybersecurity arms race in favor of attackers – and the math of why it tilts, and how long it stays tilted, is different from anything our institutions were built to handle.

In 2013, Edward Snowden changed what people knew
In 2013 Edward Snowden changed what people understood about nation-state cyber capabilities. In the decade that followed disclosures and leaks of nation state cyber tools reduced uncertainty and accelerated the diffusion of cyber tradecraft.

The defensive playbook that followed – compartmentalization, need-to-know, leak-surface reduction, clearance reform, “worked” because the Snowden leaks and those that followed were one-time disclosures, absorbed over a decade, with the system returning to something like equilibrium.

We got good at responding to the shocks of disclosures. It became doctrine.

It was the right doctrine for the wrong future.

Pandora’s Box
In 2026 Anthropic Mythos (and similar AI systems) changes what people can do. Mythos found Zero-day vulnerabilities and thousands of “bugs” that were not publicly known to exist (a must read article here.) Many of these were not just run-of-the-mill stack-smashing exploits but sophisticated attacks that required exploiting subtle race conditions, KASLR (Kernel Address Space Layout Randomization) bypasses, memory corruption vulnerabilities and logic flaws in cryptographic libraries in cryptography libraries, and bugs in TLS, AES-GCM, and SSH.

The reality is a number of these were not “bugs.” There were nation-state exploits built over decades.

What this means is that Anthropic Mythos, and the tools that will certainly follow, has exposed hacking tools previously only available to nation-states and transformed into tools that Script Kiddies will have within a few months (and certainly within a year.) No expertise will be required to apply that tradecraft, compressing both the learning curve and the execution barrier.

All Government’s Will Scramble
When Mythos-class systems are used to analyze the code in critical infrastructure and systems, the hidden sophisticated zero-day exploits that are already in use, (including ones nation-states have been sitting on for years) will be found and patched. That means the sources intelligence agencies used to collect information will go dark as companies and governments patch these vulnerabilities.

Every intelligence service will scramble, likely with their own AI, to find new exploits and accesses to replace the ones that have been burned. This will build a cyber arms race with a new generation of AI-driven cyber exploits to replace the ones that have been discovered.

Whichever side sustains faster AI adoption – not just “procures” it, but ships it into operational systems, holds a widening advantage measured in powers of two every four months.

The constraint for intelligence agencies (and companies) wont be their budgets, or authorities or access to models. It will be their institutional capacity for change – the rate at which a defender organization can actually change what it deploys.

The Long Tail Will Not Be Patched
Anthropic has given companies early access to secure the world’s most critical software,.

That will help Fortune 100 companies. But the Fortune 100 is not just a small part of the software attack surface.

The attack surface includes the unpatched county water utility, the regional hospital, the third-tier defense supplier, the school district, the state Department of Motor Vehicles, the municipal 911 system, and the small-town electric co-op. It includes the tens of thousands of systems running software nobody has time to patch, maintained by teams that have never heard of KASLR.

Every one of those systems is now exposed to nation-state-grade tradecraft, wielded by attackers with no expertise required. Mythos-class hardening at the top of the pyramid does not trickle down. The long tail will stay unpatched for years.

Attackers Advantage – For Now
Under continuous exponential growth of AI designed cyber attacks, a cyber defender using traditional tools can’t just respond just once and stabilize their systems. They’ll need to keep investing at a rate that matches the offense’s growth rate. A one-time defensive shock like compartmentalization might work against a sudden attack, but it will fail against sustained exponential pressure of these AI attack tools because there’s no stable equilibrium to return to. A defender’s investment rate now has to track the offense’s exponential growth rate.

Ultimately/hopefully, the next generation of AI driven cyber-defense tools will create a new equilibrium.

What We Need to Do
Mythos and its follow-ons will change how we think about cyber-defense. We can’t just build a set of features to catch every exploit x or y. We need to build cyber systems that can maintain or exceed the capability rate of the attackers.

Here are the three tools governments and cyber defense companies need to build now:

1. Measure the Gap Between Attackers and Defenders.  We need to know the gap between what the attackers can do and what we can defend against. We need to develop instrumented red/blue exercises (a simulation of a cyberattack, where two teams – the red team and the blue team – are pitted against each other) to estimate the number of new vulnerabilities vs cyber defense mitigation.
2. Measure the Defender Response Time. For each corporate or government mission system, measure how long it takes to implement a change from identification to production deployment. Then treat each organizational obstacle as equivalent to technical debt that needs to be fixed and obstacle to be removed..
3. Specify Speed, Not Features. Any new Cyber Defense tools and architecture – including the next-generation cloud-native systems sitting in review right now – should have explicit ‘rate’ requirements. Claims of “our product delivers X capability is now the wrong specification. “Closes detection gap at rate greater than or equal to the offense growth rate” is the right one.

Summary

Buckle up. It’s going to be a wild ride – for companies, for defense and for government agencies.

Mythos is a sea change. It requires a different response than what the current cyber security ecosystem was built for, and one the current system is not built to produce.

We are not behind yet. The gap between Mythos and what we can build to defend is small enough today that a serious response can still match it. A year from now, the same response will be eight times too slow. Two years, sixty-four.

By the way, the only thing left in Pandora’s Box was hope.

2026-04-22 23:34:09

This article previously appeared in the Entrepreneur & Innovation Exchange (EIX)

This is the 16th year we’ve been teaching the Stanford Lean LaunchPad class. This year, from the first hour of the first class, we realized we were seeing something extraordinary happen. It was both the end and beginning of a new era. 

Teams showed up to the first day of class with MVPs (Minimal Viable Products) looking like finished products that previous classes had taken weeks or months to build. After the class, as the instructors sat processing what just happened, we realized there’s no going back. 

I’ve been writing about how AI is going to change startups, but the shock of seeing 8 teams actually implementing it was mind blowing. And not a single team thought they were doing anything extraordinary.  

Class Observations: Product Development Velocity is Off the Scale
The old sequence for our class was simple – we had teams replicate what they would do in a startup. Have an idea. Build a team. Get out of the building to talk to customers to understand their problems, do Agile development and DevSecOps to build Minimal Viable Products (MVPs) over 10 weeks to test the solutions. And if they were going to build a company, discover and  develop a “moat” of proprietary code and features.

This year, in the first week of the class our students used multiple AI tools to replace what previously would have taken a large development team. They used Perplexity and ChatGPT for research, Claude Code and Replit to build apps, Vercel/v0 for prototyping, Granola to auto-transcribe and summarize customer interviews. The whole flow was compressed.

Because it was so easy to have an idea and then build something in minutes/hours, our students showed up on the first day of the class with products. They no longer had to wait weeks or months before testing whether anyone cares.

What we realized we were watching was a massive acceleration of the Customer Discovery / Customer Validation timeline. 

Learning 1. Impedance Mismatch Between Product Development and Learning
By the third week of the class we observed that the velocity of product development meant that teams could now generate more products than they could validate. The amount of product did not equal the amount of learning. Teams were so overwhelmed with so much information from the AI tools that they lost sight of the goal of customer development. They started to believe that the product itself was the truth.

Consequence 1. AI has made Customer Validation Harder
The abundance and ease of creating MVPs has become an accidental denial of service attack on the search for a repeatable and scalable business model. While this is an artifact of today, it means we need a different model for Customer Development as rapid coding isn’t going away.

Learning 2. Student Dependence On ChatGPT Decreased the Quality of Insights After week two of the class, it was clear teams were delegating communication to an AI. This dumbed down communication turned into AI slop. ChatGPT and Claude are no substitute for thoughtful communication – whether it’s email, PowerPoint or weekly summaries of Lessons Learned. Luckily you can spot this quickly.

Learning 3. Customers are Feeling Disrupted
As the student teams got out of the building, they discovered that potential customers were already feeling disrupted by AI. Many of the companies the teams demo’d to realized that they were seeing not just incremental improvements, but in fact were being shown a “going out of business” scenario.

Learning 4. Customers realize their proprietary data might be their only moat
In some cases, potential customers who would have previously shared their data with students are now asking for NDAs to share information with the team. Customers are realizing that closely held and hard-won information might be one of the few barriers to AI.

Potential 1: Customer Co-Design
As AI tools are allowing our teams to build higher fidelity MVPs, a few are beginning to consider using the MVPs as digital twins (as a simulation of the final product.) When put in the cloud and shared with potential earlyvangelists, startups can now start co-designing the product with potential prospects.

Teams can monitor if the digital twin is being used, how it’s used, and the feedback of what features are needed can be shared instantly. Teams can update the digital twin as they add features.

Potential 2: Agent/Customer Outcome Fit
Today, software applications are built to give users information and then expect the users to do the work via a user interface of dashboards, alerts, workflow tools and reports. But customers buy software to get a job done, not to look at more screens. Getting the job done is what AI Agents (orchestrated by tools like OpenClaw) will autonomously enable. For some teams, future class sections may see the search for Product/Market fit become the search for AI Agent/Customer Outcome fit. Minimum Viable Products (MVPs) will become Minimum Productive Outcomes (MPOs.)

Lessons Learned

• MVPs are No Longer an Indication of Technical Competence
  • Vibe coding has transformed MVPs to the equivalent of PowerPoint slides
• Speed to MVPs Hasn’t Yet Meant Faster Learning About Building a Company
  • While we’re still early in the class, the blinding speed of the first week’s onslaught of MVPs hasn’t yet translated into faster learning about customer validation.
• Business Process and Business Models Still Matter
  • The bottleneck for our student teams has moved from needing the resources to build high-quality MVPs to judgment: how to choose the right problem, how to read user signals correctly, and deciding what to build next.
• Product/Market Fit and Agent/Outcome Fit Will Co-Exist (for a while.)
  • While some customers are ready to move to an Agentic workflow, for others delivering Product/Market Fit is still what users want to see.
• Startup Teams Will Be Smaller
  • Our class teams are 4-5. In the past, if they decided to pursue their idea and start a company they would need to hire a larger team to build the product, manage the product, find out whether they had product/market fit, create demand, etc. That’s mostly no longer true.
  • Most teams won’t need to raise money to find out if the problem is real or before they know if users care.
• Enterprise Pricing Models Will Change
  • Some teams are already testing pricing that will shift from per/seat to workflows, outcomes, results, resolutions, successful task
• Customer Development Will Change
  • Because the Customer Development cycle is faster and multiple MVPs now can be run simultaneously…
  • Effort shifts to the extra time needed on hypotheses testing because the velocity and volume of product development can overwhelm signals from potential customers
  • As MVPs rapidly change, they need to be instrumented to monitor customer usage/interactions

More Learning In the Weeks Ahead

2026-04-09 21:00:25

Drones in Ukraine and in the War with Iran have made the surface of the earth a contested space. The U.S. has discovered that 1) air superiority and missile defense systems (THAAD, Patriot batteries) designed to counter tens or hundreds of aircraft and missiles is insufficient against asymmetric attacks of thousands of drones. And that 2) undefended high value fixed civilian infrastructure – oil tankers, data centers, desalination plants, oil refineries, energy nodes, factories, et al -are all at risk. 

When the targets are no longer just military assets but anything valuable on the surface, the long term math no longer favors the defender. To solve this problem the U.S. is spending $10s of billions of dollars on low-cost Counter-UAS systems – detection systems, inexpensive missiles, kamikaze drones, microwave and laser weapons.

But what we’re not spending $10s of billions on is learning how to cheaply and quickly put our high-value, hard-to-replace, and time-critical assets (munitions, fuel distribution, Command and Control continuity nodes, spares), etc., out of harm’s way – sheltered, underground (or in space). 

The lessons from Gaza reinforce that underground systems can also preserve forces and enable maneuver. The lessons from Ukraine are that survivability while under constant drone observation/attack requires using underground facilities to provide overhead cover (while masking RF, infrared and other signatures). And the lessons from Iran’s attacks on infrastructure in the Gulf Cooperation Council countries is that anything on the surface is going to be a target.

We need to rethink the nature of force protection as well as military and civilian infrastructure protection.

Protecting Ground Forces
The problem of protecting troops with foxholes against artillery is hundreds of years old. In WWI, trenches connected foxholes into systems. Bunkers were hardened against direct hits. Each step was a response to increased lethality from above. Today, drones are the new artillery; a persistent, cheap and precise overhead threat but with the ability to maneuver laterally, enter openings, and loiter. And mass drone attacks put every high value military and civilian target on the surface at risk. Fielding more hardened shelters for soldiers like the Army’s Modular Protective System Overhead Cover shelters is a first step for FPV kamikaze drones defense, but drones can get inside buildings through any sufficiently sized openings. 

Drone Protection
Ukraine has installed ~500 miles of anti-drone net tunnels with a goal of 2,500 miles by the end of 2026. These are metal poles and fishing nets stretched over roads but they represent the same instinct: the surface is a kill zone, so cover it. Russia has done the same.

The logical response is to go underground (or out to space) but the technology to do it quickly, cheaply, and at scale is genuinely new. The gap in current thinking is between “put up nets” (cheap, fast, limited) and “build a Cold War concrete bunker” (expensive, slow, permanent). What’s missing is the middle layer – rapidly bored shallow tunnels that provide genuine overhead cover for movement corridors, equipment parking, and personnel protection. 

What tunnels solve that nets and shelters don’t
A net stops an FPV drone’s propellers. A shelter stops shrapnel. But a tunnel 15-30 feet underground is invisible to ISR, immune most to top-attack munitions, can’t be entered by a drone through a door or window, and survives anything short of a bunker-buster. Gaza proved that even with total air superiority and ground control, Israel has destroyed only about 40 percent of Gaza’s tunnels after two and a half years of war.

That’s an asymmetric defender’s advantage the U.S. military should be thinking about for its own use, not just as a threat to overcome.

What’s changed to make this feasible is that we may not need boring tunnels per se, but instead modular, pre-fabricated tunnel segments that can be installed with cut-and-cover methods at expeditionary bases. Or autonomous boring machines sized for military logistics (smaller versions of the Boring Company TBMs) corridors rather than highway traffic.

The problem is a lack of urgency and imagination
The problem is real, the incumbents (Army Corps of Engineers) are slow, and the existing commercial tunneling industry isn’t thinking about expeditionary military applications.

The doctrinal gap is between “dig a foxhole with an entrenching tool” (individual soldier, hours) or deploy a few Army’s Modular Protective System Overhead Cover shelters or “build a Cold War hardened aircraft shelter” (major construction project, years, billions). There’s no doctrine for rapidly boring hardened underground movement corridors, dispersed equipment shelters, or protected command post positions using modern tunneling technology.

Army doctrine treats excavation as something done with organic engineer equipment — backhoes, bulldozers, troops with shovels — to create individual fighting positions and cut-and-cover bunkers. The Air Force doctrine barely addresses physical hardening at all, having spent 30 years assuming air superiority would substitute for it.

Nobody in the doctrinal community is asking: what if the Army could cut and cover 100 meters of precast tunnel segments in a day or if we could bore a 12-foot diameter tunnel 30 feet underground at a rate of a hundred of meters per week and use it as a protected logistics corridor, command post, or aircraft revetment?

Summary
Oceans on both sides and friendly nations on our borders have lulled America into a false sense of security. After all, the U.S. has not fought a foreign force on American soil since 1812.

Protection and survivability is no longer a problem for a single service nor is it a problem of a single solution or an incremental solution. Something fundamentally disruptive has changed in the nature of asymmetric warfare and there’s no going back. While we’re actively chasing immediate solutions (Golden Dome, JTAF-401, et al), we need to rethink the nature of force protection, and military and civilian infrastructure protection. Protection and survivability solutions are not as sexy as buying aircraft or weapons systems but they may be the key to winning a war.

The U.S. needs a coherent protection and survivability strategy across the DoW and all sectors of our economy. This conversation needs to be not only about how we do it, but how we organize to do it, how we budget and pay for it and how we rapidly deploy it.

Lessons Learned

• There is no coherent protection and survivability strategy that addresses drones across the DoW and the whole of nation
  • Just point solutions
• For troops near the front, tunnels could reduce visual, thermal, and RF signature while providing fragment protection with a network of small, concealed, overhead- covered positions, short connectors, buried command posts, protected aid stations, and revetted vehicle hides.  
• We need to underground assets that cannot be quickly replaced 
  • Command posts, comms nodes, ammunition, fuel distribution points, repair facilities, key power systems, maintenance spares, and high-value aircraft or drones.  
  • Think protected taxiways, blast walls, covered trenches, buried cabling, alternate exits, redundant portals, and rapid runway repair. Sortie generation under attack depends on a whole system, not one bunker.  
• We need to work with commercial companies to harden/defend their sites
  • Provide active defenses and incentives for under-grounding critical facilities
• The Army and Air Force need to rethink their doctrines and techniques for Protection and Survivability
  • Army Techniques Publications (ATP) 3-37.34 – Survivability Operations treat excavation as something done with backhoes, bulldozers, troops with shovels to create individual fighting positions and cut-and-cover bunkers. Update it.
  • The Air Force needs to do the same with AFDP 3-10, AFDP 3-0.1 (Force Protection and AFTTP 3-32.34v3, AFH 10-222, Volume 14 and UFC 3-340-02
• We need to think of force and infrastructure protection not piecemeal but holistically
• • Part of any weapons systems requirement and budget should now include protection and survivability 
  • Protection and survivability should be deployed concurrently with weapons systems
• We need a Whole of Nation approach to protection and survivability for both the force and critical infrastructure