Lean LaunchPad – The Next Generation

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.

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

  •  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.
  • 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.


Week 5 – Lean LaunchPad

Week 5 Learning Goals

  • Testing a Design Partner/Go-to-Market Strategy
  • How to engage of potential Design Partner
  • Token spend and inference costs

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, ..

  • AI-generated or enhanced work (slides, products, et al) or created by AI must be clearly identified

If you were in another lab on campus that was working on this idea…

  • If you were part of a lab and used any of their work you need to acknowledge those contributors
  • And verify whether you have the right to commercialize those inventions

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.

  • If you personally bring any Intellectual Property (patents, hardware, algorithms, etc.) to the class, its ownership will remain with you.
  • The only exception is if you make “more than incidental use of Stanford resources,” in which case Stanford could have an ownership interest in the invention
  • You and your team members need to disclose to each other what IP/Licensing rights any company has to inventions you make at school/in this class.
  • If any or you decide to start a company based on the class, you own only what was written and completed in the class.
    • You have no claim for work done by others before or after the class quarter.
  • If a subset of the team decides to start a company they do NOT “owe” anything to any other team members for work done in and during the class.
  • All team members are free to start the same company, without permission of the others. (We would hope that a modicum of common sense and fairness would apply.)

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?

  • Discuss prior Intellectual Property rights with your team from the beginning
    • If you can’t come to agreement with the team, join another team, pick another project, or drop the class
  • Your slides, notes and findings will be shared.
  • Your team owns everything done in conjunction with this class – interview notes, code, et al. Remember anything you do and learn in the class may be public.

Will my Intellectual Property rights be protected when I discuss my ideas with the class?

  • You do not have to describe every part of your technology.
    • However you do have to describe what you are learning.
  • At times you will learn by seeing how previous classes solved the same class of problem by looking at their slides, notes and blogs.
  • All your presentations and Customer Discovery and Validation notes, business model canvas, blogs and slides can, and more likely will be shared and put online.
  • Keep in mind that successful companies are less about the original idea and more about the learning, discovery and execution. (That’s the purpose of this class.)
    • Therefore you must be prepared to share your ideas openly with the class
    • It is a forum for you to “bounce” your ideas off the teaching team and your peers.

I’m not comfortable sharing what I learn with others. What should I do?

  • When you’re doing customer discovery it’s not necessary to share IP details.
    • You are not sharing every technical detail
  • If sharing what you learn in the class makes you uncomfortable this may not be the right class.
  • Feel free to come to different arrangements
    • If you do, we suggest you do so in writing with all team members
  • If you have prior IP consult with a counsel/Stanford Licensing Office for advice

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:

  • There are no restrictions on publication of the information you discover and the IUPs you build
  • There is no specific project funding by the U.S. Government and there are no specific access and dissemination controls protecting information resulting from the research you do in this class.

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.

Leave a Reply

Discover more from Steve Blank

Subscribe now to keep reading and get access to the full archive.

Continue reading