Steve Blank

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:

• Double down in the front end of the class on the rigor of understanding Stakeholders, Problems, Hypotheses and Connections
• Double down on AI for its rapid development/deployment, time-to-market speed up and ability to transform entire industries
• Replace the MVP as evidence of the Value Proposition with “Snippets” (Using a small portion of the initial untested product to test a value-proposition)
• Replace the MVP as evidence for testing the other parts of the Business Model Canvas with “Minimal Tested Canvas” tests.
• Make Product/Market Fit targets category specific
• Change the class tempo to move even faster
• Use Design Partners as evidence of Customer Validation in the second half of the class
• Change the language to embrace new class concepts

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.

What Changes – Class Tactics

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:

• B-to-B enterprise software teams search for Outcome/Agent fit. The customer can define acceptable work, the agent reaches that threshold in the target workflow, the organization grants the required permissions, and the old alternative is reduced or retired.
• B-to-C consumer teams do mass creation and testing, spinning up and testing many variants in parallel. The team finds a problem/need, target archetype(s) and behavior, acquisition and retention loop, and distribution path that survive repeated testing across variants.
• Hardware teams build digital twins. Simulations predict the behavior of prototypes closely enough to accelerate iteration, while manufacturability, reliability, supply, and deployment remain viable.
• Life science teams accelerate their Initial Untested Product with simulation and modeling tools and test clinical endpoints (therapeutics, diagnostics, devices, clinical trials), reimbursement and financing.

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.

AI-Specific Class Additions

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.

Risks

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.

Putting the pieces together

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.

Lean Launchpad Syllabus  Course Details

Class Website http://leanlaunchpad.stanford.edu

Professors
Steve Blank sblank@kandsranch.com
Steve Weinstein sweinstein@stanford.edu
Jennifer Carolan jennifer@reachcapital.com
Lee Redden leeredden@gmail.com

Attendance
In-person class attendance, Office hours and Workshop attendance is mandatory.

Before Class

•  Set up your teams of AI agents to have specific expertise to help you sort through your discovery efforts (research, notes, synthesis, creativity, design, and so forth). Keep in mind discovery is your job, not the agents’ job. But they can be powerful assistants.
  • Last year’s team used Claude Skills and Gemini Gems, ChatGPT for market research and Replit to build websites, Granola and Twinmind for note-taking; 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. This year newer/even more productive AI tools are available.
• Create an Initial untested Business Model Canvas
• Create an initial Stakeholder map of all your hypothetical Stakeholders
• Create an initial Hypotheses Map for each of the stakeholders
• Create the initial hypothesis of what Problem-Outcome would look like that would satisfy the stakeholders.
• Create the initial hypotheses for the other canvas components (demand creation, go to market, costs, revenue model, etc.)
• What insight do you have – what does the consensus model output say about our problem, and what do you believe that contradicts it?
• For potential software products, create Product Snippets (not Demos) to test specific hypotheses with stakeholders or use AI to create models or other artifacts
• Do at least 10 actual human interviews (record the interviews)
  • Each interview in the format of: a “hypothesis/experiment/expected result/actual result/path forward”
  • Note that Stanford students do not count as interviews. 50% need to be in person.
  • All interviews require that the person you interview give you permission to record the interview. This needs to be in writing and/or capturing the permission in the recording itself.
• Create 5 potential AI customer personas and interview them, then have AI analyze the answers and create a new set for actual interviews. What is the consensus view as determined by AI?
• For hardware or physical products, potentially create a vibe coded digital proxy, digital twin version or use AI to create models, spec sheets, etc.
• Submit all by day-prior to class start.

Week 1: Stakeholders, Hypotheses, Business Model, Snippets and Customer Development

Week 1  Learning Goals

• Understand the difference between product development and problem understanding
• Understand the value of the:
  • Business Model Canvas
  • Stakeholders and Hypotheses
• How to reach Design and conduct stakeholder interviews
• How to design hypothesis/experiment interviews
• How to use Initial Untested Product snippets as a tool for discovery vs validation of your product

Weekly Presentations:

The presentations generally follow a cadence of:

• Here’s what we thought
• Here’s what we did
• Here’s what we found
• Here’s what we are going to do next.

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

• Team Name
• Interviews this week in person, remote, synthetic
• Total interviews: in person, remote, synthetic
• Problem You’re Solving
• Team Members

Slide 2 – Business Model Canvas

• Briefly highlight any key insights
• Use the next slide to zoom into the Stakeholders

Slide 3 – Stakeholders

• Show us your Stakeholder Map
• Who are the users? Decision-makers? Influencers? Economic Buyers? Regulators? etc.

Slide 4 – Hypotheses

• Show us your Hypotheses Map
• Connect the Hypotheses to the Stakeholders

Slide 5 – Live customer insights

• Show us a summary table of your table of hypothesis/experiment/expected result/actual result/path forward (see sample slide)
• Quote(s) and photos here are required.
• How did it compare to the synthetic interviews?

Slide 6 – Initial Untested Snippets

• Briefly, show us the product if you’ve built it.
• Show us the initial snippet
  • What hypotheses was the snippet(s) testing?
  • What were the results?

Slide 7- Insights?

Slide 8- Next steps?

Week 2: Experiment Design and Execution, Interview Insights

Week 2 Learning Goals

• Refine Customer Discovery Skills
• Refine hypothesis/experiment interviews
• Design and Run experiments
• Identify Stakeholder archetypes
• Understand value proposition and the role of Initial Untested Product snippets
• Understand and practice effective cold outreach

Week 2 Team Presentations

Slide 1 – Title Slide

• Same as week 1

Slide 2 – Business Model Canvas

• Briefly highlight any changes
• Use the next slide to zoom into the Stakeholders

Slide 3 – Stakeholders

• Enhance the Stakeholder Map
• Who are the users? Decision-makers? Influencers? Economic Buyers? Regulators? etc.

Slide 4 – Hypotheses

• Refine the Hypotheses Map
• Connect the Hypotheses to the Stakeholders

Slide 5 – Actual Live customer insights

• Update the summary table of your table of hypothesis/experiment/expected result/actual result/path forward (see sample slide)
• Include past weeks

Slide 6 – Initial Untested Snippets

• New/refined snippets? Show us
  • What hypotheses was the snippet(s) testing?
  • What were the results?
• Briefly, show us the product if you’ve built it. Highlight if anything has changed

Slide 7- New Insights?

Slide 8- Next steps

Week 3 – Stakeholders, Competitors, Moats

Week 3 Learning Goals

• Stakeholder Segments
• Enhanced Value Proposition Canvas
• Competitive Positioning
• Stakeholder/Outcome Fit
• How are potential stakeholders attempting to solve the problem?
• What is a Design Partner/Go-to-Market Strategy?
• Define your moat. E.g. data accumulated, distribution channel, brand, clearance held, evidence accumulated, yield learned, deployed-instrument data, qualified supply chain, installed base, etc.

Week 3 Team Presentations

Slide 1 – Title Slide

• Same as week 1

Slide 2 – Competitive Positioning

• Draw a Petal Diagram
• What is your competitive moat?

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

• What have the customers already tried, including with AI, and specifically why did it fail?

Slide 4 – Outcome/Value Proposition Canvas

• Combine learning from stakeholders & experiments to create an Enhanced Value Prop Canvas
• See example in Appendix A

Slide 5- Initial Customers/Design Partners

• Who will they be? Why?

Slide 6 – Initial Untested Snippets

• New/refined snippets? Show us
• Briefly, show us the current state of the product (if you’ve built it.)
• Highlight what you learned from stakeholder feedback.
• What will you show potential customers/Design Partners?

Slide 7 -Design Partners

• Using the Enhanced Value Proposition Canvas who would be Potential Design Partners?
• Engagement plan hypotheses

Week 4 – Stakeholder/Outcome Fit?  Pivot or Proceed?

Week 4 Learning Goals

• Day-in-the-Life of Stakeholders
• Setting a Product/Outcome Fit Strategy
• Testing a Design Partner/Go-to-Market Strategy
• How to engage potential Design Partners
• Pivot or Proceed?

Week 4 Team Presentations

Slide 1 – Title Slide

• Same as week 1

Slide 2 – Minimally Tested Business Model Canvas

• Go through each box of the business model canvas
• Highlight key learnings and any changes
• Use the next slide to zoom into the Stakeholders

Slide 3 – Initial Customers/Design Partners

• Who will they be? Why?
• Use Value Proposition Canvases to illustrate

Slide 4 -Partially Tested Snippets

• New/refined snippets? Show us
• Briefly, show us the current state of the product (if you’ve built it.)
• Highlight what you learned from stakeholder feedback.
• What will you show potential customers/Design Partners?

Slide 5 – Defensibility/Moat

• Short term? Long term?
• Unique data? Data Access?
• Trust? Evidence/verifications?

Slide 6 – Market/opportunity size (first pass)

• Market/opportunity size
• Funding/team needed

Slide 7 -Design Partners

• Update the Enhanced Value Proposition Canvas to point to Potential Design Partners/Go-to-Market Strategy
• Define Product/Outcome Fit Strategy for Partners
• Partners Engagement plan

Pivot or Proceed Criteria

• Stakeholder(s): who are they and what’s their problem/objective?
  • Show me the evidence of your understanding!
• Value Prop: do Stakeholder(s): care about how you intend to create value / solve the problem?
  • Show me the evidence that they care!
• Differentiation & moats: why will Stakeholder(s): pick you and is your advantage defensible?
  • Show me the evidence they’ll choose you!
• Willingness to pay & economics: will customers pay enough, and can you make the economics work?
  • Show me the evidence they’ll pay!
• Customer acquisition & retention: How are you going to acquire and retain customers?
  • Show me the evidence

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.

Filed under: Lean LaunchPad, Teaching | 3 Comments »

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.

• Venture capital (how much startups could raise, when they could raise and who they could raise it from)
• How startups built their products (core tech platforms and development tools)
• The cost of building products (time to market, team size, capital requirements)
• Customer Adoption (how did they evaluate, buy, deploy and use products. And the speed in which they did that. And customer build versus buy criteria.)

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:

1. Bottlenecks for adoption and scale still exist, they’ve just moved elsewhere.
2. Product/Market fit needs market-specific targeted end points
3. Customers are willing to be design partners
4. Finding defensible moats is critical

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.

Filed under: Lean LaunchPad, Teaching | 2 Comments »

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
Part 2: This Post

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:

1. The Business Model Canvas as a hypothesis map. The Business Model Canvas captured the team’s assumptions about customers, customer problems/needs, value propositions, channels, revenue, costs, partners and activities. The canvas created a common language across industries. It exposed the full set of assumptions that had to become facts. It also acted as connective tissue: when teams became lost in the details of a prototype or an interview, they could return to the map.
2. Customer Development as the core activity. Customer Development pushed students outside the classroom and tested their assumptions directly with customers and stakeholders. Customer discovery could start before a finished product existed, making the method applicable in domains where building took days, months, or years (hardware, biotechnology, semiconductors, energy, defense, et al.)
3. 100 customer and stakeholder interviews created Pattern Recognition. The demand for 100+ interviews added breadth, diversity and repetition. It allowed for testing the all the parts that make up a business model, not just the product. More than 100 interviews made it harder to rely on friendly contacts, anecdotes or confirmation bias. High volume exposed differences between users and buyers, early adopters and mainstream customers, and stated preferences and actual behavior.
4. Hypotheses turned into experiments. Teams stated what they believed, identified the evidence needed, ran experiments, and reported whether each hypothesis survived. It was the scientific method applied to startups. The process remained consistent even though the experiments varied by industry.
5. Minimum Viable Products (MVPs) took on two roles. First, the MVP was a sign of a team’s technical competence and reflected a team’s cumulative knowledge of customer problems and possible solutions. Agile engineering built Minimum Viable Products iteratively and incrementally. The iteration of incrementally refined MVPs allowed teams to find product/market fit between Stakeholders and a value proposition and a path to a repeatable and scalable business model.
   
6. Minimum Viable Products (MVPs) were also used to test the entire business model – not just the product. Teams built the smallest artifact needed to validate any part of their business model. An MVP was whatever got you the most learning about your business model at a point in time, creating evidence and reducing uncertainty.  (E.g. a MVP could be a landing page or A/B test to validate a go-to-market strategy, a price list to test potential revenue, clinical endpoint, bill of materials to test costs, etc.)
7. Pivoting or restarts were legitimate outcomes. Discovering that an opportunity was unattractive was a valid result. The class reduced pressure to manufacture positive findings and made it possible to allocate time and capital away from weak opportunities.
8. Intensity and time pressure. Teams operated under demanding weekly deadlines, required fieldwork, weekly public presentations, and direct and unsparing instructor feedback, coupled with incomplete and uncertain information. The process forced teams to distinguish the evidence they were hearing from customers from their own opinions.This intensity exposed students to real-world startup conditions of rapid/good-enough decision-making. (As a side-effect it also exposed dysfunctional team behavior.) This cadence of operating in chaos and uncertainty compressed months of informal learning into a short, structured cycle. Pivots and restarts were recognized as legitimate outcomes rather than admissions of failure.
9. Experienced practitioners as instructors. Class time was used primarily for critique and coaching rather than conventional lectures. Experienced instructors could recognize recurring startup patterns, while mentors supplied specialized domain knowledge. Instructors did not need to be the world’s leading experts in every technology.
10. A standardized process with adaptable content. The course appeared open-ended to students, but its freedom sat inside a carefully designed structure. The cadence, canvas, interview process, MVP search for product-market fit, and evidence requirements were standardized, while the interview targets and types of experiments varied by domain. For example, in life sciences the canvas emphasized clinical research organizations and clinical end points, FDA regulations, insurer reimbursement, etc. while in B-to-B the emphasis was product/market fit.

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.

1. Venture capital (how much startups could raise, when they could raise and who they could raise it from)
2. How startups built their products (core tech platforms and development tools)
3. The cost of building products (time to market, team size, capital requirements)
4. Customer Adoption (how did they evaluate, buy, deploy and use products. And the speed in which they did that. And customer build versus buy criteria.)

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

Filed under: Lean LaunchPad, Teaching | 7 Comments »

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 3^rd, 4^th, 5^th, 6^th, 7^th and 8^th 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.

1. The MVP as an artifact of learning about a value proposition was dead.
2. The bottleneck in startups has moved from the time and cost of building a product to judgment about what to build and who to build it for. This means founders still need to know which problem matters, who will pay, how to distribute, and how to move faster than the other teams who can also build something in a weekend.
3. When everyone can build quickly, what you choose to build and for whom becomes the whole game.
4. This means the competitive landscape is much more important. Previously a team could spend a semester largely ignoring competitors because the time and cost of building a product became a moat. That moat no longer exists. Teams now need a deep understanding of the current competitive landscape and the rapid competitive trends.
5. AI has made customers more sophisticated– now they can use AI to build solutions as fast as startups can. This means the discovery process now also needs to find moats and paths to scale.
6. There are low barriers to cloning. That same ease of creation means startups need to learn how to build defensible moats — and to treat a moat as a discovery problem, not a slide in the fundraising deck. IP used to be defensible. Now what is defensible IP?

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.

Filed under: Lean LaunchPad, Teaching | 13 Comments »