Site icon Steve Blank

AI Killed the MVP – Long Live the IUP

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

Exit mobile version