Fa uns anys, ensenyar un producte que funcionava era un senyal que l'equip havia resolt una cosa difícil. Avui un agent de codi ho fa en dies. El senyal s'ha quedat sense valor, i molts equips encara no se n'han adonat.
La tesi d'aquesta peça: amb IA, la disciplina d'una startup passa de la construcció a la hipòtesi. Abans de la primera línia cal deixar escrit què es creu, què ho desmentiria i què es comprovarà amb clients reals. Una demo que convenç tota sola no és una prova.
El que va veure Steve Blank a la seva classe de Stanford
Steve Blank, una de les figures del moviment lean startup, fa anys que ensenya a fundar empreses a Stanford amb la seva classe Lean LaunchPad. El setembre de 2026 va explicar què va passar a l'edició de primavera: els estudiants van arribar el primer dia amb productes complets, i l'equip docent se'n va alegrar. Va durar poc.
Segons Blank, els estudiants van fer servir la IA en lloc de clients per obtenir aprenentatges i validar. I aquests productes «semblaven progrés, però van disparar el biaix de confirmació i van endarrerir els canvis de rumb». L'equip havia invertit en una cosa que funcionava, i això feia més difícil acceptar que potser no la volia ningú.
Tres dies després, Blank va fer el pas següent: el producte mínim viable havia deixat de ser un artefacte útil per descobrir clients i arribar a una proposta de valor basada en evidències. Per això ha deixat de dir MVP a aquests productes del primer dia. Ara en diu Initial Untested Products: productes inicials sense provar.
Límit És el que explica un professor sobre una classe, no un estudi amb mostra i grup de control. El seu valor és en el mecanisme que descriu, no en una xifra. I Blank no diu que construir ràpid sigui dolent: diu que construir ràpid ja no prova res.
Què era un MVP, i per què ja no n'hi ha prou
Eric Ries va definir el 2009 el producte mínim viable com la versió d'un producte nou que permet a l'equip reunir la màxima quantitat d'aprenentatge validat sobre els clients amb el mínim esforç. La paraula important no va ser mai «producte». Era «aprenentatge».
Durant anys, les dues coses anaven juntes perquè construir era car: per no gastar mesos, es construïa el mínim, i el mínim obligava a parlar aviat amb clients. Aquesta restricció feia bona part de la feina. Ara, com escriu Blank a la tercera part de la seva sèrie, els agents escriuen la major part del codi, una especificació es converteix en un producte que funciona en dies i crear ja és barat per a tothom.
Quan la restricció desapareix, la drecera apareix sola: si ja tinc el producte, per què he de sortir a preguntar? Blank ho resumeix amb una frase de la segona part: el primer dia, gairebé tots els fets importants d'un negoci són hipòtesis. Un producte complet no canvia això. Només ho amaga millor.
Si construir ja no costa, el producte deixa de ser la prova. La prova torna a ser el que sempre va ser: el que fan els clients reals quan els ho ensenyes.
On es posa ara la disciplina
A la quarta part de la sèrie, Blank explica com canvia la seva classe. Els equips han de fer almenys deu entrevistes reals abans de la primera sessió, i la meitat en persona. Les entrevistes simulades amb IA es permeten, però les reals qualifiquen les simulades, mai al revés. No hi ha demostracions de producte complet fins que el descobriment s'ha acabat, i hi ha punts explícits de continuar o canviar perquè un producte polit no pugui ocupar el lloc de l'evidència.
Per comprovar la proposta de valor, Blank substitueix l'MVP per trossos petits del producte que anomena snippets. I l'objectiu de l'equip deixa de ser genèric: aconseguir un o més clients que hi treballin en el disseny.
Fora de l'aula, la traducció per a un fundador és directa: la part de la feina que abans s'enduia la construcció ara se'n va a escriure i comprovar la hipòtesi. Aquesta és la diferència, en una taula:
| Pregunta | Producte del primer dia | Hipòtesi per escrit |
|---|---|---|
| Què demostra | Que es pot construir | Què ha de ser veritat perquè algú pagui |
| A qui convenç | Al mateix equip, i de vegades a qui veu la demo | A ningú encara: està pensada perquè la desmenteixin |
| Quan apareix l'error | Tard, quan ja costa renunciar al que s'ha construït | Aviat, a les primeres converses amb clients |
| Què es fa si falla | Es defensa el producte | Es canvia la hipòtesi i es torna a provar |
Lectura pròpia d'onext a partir de la sèrie de Steve Blank (setembre i octubre de 2026)
Què cal escriure abans de la primera línia
No cal un document llarg. Cal que, abans de demanar res a un agent, hi hagi escrites tres coses i que algú que no sigui el fundador les pugui llegir:
- Què creiem. Qui té el problema, quin és exactament i per què pagaria per resoldre'l. Sense adjectius: una persona concreta amb un problema concret.
- Què ens faria canviar d'idea. El senyal que, si apareix, desmenteix la hipòtesi. Si no es pot escriure, la hipòtesi no es pot comprovar.
- Què comprovarem, amb qui i quan decidim. Què s'ensenya als clients, a quants i en quina data es decideix continuar o canviar.
Amb això escrit, construir ràpid torna a ser un avantatge: es construeix just el necessari per ensenyar una cosa concreta i aprendre de la reacció. Com fer-ho sense hipotecar el que vingui després és a com llançar un MVP ràpid sense hipotecar el producte, i què cal buscar en qui t'ajudi a construir-lo, a el partner de desenvolupament d'una startup.
La mateixa lògica que una especificació
Això no és nou per a qui treballa amb agents de codi. En el desenvolupament guiat per especificacions (Spec-Driven Development, SDD), primer s'escriu què ha de complir el codi i després es construeix; així l'agent no decideix pel seu compte què es volia. Ho expliquem a què és l'SDD i com manté el codi controlat, i per què recupera l'anàlisi prèvia sense perdre el lliurament curt, a el millor del waterfall i el millor de l'agilitat.
La hipòtesi de negoci és aquesta especificació un nivell més amunt: no diu què ha de fer el codi, sinó què ha de ser veritat al mercat. I té el mateix enemic. Un producte que ningú de l'equip sap per què es va construir així s'assembla molt al deute de comprensió del codi que ningú sap explicar. En una empresa ja establerta, la versió d'això és la tesi de valor que convé demanar a un equip abans d'invertir en IA.
Abans de construir
Si estàs preparant el teu primer producte i vols contrastar amb algú de fora quina hipòtesi estàs provant i com sabràs si és certa, parlem-ne. La conversa comença per la hipòtesi, no pel producte.
Preguntes freqüents
La IA ha matat l'MVP?
N'ha matat una de les funcions. El producte mínim viable va néixer per aprendre el màxim sobre els clients amb el mínim esforç. Quan un agent construeix una versió completa en dies, l'esforç deixa de ser el límit, però l'aprenentatge continua exigint clients reals. Steve Blank ha deixat de dir MVP a aquests productes i ara en diu «productes inicials sense provar».
Què és un «Initial Untested Product»?
És el nom que Steve Blank dona, a la seva sèrie de setembre i octubre de 2026, als productes que els seus estudiants de Stanford van construir amb IA des del primer dia. Semblen un MVP, però no s'han contrastat amb cap client: són un producte inicial sense provar, no una prova de res.
Què ha d'incloure la hipòtesi per escrit?
Tres coses abans de la primera línia de codi: què es creu (qui té el problema, quin és i per què pagaria per resoldre'l), què ho desmentiria (un senyal concret que faria canviar d'idea) i què es comprovarà amb clients reals, amb quan es decideix continuar o canviar. És una proposta d'onext a partir de la idea de Blank, no una plantilla seva.
Serveixen les entrevistes simulades amb IA per validar una idea?
Com a assaig, potser; com a prova, no. Blank explica que els seus estudiants van fer servir la IA en lloc de clients per validar, i a la nova versió de la seva classe les entrevistes reals qualifiquen les simulades, mai al revés.
Construir ràpid amb IA és un error?
No. Blank no critica la velocitat: critica confondre un producte polit amb una prova. Construir ràpid continua sent útil per ensenyar una cosa concreta a un client i aprendre de la seva reacció. L'error és donar per validat el que només està construït.
Què hi té a veure el Spec-Driven Development?
És la mateixa lògica en un altre nivell. En el desenvolupament guiat per especificacions (Spec-Driven Development, SDD), primer s'escriu què ha de complir el codi i després es construeix. Amb una idea de negoci passa el mateix: primer s'escriu què ha de ser veritat i després es construeix el mínim per comprovar-ho.
Fonts
- Steve Blank, «The Year AI Came For Us: Teaching Entrepreneurship Will Never Be The Same», Poets&Quants, 21 de setembre de 2026.
- Steve Blank, «AI Killed The MVP – Long Live The IUP», Poets&Quants, 24 de setembre de 2026.
- Steve Blank, «The World Outside The Classroom Changed, The Class Didn't», Poets&Quants, 29 de setembre de 2026.
- Steve Blank, «Lean LaunchPad: The Next Generation», Poets&Quants, 1 d'octubre de 2026.
- Eric Ries, «Minimum Viable Product: a guide», Startup Lessons Learned, 3 d'agost de 2009.
- Les cites de fonts en anglès estan traduïdes per onext. La taula i les tres preguntes de la hipòtesi són elaboració pròpia d'onext.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →