A few years ago, showing a product that worked was a sign that the team had solved something hard. Today a coding agent does it in days. The signal has lost its value, and many teams have not noticed yet.
The thesis of this piece: with AI, a startup's discipline moves from building to the hypothesis. Before the first line, you need to write down what you believe, what would prove it wrong and what you will test with real customers. A demo that convinces on its own is not evidence.
What Steve Blank saw in his Stanford class
Steve Blank, one of the figures of the lean startup movement, has spent years teaching how to found companies at Stanford with his Lean LaunchPad class. In September 2026 he described what happened in the spring edition: students arrived with complete products on day one, and the teaching team was thrilled. It did not last.
According to Blank, "students used AI instead of customers for insights and validation". Those products "looked like progress but dramatically raised confirmation bias and delayed pivots". The team had invested in something that worked, which made it harder to accept that perhaps nobody wanted it.
Three days later, Blank took the next step: the minimum viable product was no longer a useful artifact for customer discovery and for arriving at an evidence-based value proposition. So he stopped calling those day-one products MVPs. He now calls them Initial Untested Products.
Limit This is a professor's account of one class, not a study with a sample and a control group. Its value lies in the mechanism it describes, not in a number. And Blank does not say building fast is bad: he says building fast no longer proves anything.
What an MVP was, and why it is no longer enough
In 2009, Eric Ries defined the minimum viable product as the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. The key word was never "product". It was "learning".
For years the two went together because building was expensive: to avoid spending months, you built the minimum, and the minimum forced you to talk to customers early. That constraint did a good part of the work. Now, as Blank writes in the third part of his series, agents write most of the code, a spec becomes a working product in days, and creation is cheap for everyone.
When the constraint disappears, the shortcut appears on its own: if I already have the product, why go out and ask? Blank sums it up with a sentence from his second part: on day one, nearly every important fact in building a business is a hypothesis. A complete product does not change that. It just hides it better.
If building no longer costs anything, the product stops being the proof. The proof goes back to what it always was: what real customers do when you show it to them.
Where the discipline goes now
In the fourth part of the series, Blank explains how his class is changing. Teams must do at least ten real interviews before the first session, half of them in person. AI-simulated interviews are allowed, but the live interviews grade the synthetic ones, never the reverse. There are no full product demos until discovery is complete, and there are explicit continue-or-change points so that a polished product cannot substitute for evidence.
To test the value proposition, Blank replaces the MVP with small slices of the product he calls snippets. And the team's goal is no longer generic: get one or more design partners.
Outside the classroom, the translation for a founder is direct: the share of the work that building used to take now goes into writing and testing the hypothesis. Here is the difference in a table:
| Question | Day-one product | Written hypothesis |
|---|---|---|
| What it proves | That it can be built | What has to be true for someone to pay |
| Who it convinces | The team itself, and sometimes whoever sees the demo | Nobody yet: it is designed to be proved wrong |
| When the mistake shows up | Late, when it is already hard to give up what was built | Early, in the first conversations with customers |
| What happens if it fails | The product gets defended | The hypothesis changes and gets tested again |
onext's own reading of Steve Blank's series (September and October 2026)
What to write before the first line
You do not need a long document. You need three things written down before you ask an agent for anything, readable by someone other than the founder:
- What we believe. Who has the problem, what exactly it is and why they would pay to solve it. No adjectives: a specific person with a specific problem.
- What would change our mind. The signal that, if it shows up, proves the hypothesis wrong. If you cannot write it, the hypothesis cannot be tested.
- What we will test, with whom, and when we decide. What you will show customers, how many of them, and on what date you decide to continue or change course.
With that written down, building fast becomes an advantage again: you build just enough to show something concrete and learn from the reaction. How to do it without mortgaging what comes next is in how to launch an MVP fast without mortgaging the product, and what to look for in whoever helps you build it is in a startup's development partner.
The same logic as a specification
None of this is new for people who work with coding agents. In Spec-Driven Development (SDD), you first write what the code must do and then you build it, so the agent does not decide on its own what was wanted. We explain it in what SDD is and how it keeps code under control, and why it brings back upfront analysis without losing short delivery cycles in the best of waterfall and the best of agile.
The business hypothesis is that specification one level up: it does not say what the code must do, but what has to be true in the market. And it has the same enemy. A product nobody on the team can explain the reasons for looks a lot like the comprehension debt of code nobody can explain. In an established company, the equivalent is the value thesis worth asking a team for before investing in AI.
Before you build
If you are preparing your first product and want to check with someone from outside which hypothesis you are testing and how you will know whether it is true, let's talk. The conversation starts with the hypothesis, not the product.
Frequently asked questions
Has AI killed the MVP?
It has killed one of its jobs. The minimum viable product was meant to learn as much as possible about customers with the least effort. When an agent builds a complete version in days, effort stops being the limit, but learning still requires real customers. Steve Blank no longer calls those products MVPs; he calls them Initial Untested Products.
What is an Initial Untested Product?
It is the name Steve Blank gives, in his September and October 2026 series, to the products his Stanford students built with AI from day one. They look like an MVP, but they have not been tested with a single customer: they are an initial untested product, not proof of anything.
What should the written hypothesis include?
Three things before the first line of code: what you believe (who has the problem, what it is and why they would pay to solve it), what would prove it wrong (a concrete signal that would change your mind) and what you will test with real customers, including when you decide to continue or change course. This is onext's proposal based on Blank's idea, not a template of his.
Are AI-simulated interviews useful for validating an idea?
As rehearsal, perhaps; as evidence, no. Blank reports that his students used AI instead of customers for validation, and in the new version of his class the live interviews grade the synthetic ones, never the reverse.
Is building fast with AI a mistake?
No. Blank does not criticise speed: he criticises mistaking a polished product for evidence. Building fast is still useful to show a customer something concrete and learn from their reaction. The mistake is treating as validated what has only been built.
What does this have to do with Spec-Driven Development?
It is the same logic at another level. In Spec-Driven Development (SDD), you first write what the code must do and then you build it. A business idea works the same way: first you write what has to be true, and then you build the minimum needed to check it.
Sources
- Steve Blank, "The Year AI Came For Us: Teaching Entrepreneurship Will Never Be The Same", Poets&Quants, 21 September 2026.
- Steve Blank, "AI Killed The MVP – Long Live The IUP", Poets&Quants, 24 September 2026.
- Steve Blank, "The World Outside The Classroom Changed, The Class Didn't", Poets&Quants, 29 September 2026.
- Steve Blank, "Lean LaunchPad: The Next Generation", Poets&Quants, 1 October 2026.
- Eric Ries, "Minimum Viable Product: a guide", Startup Lessons Learned, 3 August 2009.
- The table and the three hypothesis questions are onext's own work.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →