AI Killed the MVP. Your Customers Will Expect Tailored Products. Is Your Engineering Org Ready?

AI has moved the bottleneck in software from building to judgment, and Steve Blank just proved it in his own Stanford classroom.

In Spring 2026, the first team in his Lean LaunchPad class walked in on day one and demoed a complete product. Then the second team did the same. By the eighth team, the whole teaching team was stunned. Every group had used AI to build in days what students used to show at the end of week 10.

It looked like a breakthrough. Blank's verdict a few months later, in a four part series on his blog, was blunt: the teaching team had been "wrong, wrong, wrong." The teams were learning less, not more.

I think every CTO and VP of Engineering should read that series. What happened to those student teams is happening right now inside engineering organizations of every size, from five person startups to Fortune 500 platforms.

The three parts of Blank's series this post draws on.

Who Steve Blank is, and why his warning matters

When the person who wrote the playbook for modern startups says the playbook is broken, it is worth listening.

Blank's own bio starts with him repairing fighter planes in Thailand during the Vietnam War. He arrived in Silicon Valley in 1978 and spent 21 years in 8 technology companies before retiring in 1999. Those included the semiconductor companies Zilog and MIPS Computers, Convergent Technologies, the supercomputer firm Ardent, SuperMac, the military intelligence supplier ESL, Rocket Science Games, and a consulting stint at Pixar. He co-founded his last company, E.piphany, in his living room in 1996. His own scorecard: two large craters, one dot com home run, and several base hits.

After retiring he wrote the books that shaped how a generation builds companies:

Customer Development became the heart of the Lean Startup movement. His May 2013 Harvard Business Review cover story, Why the Lean Startup Changes Everything, brought it to the mainstream.

The teaching record is just as long. He has taught at Stanford, U.C. Berkeley, Columbia, NYU, UCSF and Imperial College. His 2011 Lean LaunchPad class became the curriculum for the National Science Foundation's I-Corps, later adopted by NIH and ARPA-E. According to Blank, that program has trained about 10,000 scientists in 3,500 teams and launched more than 1,400 startups. Over 500,000 people have taken the class online. He co-created Hacking for Defense, which became a federal program and now runs in 60+ U.S. universities, and co-founded Stanford's Gordian Knot Center for National Security Innovation.

What AI did to the classroom: evidence theater and learning debt

The products worked. The learning did not.

In the first post, Blank describes how teams swapped customers for AI as their source of insight, and trusted the answers because they came from AI. Their MVPs turned into sales pitches instead of experiments. Interviewees reacted to a polished product instead of explaining their problems. Teams collected compliments instead of disconfirming evidence.

The result had a few names in the teaching team's after action review:

Blank's line that sticks with me:

It was not that the AI was hallucinating, it was the teams.Steve Blank, paraphrased

So in part two he retired the term. A Minimum Viable Product used to be evidence of technical competence and of accumulated customer knowledge. Now that anyone can vibe code a product, it proves neither. Blank renamed these artifacts Initial Untested Products (IUPs), and declared two of his ten course design elements obsolete.

How startups now approach development

When everyone can build in a weekend, what you choose to build and for whom becomes the whole game.

That is Blank's central conclusion. The bottleneck has moved from the time and cost of building to judgment about what to build.

Several things follow from it:

In part three Blank looks outside the classroom at four forces: venture capital, how products are built, the cost of building, and how customers adopt. His conclusion is that bottlenecks for adoption and scale still exist, they have just moved elsewhere.

Two of his fixes stand out for anyone shipping software:

1. 1

   Replace generic product/market fit with category specific evidence. For enterprise software, Blank says fit is becoming Agent/Outcome fit. You prove the agent delivers the outcome, not that the feature exists.

2. 2

   Require Design Partners. A design partner commits scarce resources, such as staff time, data, workflow access, integration effort and test environments, in exchange for early access and influence. Commitment, not compliments, becomes the proof.

Sam Altman's version: tailor the product to the customer

Blank is not alone. In the same weeks his series came out, Sam Altman made the case from the other side: AI makes it economical to build for each customer's specific needs.

At OpenAI DevDay on September 29, Altman introduced "dots," OpenAI's always-on agents, and said the company is building specialist versions for fields like legal and finance in collaboration with enterprises (Simon Willison's live blog). Companies can also set up their own specialist dots, each with its own identity, credentials and access to the systems it needs (Wccftech). He also argued that today's software abstractions start to fail once several people and their AI agents work together (BigGo Finance).

Earlier in September, Altman told Axios that software for a few thousand users, which never justified paying engineers, is now viable because it costs almost nothing to build. In his words (TNW):

"The space of viability has increased dramatically."Sam Altman, to Axios

Put next to Blank, the message is the same: generic is no longer a moat. When building is cheap, value comes from fitting the product to a specific customer's workflow, data and outcomes. That is Blank's design partner idea, applied at scale.

For engineering organizations this cuts two ways:

Your engineering org is a classroom too

Swap "student team" for "engineering team" and Blank's diagnosis reads like a status report from most companies we talk to.

AI coding tools have made output cheap. Pull requests, lines of code and shipped features are all up. Dashboards look great. But output is now the engineering version of an IUP: it looks like progress and proves very little on its own.

The same failure modes show up at every size:

In each case the organization is collecting compliments instead of evidence. Activity is mistaken for impact, and learning debt shows up later as rework, review bottlenecks, incidents and code nobody fully understands.

Size changes the scale of the damage, not the nature of it. A five person team and a 5,000 engineer platform face the same question Blank put to his students: now that building is easy, how do you know you are building the right thing, the right way?

How to approach the new AI SDLC

Treat every AI driven change to your software lifecycle as a hypothesis, and demand evidence before you scale it.

That is Customer Development applied to engineering. Here is how Blank's lessons translate:

In practice, that comes down to five habits:

1. 1

   Baseline before you roll out.

   You cannot prove impact without a before. Capture cycle time, review load, quality and delivery metrics first.

2. 2

   Measure outcomes, not adoption.

   Seats and prompts are activity. The question is whether AI assisted work ships faster, breaks less and maps to goals.

3. 3

   Run small, honest experiments.

   Pick a few teams as internal design partners, compare against control teams, and publish what failed as well as what worked.

4. 4

   Keep humans accountable for judgment.

   Invest in specs, architecture and code review. That is where the new bottleneck lives.

5. 5

   Pivot fast and without ego.

   If a tool or workflow does not show impact after a fair test, drop it. Sunk cost is how teams freeze.

Get out of the building, again

Blank's oldest advice was to get out of the building and talk to customers. In the AI era, engineering leaders need the same discipline pointed inward: get out of the dashboard and look at the evidence.

The teams that win will not be the ones that generate the most code. They will be the ones that learn fastest about which AI workflows actually create value, and have the data to prove it.