2026-10-19 21:00:20
Announcing a Lean Educators Conference. Teaching Lean in the Age of AI.
November 18-19th at K&S Ranch, California.
When AI hit our spring Lean Launchpad for Deep Tech class, our teaching team was unprepared for the impact it made on the class.
What I didn’t realize was that other Lean educators (Hacking for Defense, NSF and NIH I-Corps, et al) were seeing the same problems, and all of us were grappling with how to solve them. If students can build in hours what once took weeks, the way we teach them has to change too.
After spending the summer thinking about the problem and what needed to change, I wrote a series of blog posts describing what we saw and what we were going to do about it.
Part 1: The Year AI Came For Us
Part 2: AI Killed the MVP – Long Live the IUP
Part 3: The World Outside the Classroom Changed, The Class Didn’t
Part 4: Lean LaunchPad – The Next Generation
I was surprised by the feedback from educators who wanted to get together and discuss what’s next.
Therefore this Lean Educators’ Conference.
Join us as we share the new syllabi we drafted for our revised Lean Launchpad and Hacking for Defense classes, and participants leave with a model they can teach, run, test, and continue improving. Come and share your suggestions and tools.
Collectively we can get smarter.
2026-10-13 21:00:19
This article previously appeared in Cipher Brief.
The DoW urgently needs to organize its scattered subterranean warfare assets into a single unified organization. Ideally, a Direct Reporting Portfolio Manager (DRPM) for Subterranean Warfare, reporting to the Deputy Secretary of War. (The Department already uses this model for unmanned systems, critical weapons and Golden Dome.) This group would have three portfolios: Subterranean Resilience, Subterranean Sensing and Subterranean Defeat. The office would integrate validated requirements, experimentation, testing, acquisition, and fielding.
Subterranean Resilience
During the 2026 Iran conflict, Iranian ballistic missiles and low-cost drones hit U.S. installations across eight Middle Eastern countries. Hundreds of buildings and structures were damaged or destroyed. The Navy’s Fifth Fleet headquarters in Bahrain was among the installations hit hard. Iranian weapons damaged one E-3 airborne early-warning aircraft and five KC-135 tankers on the ground in Saudi Arabia. (The official inspector-general report documents the damage.) Despite thousands of successful interceptions, the attacks exposed the vulnerability of concentrated, above-ground assets.
The rapid redeployment of the B-1s from RAF Fairford in the UK after warnings of an Iran-linked threat (reported as a possible drone attack) made the point: unsheltered concentrated high-value aircraft are vulnerable even way outside the theater.
The assumptions the U.S. has made about air superiority, missile defense, aircraft dispersal, building hardening, and the survivability of concentrated forward bases were all flawed. While we were prepared for ballistic missiles and hostile aircraft, drone swarms combined with ballistic missiles saturated and got through our defenses.
Washington’s reaction has been to invest billions of dollars in counter-drone and missile defense systems. Yet public budget documents reveal no comparable effort to put vulnerable aircraft, fuel, command-and-control nodes, and munitions out of harm’s way – sheltered, underground (or in space). (Agile Combat Employment, dispersal, hardening, deception, shelters, and rapid runway repair were never designed for a combined drone and missile onslaught.)
The Pentagon has recognized for decades that underground facilities are among the most effective ways an adversary can blunt U.S. conventional superiority. It described that problem explicitly in 1999. Gaza and Ukraine should have made it abundantly clear.
China, Russia, North Korea, and Iran use underground facilities, dispersal, hardening, and deception to make their own high-value assets harder to find, assess, and disable. 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.
The department needs an integrator that coordinates resilience across the Military Departments, Joint Staff, combatant commands, defense agencies, and intelligence community and provides Subterranean Resilience.
However, resilience is only one part of subterranean warfare.
Subterranean Sensing and Defeat
The U.S. needs to know where adversaries’ underground facilities are located, and the internal layout of those facilities. Today, these bespoke exquisite systems for tunnel detection, robotic mapping of accessible tunnels, Hard and Deeply Buried Targets (HDBT) characterization, and target defeat are siloed in organizations scattered across the DoW and other parts of the national security establishment. Most of these systems still require boots on the ground. Once a target is found, Combatant Commands need an integrated system that can characterize and destroy these targets, without first gaining physical access. Today, for the deepest facilities that means bombing from the air. Iran is the case in point.
Background. Iran’s route to a nuclear weapon is by enriching uranium. Natural uranium is composed of 0.71% uranium-235 (U235) and it’s only the U235 that is used to build a bomb.Iran uses centrifuges to separate U235 and increase its concentration (enriching it.) One centrifuge won’t do much, but connecting thousands of centrifuges together into cascades and running them for months can produce pounds of U235 .
2008 President of Iran Mahmoud Ahmadinejad touring Natanz enrichment facility
Iran’s underground nuclear enrichment site at Natanz had well over 10,000 centrifuges installed across dozens of cascades, and their Fordow nuclear enrichment site was built for 16 cascades, roughly 3,000 machines. Before the June 2025 strikes, Iran’s three declared enrichment facilities contained more than 20,000 centrifuges in 125 full-sized cascades.
The rough estimate needed for one Iranian nuclear weapon is ~100 lbs of U-235 at 60% enrichment or 55 lbs of U-235 at 90% enrichment (modern designs use less.) The difference is important, the lighter the weapon the easier it is to fit on a missile.
At its peak (Feb 2025 to June 2025) Iran’s cascades were delivering ~86 lbs of uranium enriched to 60% which is about 50 lbs of U-235 per month, which is just under one potential weapon every month. (Most weapons use U235 enriched to 90+% because that permits a smaller, more reliable design. Getting to that level in Iran might take days or weeks running the cascades, but building it into a weapon would still be needed.)
Deeply Buried Targets Versus Bunker Busters. One of the stated goals of the U.S. strikes on Iran was to remove their capacity to build nuclear weapons. This required the U.S. to destroy their deeply buried underground nuclear enrichment sites. The largest conventional bomb in the U.S. military’s arsenal is the 30,000-pound GBU-57 Massive Ordnance Penetrator, carried by the B-2 Bomber. A 2019 description said it could reach targets as far as 200 feet underground (its actual effectiveness depends on geology, concrete, facility design, entry points, and the use of multiple weapons). The Iranians knew this and built their nuclear enrichment sites underground. The Fordow site is ~260 to 300 feet under limestone and dolomite. The Natanz site is 25 to 160 feet underground, protected by a 25-foot concrete shield. (But public estimates are all over the place.)
Iran declared Isfahan as an enrichment complex to the IAEA the day before the June 2025 strikes; inspectors never got inside it, therefore its depth and geology are unknown, but speculation is that the enrichment complex is 260 to 330 feet underground. Another suspected enrichment facility is in Pickaxe Mountain, where the exact depths, geology, are unknown but estimates put the facility 250 – 330 feet below the summit. Both Isfahan and Pickaxe were Iran’s shift toward “deep mountain basing” to escape the reach of conventional military strikes.
In June 2025 in Operation Midnight Hammer U.S. B-2 bombers dropped 14 GBU-57 bombs on top of Fordow and Natanz. At Isfahan (Esfahan) more than two-dozen submarine-launched Tomahawks hit tunnel entrances and surface targets. In March 2026, strikes at Natanz hit its entrance.
According to the Institute for Science and International Security, the 22,000 centrifuges at Natanz, the Natanz pilot plant, and Fordow are almost certainly wrecked. What may have survived is the enriched uranium, the spare parts, and the people, and that is the problem. The International Atomic Energy Agency estimated (in June 2025) that Iran had about 970 pounds of uranium enriched to 60%; it has since lost track of where it is. Iran’s known uranium conversion capability at Isfahan was damaged, which it needed to turn the stockpile of enriched uranium into a weapon, and there is no public evidence that enrichment has resumed at Natanz, Fordow or Isfahan. We never hit Pickaxe Mountain or the Isfahan enrichment facility with the GBU-57. The strikes have set Iran back, but no one knows for how long.
While the GBU-57 MOP cannot cleanly punch through solid rock, the debate has shifted from an absolute physical destruction calculation to a functional denial calculation—meaning the military’s goal would be to seal Iran’s nuclear assets in a mountain tomb rather than blowing them up directly.
Did We Succeed? Our stated goal was to prevent Iran from rapidly rebuilding the capability to build nuclear weapons, but there’s no certainty that we did that. Repeated airstrikes may have damaged the buried enrichment plants, but we can’t prove it or account for the buried enriched uranium inside. The fact is that it’s extremely difficult to see how much damage the bombs did to Hard and Deeply Buried Targets (HDBTs) from the air, and without inspectors on the ground, knowing for sure is guesswork. Putting boots on the ground would carry enormous costs and risks. Negotiating the removal and inspection of weapons grade uranium would depend on Iranian cooperation and a way to verify we got it all. All bad choices.
There is another emerging option: autonomous drilling equipment.
Subterranean Sensing and Defeat. It’s not hard to imagine that with enough boots on the ground the U.S. could secure a landing zone, fly in drilling equipment and have crews drill hundreds of feet vertically or thousands horizontally to either place sensors and/or explosives. The U.S. has had organizations building specialized equipment and training for breaching tunnels in Combatant Commands and scattered across the DoW for years (DTRA, DARPA, Army ERDC and CAVES and CZ5 programs, SOCOM, Sandia and the Army’s half-billion-dollar underground-training push (2018) and ATP 3-21.51 Subterranean Operations.) One can even imagine that there are teams already trained and equipment ready to go. And one can equally imagine the Iranians are waiting for them.
What’s new is autonomous drills that could provide post-strike bomb damage assessments and/or destroy Hard and Deeply Buried Targets (HDBTs) without seizing the site. They might be inserted covertly; more likely they’d need air cover while they work.
The combination of AI, robotics and autonomy moves this from science fiction to the possible.
Anduril, The Boring Company, Exodigo, Phoenix Boring, Earthgrid and Traysar are possible candidates to deliver these systems. There are likely others as well.
(Disclosure: after my first blog about undergrounding critical assets, I invested and have a financial interest in companies in this space.)
Surface survivability and subterranean sensing and defeat are no longer one Service’s problem, and they won’t be solved by a single system or an incremental fix. 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, JIATF-401, et al), we need to rethink the nature of force protection, and military and civilian infrastructure protection.
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 it, how we budget and pay for it, and how we rapidly deploy it.
Lessons Learned
- The DoW needs to organize its scattered subterranean assets into a single organization: a Direct Reporting Portfolio Manager (DRPM) for Subterranean Warfare, reporting to the Deputy Secretary of War
- It should have three portfolios – Resilience, Sensing and Defeat
- Providing validated requirements, experimentation, testing, acquisition, and fielding to Combatant Commands.
- Protection and survivability solutions are not as sexy as buying aircraft or weapons systems but they may be the key to winning a war.
- Subterranean Sensing and Defeat need to move from bespoke special-operations capabilities into standard doctrine.
2026-09-30 21:00:28
You’re reading a four-part series on how AI has impacted our Lean LaunchPad class and what we did about it.
Part 1: The Year AI Came For Us
Part 2: AI Killed the MVP – Long Live the IUP
Part 3: The World Outside the Classroom Changed, The Class Didn’t
This post: Lean LaunchPad – The Next Generation
Lean LaunchPad – The Next Generation
While AI accelerates product development and customer discovery, it doesn’t accelerate understanding, evidence or insight. Teams still need to discover who has the problem, how painful it is, who controls the budget and data, what outcome counts as success, what failure is tolerable, how the product enters the workflow, and why a customer will choose a startup over dozens of fast followers or internally built solutions.
Here’s how we changed the course design to embrace the speed of AI while teaching students to first think deeply about their business, then act quickly to build it.
It took all summer and lots of suggestions from the Stanford Lean LaunchPad and Hacking for Defense instructors, but at the end of our own discovery, we concluded that our redesigned LLP class needed to:
What’s the Same?
The redesigned class will keep team-based, experiential learning, Business Model and Value Proposition Canvases, Customer Development, hypothesis testing, field interviews, weekly evidence reviews, validating the problem before validating the solution, permission to pivot and time pressure.
We’ll Start with a New Glossary
Renaming isn’t just a semantic hack. Language matters. It shapes behaviors and actions. In the chaotic and uncertain search for a business model, being precise with students helps them understand if they’ve made progress.
Here’s the new language we intend to use in the revised Lean LaunchPad class.
Stakeholders: users, customers, influencers, decision-makers, economic buyers, regulators, data owners, security teams, saboteurs, etc. Anyone influencing the adoption of your product/service.
Initial Untested Product (IUP): For the first class meeting, this will be an AI-created product/digital twin that may resemble a complete solution but has not been validated with customers or stakeholders.
IUP snippet: A small portion of the IUP used to test one value-proposition hypothesis without showing the full product.
Partially Tested Product (PTP): By the end of week 4 of the class, teams using IUP Snippets will produce a partially tested product based on customer feedback to validate/ invalidate/ modify the IUP.
Product-Outcome Fit (POF): A replacement for Product-Market Fit. A more focused goal for AI-accelerated startups to focus on.
Minimal Tested Canvas (MTC): A replacement for the term MVP for testing the other parts of the Business Model Canvas. The smallest set of experiments that meaningfully tests the non-product parts of the Business Model Canvas, including customers, channels, revenue, costs, partners, clinical end points, regulatory paths, and key activities.
Design Partner: A co-developer who first provides feedback, data, workflow access, and real-world testing in exchange for early access, preferential terms, or influence over the product. However, the real metric for success will be when the Design Partner is using the product and getting value out of it. (Design partners can be end-users in companies, warfighters, etc. who can buy or influence a sale.)
Design Partner Validated Product (DPVP): By the end of week 9, using successively refined PTPs, teams will have a Design Partner validated product.
Minimal Viable Product (MVP): A term previously used to discover and iterate on the value proposition and other parts of the Business Model Canvas – no longer used in the Lean LaunchPad class.
We’ll split the class into two parts:
Weeks 1 – 4 Think Deeply – Stakeholder, Problem and Hypotheses Maps and Connections
Weeks 5 – 9 Act Quickly – with a goal to get Design Partners
We’ll double down on Customer Discovery.
For the first four weeks students, using IUP Snippets, will get out of the building and map Stakeholders, problems, hypotheses and connections. The goal is to quickly understand current behavior, workarounds, budgets, failure costs, and decision processes.
Students will be graded on the quality of their outreach, not on the success of proving their snippet correct.
We’re going to Replace Product/Market Fit with Category-specific Product/Outcome Fit Goals. We’re updating generic product/market fit to match how AI companies are being built. For each product category, teams will use AI-specific Product-Outcome Fit discovery and validation goals:
We’re Eliminating MVPs for value proposition discovery. We’ll enforce rigorous problem and stakeholder discovery via hypothesis tests, using Stakeholder Maps, the Value Proposition Canvas and Lean Experiment Cards. (These are tools I’ve used at Imperial College in London to teach teams to solve “Wicked” Problems.) Teams identify and test problems and stakeholder hypotheses. Then they use portions of their initial product, the IUP Snippets, to test core value proposition hypotheses. There will be no “full product” demos until discovery is complete. Where the old class iterated low-fidelity to high-fidelity MVPs, the new class iterates low-fidelity to high-fidelity value propositions and stakeholder maps.
We’re Encouraging Synthetic Interviews but testing them against live interviews. Teams will create artificial personas and run weekly synthetic interviews. Then they will compare these responses with in-person interviews, validating or invalidating the synthetic responses and feeding the live responses back to the LLM to make the personas and synthetic interviews more accurate. Note the direction of authority: the live interviews grade the synthetic ones, never the reverse.
Create the Minimal Tested Canvas (MTC). AI can generate a product faster than a team can test the other eight boxes of the canvas. The “Minimal Tested Canvas” returns the course to a week-to-week focus on discovery, testing and experimentation of all canvas components (other than the value proposition). It tests a team’s understanding of the regulatory process, spec sheets, demand creation and sales model, funding, organizational decision processes, etc.
Create formal pivot-or-proceed criteria for discovery. Teams state their hypotheses across the canvas, test the problem, test the solution with IUP Snippets, then face explicit verify-or-pivot gates: verify the minimal IUP, the customer segment, customer relationships, the channel, and the revenue model.
Because AI removed the natural pacing that building and MVP used to impose, the class now imposes go/no-go criteria explicitly so a polished product can’t substitute for evidence.
Make Design Partners A Team Goal. The team’s class objective is to get one or more design partners. The partner commits scarce resources: staff time, data, integration effort, permissions, test environments, changes to workflow and the ability to influence the product.
A design partner is evidence of Customer Validation. In 2026, when anyone will take an online meeting and pilots spin up in days, a design partner who commits skin in the game is the honest signal.
Test for Learning Debt. Any team member should be able to explain the customer, workflow, evidence, economics, and key contradictions without opening a laptop. Technical members should hear customer language firsthand. AI-generated work should be attributed, and teams will distinguish what the model produced from what the team verified. (This is especially important in discovery: what was the result of synthetic interviews vs actual interviews.)
User Interface. The Initial Untested Product has to have a polish that wasn’t previously needed. Stakeholders compare every interface to a chatbots UI/design now has a greater importance than a traditional MVP.
LLM Costs. Three questions that didn’t exist in 2011 when this class was created are now core canvas economics: What does running a LLM cost you, and what are your unit economics? And what does it cost your customer to run it?
Autonomy Permissions. Which actions will the customer allow? At what level of reliability and reversibility. Human intervention remains especially important during early deployment and for sensitive, irreversible, or high-stakes actions?
AI Model Portability Is Strategic. Most frontier LLMs have proprietary context, tools, workflow, evaluation, trust, and distribution. A startup should assume that its preferred model, pricing, latency, terms, or relative quality will change. LLM Model dependence is therefore a business-model risk, not only an engineering choice.
“Trust” Evidence Is a Potential Moat In many markets, the evidence needed to deploy safely is not overhead added after product/market fit. It is part of product/market fit. NIST’s Generative AI Profile treats trustworthiness as a lifecycle discipline of governance, measurement, and risk management. The FDA’s AI-device guidance similarly connects iterative improvement to planned validation, documentation, and impact assessment.
Defensibility, opportunity size, team, and funding. The team’s defensibility moat needs to be part of discovery — from data, to model, to team, to hardware. Opportunity size and market type: is this an incremental improvement or does this change or create an industry? Team capabilities: does the team have unique attributes, experience and/or insight — and who else is needed?
Textbooks versus Tokens – Students won’t buy as many textbooks they’ll buy AI tokens and design tools. So expect to spend money.
A Heavier Lift for Faculty. The existing Lean Launchpad class had a lot more moving parts than teaching “how to write a business plan.” Yet it succeeded and scaled because it prepared students for the world as it was. This class will raise the bar once again – for both students and faculty. I believe the outcome will be the same.
Achievement inflation. In the current Lean LaunchPad class students are already padding the number of interviews they complete. We write off all but the most egregious as “cheating in your entrepreneurship class is like cheating in your parachute packing class.” The goal of finding Design Partners now creates new avenues to inflate accomplishments. We’ll be emphasizing partners that help validate the business and lead to growth not demos.
Design Partners as a Metric for Validation will likely result in students finding local maxima instead of the highest peak. However, this is no different from what happens in the early stage of most startups. We’ll be giving students heuristics to how time pivots to larger opportunities.
Teaching Student Teams How To Sell. In the past, a Go-to-Market strategy was just part of the customer relationship portion of the business model canvas. While a few teams generated revenue or received letters of intent while in class, we discouraged them from selling because at that point they hadn’t validated your solution. But now? We believe that AI will sufficiently accelerate problem and customer discovery in the front-end of the class. The pedagogy going forward is about the ability to rapidly discover and rapidly validate in the era of AI. So “selling” is actually curricula. This is a huge departure from the original Lean LaunchPad.
In the end, while we’re changing the tactics of the Lean LaunchPad class, its foundational beliefs remain unchanged: products succeed when they solve real customer problems/needs or create entirely new products that improve the lives of people, communities and businesses.
This new syllabus is itself a hypothesis that will be tested in Stanford’s Lean LaunchPad classes. I’ll follow up with a “What we learned” analysis of these changes. And there will be updates during the spring as we test this approach.
Comments, suggestions and your experience teaching with AI are welcomed.
We’re thinking of creating an educators guide and holding an in-person conference at Stanford / MIT on these changes. Let us know via comments or email if you’re interested.
I’ve been lucky enough to have been present at the creation of the last 50 years of disruptive technologies (semiconductors, computers, the internet, smart phones). None of us could envision how they would change the world. I can’t wait to see what my students are going to do with AI.
Puzzling through what happened to the class, the world around it and what to do next was a joint effort. Thanks to Steve Weinstein, Mar Hershenson, Jennifer Carolan, Chuck Eesley, Tom Byers, Eric Volmar at Stanford; Pete Newell, for feedback and at Imperial College Cristobal Garcia and Erkko Autio for the opportunity to teach the Stakeholder and Assumptions mapping tools in our Wicked Problems class.
Below is a draft of the updated syllabus for the students. As you read this, keep in mind the students are doing 10-15 Stakeholder interviews a week.
Class Website http://leanlaunchpad.stanford.edu
Professors
Steve Blank [email protected]
Steve Weinstein [email protected]
Jennifer Carolan [email protected]
Lee Redden [email protected]
Attendance
In-person class attendance, Office hours and Workshop attendance is mandatory.
Read this: This class is about how to build a sustainable business, not how to flip one. It is not an accelerator. If all you want to do is build a product do not take this class.
The class has a very particular point of view – that a small investment in time to understand stakeholder problems/needs and how to build defensible business model – can return huge payoffs.
This class works for all types of startups. R&D coming out of a lab, physical tech, software ideas, healthcare (including therapeutics, diagnostics, and medical devices) and others. If you think you can create a sustainable business from the idea, then this class will teach you the mechanics and methodologies.
This class assumes you (and everyone you’d be competing with) can create an AI-generated product or simulate portions of one. (We call whatever demo/product you bring to class the IUP (Initial Untested Product.)
For software this means vibe coding, for Hardware ideas it means simulations, spec sheets/CAD drawings, digital twins, for healthcare this includes AI created drug target profiles, efficacy curves, simulation of output from medical device, synthetic diagnostic performance
However, in the first 3-4 weeks of this class, your team is not going to be demonstrating your IUP. Instead, you’ll map all the stakeholders and your assumptions, then physically get out of the building to talk to them face-to-face and understand their problems and their day-in-the-life while learning and testing what it takes to build a repeatable, disruptive and scalable business model with a defensible moat.
During weeks 1 to 4 you can use “Snippets” (parts) of your IUP (Initial Untested Product) to test your hypotheses. This learning and discovery in the first half of the class will drive additional fidelity into your original IUP. By the end of week 4, you will have a Minimal Tested Canvas (MTC) and a Partially Tested Product.
In the second half of the class, the tactics shift. Now that you have a deeper understanding of who and why customers will buy, your team goal is to get one or more signed design partners (or have a validated Go-to-Market strategy) by the end of the class.
Warning: This is a tough class. We expect a lot from you. It has a high workload, operates with hustle culture, requires teamwork under pressure and offers relentlessly direct feedback. All team members – including those building the product – are expected to talk to customers. If they are not interested in doing so, do not take this class.
You will be expected to travel outside of Stanford and the Bay Area and pay for your own travel.
Read the syllabus carefully and consider if this class fits with your schedule, budget and willingness to learn in this framework and culture. Read the entire syllabus so you’re not surprised.
Before Class
Week 1 Learning Goals
Weekly Presentations:
The presentations generally follow a cadence of:
All team members should be prepared to present. We will select the presenter at class time.
Week 1 – Team Presentation Format
Slide 1 – Title Slide
Slide 2 – Business Model Canvas
Slide 3 – Stakeholders
Slide 4 – Hypotheses
Slide 5 – Live customer insights
Slide 6 – Initial Untested Snippets
Slide 7- Insights?
Slide 8- Next steps?
Week 2 Learning Goals
Week 2 Team Presentations
Slide 1 – Title Slide
Slide 2 – Business Model Canvas
Slide 3 – Stakeholders
Slide 4 – Hypotheses
Slide 5 – Actual Live customer insights
Slide 6 – Initial Untested Snippets
Slide 7- New Insights?
Slide 8- Next steps
Week 3 Learning Goals
Week 3 Team Presentations
Slide 1 – Title Slide
Slide 2 – Competitive Positioning
Slide 3 – Customer insights
● Update the summary table of your table of hypothesis/experiment/expected result/actual result/path forward (see sample slide)
Slide 3a – Customer Attempts
Slide 4 – Outcome/Value Proposition Canvas
Slide 5- Initial Customers/Design Partners
Slide 6 – Initial Untested Snippets
Slide 7 -Design Partners
Week 4 Learning Goals
Week 4 Team Presentations
Slide 1 – Title Slide
Slide 2 – Minimally Tested Business Model Canvas
Slide 3 – Initial Customers/Design Partners
Slide 4 -Partially Tested Snippets
Slide 5 – Defensibility/Moat
Slide 6 – Market/opportunity size (first pass)
Slide 7 -Design Partners
Pivot or Proceed Criteria
Team Workshop for Product/Outcome Fit Strategy
Teams meet individually with faculty to tailor Product/Outcome Fit goals for their specific technology and market. This will be their goal post for the next five weeks.
Week 5 Learning Goals
Weeks 6 – 8 The Search For a Design Partner
TBD
Week 9 – Reflection Week
Preparation for Final Lessons Learned Presentationfor Final
Lessons Learned
APPENDICES
LEAN LAUNCHPAD – ATTRIBUITON
We want you to use AI to the maximum extent possible in the class. However, ..
If you were in another lab on campus that was working on this idea…
LEAN LAUNCHPAD – INTELLECTUAL PROPERTY
Read Carefully: You are agreeing to these terms unless your team agrees in writing to something different
Who owns the intellectual property you are testing in the class?
If you’re working with a Stanford-related technology (i.e. either research from one of the team members or University IP), you must check with the Office of Technology, Licensing to understand Stanford ownership rights in any resulting IP.
I feel my idea / Business Model may become a real company and the “next killer company” and I want to own it myself. What should I do?
Will my Intellectual Property rights be protected when I discuss my ideas with the class?
I’m not comfortable sharing what I learn with others. What should I do?
ITAR Compliance
The activities in this class are fundamental research and are in compliance with ITAR regulations.
Fundamental research is defined as basic and applied research in science and engineering where the resulting information is ordinarily published and shared broadly within the scientific community, as distinguished from research the results of which are restricted for proprietary reasons or specific U.S. Government access and dissemination controls.
Applied research is further defined as a systemic study to gain knowledge or understanding necessary to determine the means by which a recognized and specific need may be met. It is a systematic application of knowledge toward the production of useful materials, devices, and systems or methods, including design, development, and improvement of prototypes and new processes to meet specific requirements. Fundamental research in this class means:
LEAN LAUNCHPAD – INSTRUCTIONAL METHOD
Experiential Learning: This class is not about the lectures. The learning occurs outside of the classroom through conversations with customers. We simulate what entrepreneurship is like in the real world: chaos, impossible deadlines, conflicting input, etc.
Team-Based Learning: This class is team-based. Each and every team member should participate in customer discovery activities (out-of-the-building hypotheses testing). You cannot delegate customer discovery. Teams will self-organize and establish individual roles on their own. There are no formal CEO/VP’s, just the constant parsing and allocating of the tasks that need to be done.
Relentless Direct Feedback. The teaching team assumes you’re some of the smartest and motivated students on campus. But because time is short we do not have the luxury to let teams drift or execute comfortable, flawed assumptions. We are going to constantly have you separate fact from opinion and we are going to insist on a Bias for Action; iterations, pivots, or restarts.
The “Flipped” Classroom: Unlike a traditional classroom where the instructor presents lecture material, you’ll watch core weekly lectures at home. These lectures contain the information you will need to complete that week’s customer interviews. What is traditional “homework” (summarizing team progress and receiving feedback) is now done in class.
Advanced Topic Lectures and Workshops: Online lectures may be supplemented by a deep-dive, in-class socratic lectures and workshops tailored to this week’s topic.
Weekly Presentations: Each week all teams will present a 10-minute summary of what you learned testing specific hypotheses. The teaching team will provide advice and guidance.
Team Teaching: Sitting in the back of the classroom are experienced instructors and mentors who’ve built and/or funded world-class startups and have worked with hundreds of entrepreneurial teams. They will be giving feedback on each team’s progress.
Cohort-Based Team Dynamics: The class is a learning cohort. It is your responsibility to help each other and learn from one another’s experiences. The professors will include student feedback opportunistically during feedback following weekly presentations. In addition, there will be two sessions with one-on-one team interactions to share perspective and advice.
Keeping Track of Your Progress: Each week you as a team will take the time to synthesize and summarize your insights from customer interviews using an online tools (detailed below). This is how we monitor progress and offer guidance.
Conducting Experiments: You’ll learn a lot by asking people questions. You’ll learn even more by observing what people actually do (which often is not what they say they would do). For each key hypothesis, you will design and run experiments to collect behavioral data and use these insights to iterate on your IUP.
2026-09-28 21:00:57
This post previously appeared in Poets and Quants
This is the third of four posts on how AI has impacted our Lean LaunchPad class and what we did about it.
Part 1: The Year AI Came For Us
Part 2: AI Killed the MVP – Long Live the IUP
Part 3: This Post
Part 4: Lean LaunchPad – The Next Generation
The Lean LaunchPad has successfully accommodated 15 years of evolution of technology and markets – until now. AI is not only changing our classroom; it is changing everything outside the classroom.
I needed to understand those external changes so the class could change with it.
The class I designed in 2011 focused on teaching founders how to understand a company’s entire business model, not just the product features and customers. However, there were four important elements outside a classroom or a startup that would affect its success.
The Lean LaunchPad class was designed to teach founders to use Lean Methods to derisk their new ventures — all while emulating the speed and tempo of 2011 startups.
The sidebar below summarizes what each of those types of companies looked like in 2011 compared to 2026. Skip this if you have a good memory.
The bottom line is that the world is a very different place and operates at a different pace from when I first designed the class, changes that AI has dramatically accelerated.
Looking at this comparison several things jump out:
Product/Market Fit Needs Specific Targets
When I looked at this table it struck me that for 15 years, we used the term “product/market fit” as a one-size-fits-all phrase to describe the intersection between Stakeholders and the product features they needed/wanted. It managed to cover end users, influencers, recommenders, requirements writers, regulators, etc. across deep tech, life science, defense. Up until now it worked well enough.
Today, product/market fit is evolving. In enterprise software it is becoming Agent/Outcome fit; in hardware, it’s digital twins and physical-world models; in life sciences, computationally tested endpoints. When we next teach the class, we will replace generic product/market fit with category-specific evidence: outcome/agent fit for enterprise, mass creation and testing for consumer, digital-twin-to-physical fit for hardware, endpoint-clinical-evidence fit for life sciences, and testing with standardized or validated external assessments for education.
AI Enables Faster Time to Market
While we need to teach founders to “think deeply” in the first half of the class, we also need to teach them “to act quickly.”
To do that, the second half of the class will ask teams to acquire one or more Design Partners as evidence of Customer Validation. A Design Partner is a co-developer who first provides feedback, data, workflow access, and real-world testing in exchange for early access, preferential terms, or influence over the product. The partner commits scarce resources: staff time, data, integration effort, permissions, test environments, changes to workflow and the ability to influence the product.
In Part 4, how all the pieces fit together to create a new Lean LaunchPad Course design.
2026-09-25 21:00:16
This post previously appeared in Poets and Quants
This is the second of four posts on how AI has impacted our Lean LaunchPad class and what we did about it.
Part 1: The Year AI Came For Us – This Post
Part 2: AI Killed the MVP – Long Live the IUP
Part 3: The World Outside the Classroom Changed, The Class Didn’t
Part 4: Lean LaunchPad – The Next Generation
Next Week
Part 3: The World Outside the Classroom Changed, The Class Didn’t
Part 4: Lean LaunchPad – The Next Generation
Leaving the After-Action Review of our class this spring, we thought we understood the problem AI had created. The Minimum Viable Product (MVP) was no longer a useful artifact for customer discovery and arriving at an evidence-based value proposition. (To make clear what we thought of these AI-generated day one products, we labeled them Initial Untested Products – IUPs.) We were confident that we could make some simple fixes to the syllabus to deal with this.
To my chagrin we would find that much like our students, we had confused the symptoms (the MVP is dead) with the much larger real problems facing the class. After lots of iterations we discovered the root causes and how to keep the class fresh for the AI age.
I thought it would be pretty simple to just make some minor tweaks to the class. But the more I thought about it, something troubled me. It felt like something much deeper was broken that I couldn’t yet articulate or put my finger on.
After a while I realized, you can’t know your future if you don’t understand your past. So I needed to go back to basics.
Who did I design the class for? How did I design the class? Why has it scaled and lasted almost two decades? What did we want students to learn 15 years ago? What do I want them to learn today?
It was time to rethink the pedagogy of the class – the why and how of what we were teaching. Then we could tackle the course design – the what, when, and in what order. The result would be the content of the class in an updated curriculum; and the syllabus for the students that describes all of it.
Only then could I make the changes to match the world as it is, not the world as it was.
What Was I Thinking?
I developed the Lean LaunchPad class in 2011 to break out of “how to write a business plan” which was then the capstone of entrepreneurial education. The old approach assumed that all founders of startups needed to do was to describe the future in a document, raise money and then execute the plan. The Lean approach started from the opposite premise: on day one, nearly every important fact in building a business is a hypothesis.
I realized 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 scalable business model. The class was designed to teach founders how to search for all parts of a business model, not just the product, and to create a classroom environment that closely resembled a startup – team-based, experiential, uncertain and relentless. (At the time this was heretical.)
In hindsight, the genius of the class design was to combine a universal framework, domain-specific field evidence, high-tempo accountability, and permission to change direction.
The original 10 Lean LaunchPad Course Design Elements included:
The Result
The class proved surprisingly portable, durable (15 years and counting) and universal.
These design elements allowed the course to be flexible enough to be replicated across industries (enterprise software, consumer products, hardware, therapeutics, medical devices, energy, climate, oceans, semiconductors, and national-security) without becoming a generic entrepreneurship lecture or requiring a completely different curriculum for every technology.
The class was adopted by the U.S. research community; the National Science Foundation, National Institutes of Health, and ARPA-E, relabeled as “I-Corps” and in over 100 universities. All these agencies used the class to teach principal investigators how to commercialize their science (training ~10,000 scientists in ~3,500 teams and launching 1,400+ startups to date.)
Five years later, a spin-off of the class using the same syllabus would become Hacking for Defense, now in 60+ U.S. universities and 17 in the UK.
And yet…
AI Killed the MVP – Long Live the IUP
The class had been resilient and adaptable but now as I stared at its 10 design elements it became clear that AI had demolished a core pillar of the class. With teams capable of vibe coding a product, minimum viable products (MVPs) did not represent proof of technical competence. MVPs were also no longer reliable evidence of customer discovery, critical thinking, hypothesis testing, product/market fit or even commitment. This meant two of the 10 class design elements were obsolete. So much so that we will now label Minimum Viable Products (MVPs) as Initial Untested Products (IUPs.)
We didn’t want to kill AI in the class. Quite the opposite. That’s the world as it is. We want students to use AI to the max, just like in the real world. But AI has changed the world in which entrepreneurs will create new companies. The Lean LaunchPad class needed to change more than the MVP.
The World Changed, The Class Didn’t
The class I designed in 2011 focused on teaching founders how to understand a company’s entire business model, not just the product features and customers. However, in 2026 there were four important elements outside a classroom or a startup that would affect their success.
AI was also changing everything outside the classroom. Including what AI just did to Product/Market Fit.
I needed to understand those changes so I could have the class match the future, not the past.
More in Part 3: The World Outside the Classroom Changed, The Class Didn’t and in
Part 4: Lean LaunchPad – The Next Generation
2026-09-23 21:00:12
This post previously appeared in Poets and Quants.
15 years ago, my Lean LaunchPad class changed how entrepreneurship is taught. The class is now taught in hundreds of universities worldwide and helped launch thousands of startups. But this past summer, I got thinking about whether AI killed our Lean LaunchPad class, and with it the Lean Startup and Customer Development.
I realized that if we wanted students to learn how to build businesses rather than AI slop, we had to rethink the class.
Here’s what happened, how we diagnosed the changes needed, and what we are planning to do going forward.
For the last 15 years the cadence of the Lean LaunchPad class has been the same. Students arrived with hypotheses of their product idea and target customers. Each week student teams got out of the building and talked to 10-15 stakeholders. The following week, they presented “Here’s what we thought, here’s what we did, here’s what we learned, and here’s what we’re going to do next week.” Over the 10-week quarter, teams would talk to 100+ stakeholders and use this feedback to validate, modify or invalidate their hypotheses about their business and refine and iterate their Minimal Viable Product in search for product/market fit.
The experience was meant to mirror the real-world journey of a startup founder, and regardless of the technical fad of the moment (social media, mobile apps, energy, life science, defense, et al), this pedagogy has worked like clockwork for 15 years. Coming into class in Spring 2026, I had no idea that this year would be its last, and how teaching entrepreneurship would never be the same.
The first week of class is always exciting
Several months before the Spring 2026 class was to start, we interviewed the teams to hear what problems they wanted to work on and select which would join the class. In the first official class, it was always interesting to see how much they’d dug into the problem before the first day of the class.
In the first class, teams typically presented a PowerPoint or wireframe of their product concept. This year, however, when the first team presented, there were no PowerPoint or wireframe prototypes. Instead they demoed a complete product (for Pediatric Sleep Apnea, Freight Forwarding, 3D-printed cooling for GPUs, music attribution, …) Wow.
We were impressed–this was the first time we had ever seen a team develop something this fast and feature-rich on day one. As I was still processing what a great job this team had done, the next team got up and also demoed a finished product. This time I was taken aback. Two in a row!? By the time the 3rd, 4th, 5th, 6th, 7th and 8th teams presented their complete products, all of us on the teaching team were stunned.
We kept looking at each other trying to confirm, “Did you see what I saw?”
To be honest, at first we instructors were giddy. All the teams had used AI to build apps, digital twins or clinical endpoints that in previous years we would have hoped to see at the end of week 10. We left class thinking these teams were on a great trajectory and thought for sure this start would lead to amazing outcomes for all of them.
We were wrong, wrong, wrong.
……………..Tired but accurate meme…………….
As a teaching team, we were so enamored with this phantom progress that we didn’t stop the presses and refocus the students fast enough. We didn’t realize that AI had set our class on fire and would burn it to the ground.
What AI changed inside the classroom
In past years, students would get of the building and spend time trying to deeply understand customers’ problems. They used the business model canvas to capture what they learned as they tested all their hypotheses (go-to-market strategy, pricing, product/market fit, revenue, costs, etc.) — all the essential elements needed to turn an idea into business.
AI made that process fail.
Students used AI instead of customers for insights and validation. And because this information came from AI, they assumed it was correct.
AI made it easier and faster for students to translate ideas into products—but they had no idea if this AI product met a customer need or solved a customer’s problem.
As the weeks went by, the teams that had looked so promising were learning less. Minimal Viable Products (MVPs) became sales pitches instead of experiments; teams collected compliments instead of disconfirming evidence; interviewees reacted to the product rather than explaining their problems/needs.
Meanwhile, teams were surprised to discover that many potential customers were already using the same AI tools to create their own alternatives just as fast as they could. (This bit of discovery was a signal to the team of what the floor was for features their startup could sell.)
In the end, many students couldn’t let go of the initial ideas that AI had helped them build. Pivots become more expensive psychologically, and those initial ideas became frozen regardless of evidence they heard from customers. This was ironic, given pivoting the product was now technically cheap. The teaching team had to intervene to pry these Initial Untested Products (what we had started calling MVPs) out of students’ hands.
The After-Action Review (AAR)
A few days after the class, while our memories were still fresh, we gathered the teaching team and Stanford faculty to share notes about what happened, why it happened, and how to improve.
As we went around the room describing what we had seen and what we thought it meant, a few things became clear.
The impact on learning far outweighed the benefits AI provided. To be sure there were positive parts of using AI in the class. Students had built these amazing products using Claude Skills and Gemini Gems. There were tons of untapped opportunities to build digital twins or test 10s or 100s of apps simultaneously. The impact on customer discovery was equally impressive. Assisted by AI, teams were able to surface the right questions to ask of the right people to get better answers to test their hypotheses faster. Teams used ChatGPT for market research and Replit to build websites, Granola and Twinmind for notetaking; created synthetic users with Listen Labs and Viewpoints AI to test against real customer data; summarized their research in Google NotebookLM or Notion, then used Perplexity to create their weekly presentations.
The MVP Is Dead
What was immediately obvious was AI’s impact on the Minimal Viable Product (an MVP). In the past, an MVP was painfully developed, reflecting the week-to-week cumulative knowledge gathered by talking to stakeholders. An MVP also was evidence of a team’s technical competence.
It struck us that having a product on day one meant an MVP was no longer evidence of anything: not customer discovery, critical thinking, hypothesis testing, product/market fit, customer validation or even commitment.
Creating products rapidly at almost no cost had allowed teams to make bad ideas go faster.
AI had created evidence theater. These Initial Untested Products felt like evidence but had been built with minimal or no contact with customers. They looked like progress but dramatically raised confirmation bias and delayed pivots.
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 search for Customer Validation. Team understanding was less nuanced; there was less depth uniformly across the teams about the problem they were solving and how well they understood customer needs.
It wasn’t that AI was hallucinating – the teams were. If they pivoted at all, they pivoted late as they assumed that a polished product meant product/market fit. (Pre-AI teams pivoted 3-4 times.) One team did go “IUP crazy” and created new IUPs weekly while never letting their learned evidence mount up.
All this added up to learning debt. These Initial Untested Products (IUPs) let teams skip the struggle which in the past had led to customer insight and understanding. The code worked, the deck was polished, and the analysis was coherent, but by using AI to summarize their interviews, teams missed the customer insights. As a result, they could not defend the assumptions or explain the edge cases.
As the teaching team discussed what we had seen and what we thought it meant, a few things became clear.
Leaving the After-Action Review, we thought we understood the problem. The Minimum Viable Product was no longer a useful artifact for learning and discovery about the value proposition and product/market fit. I felt confident that we could make some simple fixes to the syllabus to deal with this.
[Insert laughter here.]
Much like our students, we had just confused the symptoms (the MVP is dead) with much, much larger real problems. After lots of iterations we discovered the root causes and how to keep the class fresh for the AI age.
Part 1: The Year AI Came For Us – This Post
Part 2: AI Killed the MVP – Long Live the IUP
Part 3: The World Outside the Classroom Changed, The Class Didn’t
Part 4: Lean LaunchPad – The Next Generation