Hace unos años, enseñar un producto que funcionaba era una señal de que el equipo había resuelto algo difícil. Hoy un agente de código lo hace en días. La señal se ha quedado sin valor, y muchos equipos todavía no lo han notado.
La tesis de esta pieza: con IA, la disciplina de una startup pasa de la construcción a la hipótesis. Antes de la primera línea hay que dejar escrito qué se cree, qué lo desmentiría y qué se va a comprobar con clientes reales. Una demo que convence sola no es una prueba.
Lo que vio Steve Blank en su clase de Stanford
Steve Blank, una de las figuras del movimiento lean startup, lleva años enseñando a fundar empresas en Stanford con su clase Lean LaunchPad. En septiembre de 2026 contó qué pasó en la edición de primavera: los estudiantes llegaron el primer día con productos completos, y el equipo docente se alegró. Duró poco.
Según Blank, los estudiantes usaron la IA en lugar de clientes para obtener aprendizajes y validar. Y esos productos «parecían progreso, pero dispararon el sesgo de confirmación y retrasaron los cambios de rumbo». El equipo había invertido en algo que funcionaba, y eso hacía más difícil aceptar que quizá no lo quería nadie.
Tres días después, Blank dio el paso siguiente: el producto mínimo viable había dejado de ser un artefacto útil para descubrir clientes y llegar a una propuesta de valor basada en evidencias. Por eso dejó de llamar MVP a esos productos del primer día. Ahora los llama Initial Untested Products: productos iniciales sin probar.
Límite Es lo que cuenta un profesor sobre una clase, no un estudio con muestra y grupo de control. Su valor está en el mecanismo que describe, no en una cifra. Y Blank no dice que construir rápido sea malo: dice que construir rápido ya no prueba nada.
Qué era un MVP, y por qué ya no basta
Eric Ries definió en 2009 el producto mínimo viable como la versión de un producto nuevo que permite al equipo reunir la máxima cantidad de aprendizaje validado sobre los clientes con el mínimo esfuerzo. La palabra importante nunca fue «producto». Era «aprendizaje».
Durante años, las dos cosas iban juntas porque construir era caro: para no gastar meses, se construía lo mínimo, y lo mínimo obligaba a hablar pronto con clientes. Esa restricción hacía buena parte del trabajo. Ahora, como escribe Blank en la tercera parte de su serie, los agentes escriben la mayor parte del código, una especificación se convierte en un producto que funciona en días y crear ya es barato para todos.
Cuando la restricción desaparece, el atajo aparece solo: si ya tengo el producto, ¿para qué salir a preguntar? Blank lo resume con una frase de su segunda parte: el primer día, casi todos los hechos importantes de un negocio son hipótesis. Un producto completo no cambia eso. Solo lo esconde mejor.
Si construir ya no cuesta, el producto deja de ser la prueba. La prueba vuelve a ser lo que siempre fue: lo que hacen los clientes reales cuando se lo enseñas.
Dónde se pone ahora la disciplina
En la cuarta parte de la serie, Blank explica cómo cambia su clase. Los equipos tienen que hacer al menos diez entrevistas reales antes de la primera sesión, y la mitad en persona. Las entrevistas simuladas con IA se permiten, pero las reales califican a las simuladas, nunca al revés. No hay demostraciones de producto completo hasta que el descubrimiento ha terminado, y hay puntos explícitos de seguir o cambiar para que un producto pulido no pueda ocupar el lugar de la evidencia.
Para comprobar la propuesta de valor, Blank sustituye el MVP por trozos pequeños del producto que llama snippets. Y el objetivo del equipo deja de ser genérico: conseguir uno o varios clientes que trabajen con ellos en el diseño.
Fuera del aula, la traducción para un fundador es directa: la parte del trabajo que antes se llevaba la construcción se va ahora a escribir y comprobar la hipótesis. Esta es la diferencia, en una tabla:
| Pregunta | Producto del primer día | Hipótesis por escrito |
|---|---|---|
| Qué demuestra | Que se puede construir | Qué tiene que ser verdad para que alguien pague |
| A quién convence | Al propio equipo, y a veces a quien ve la demo | A nadie todavía: está pensada para que la desmientan |
| Cuándo aparece el error | Tarde, cuando ya cuesta renunciar a lo construido | Pronto, en las primeras conversaciones con clientes |
| Qué se hace si falla | Se defiende el producto | Se cambia la hipótesis y se vuelve a probar |
Lectura propia de onext a partir de la serie de Steve Blank (septiembre y octubre de 2026)
Qué escribir antes de la primera línea
No hace falta un documento largo. Hace falta que, antes de pedirle nada a un agente, estén escritas tres cosas y que alguien que no sea el fundador las pueda leer:
- Qué creemos. Quién tiene el problema, cuál es exactamente y por qué pagaría por resolverlo. Sin adjetivos: una persona concreta con un problema concreto.
- Qué nos haría cambiar de idea. La señal que, si aparece, desmiente la hipótesis. Si no se puede escribir, la hipótesis no se puede comprobar.
- Qué vamos a comprobar, con quién y cuándo decidimos. Qué se enseña a los clientes, a cuántos y en qué fecha se decide seguir o cambiar.
Con eso escrito, construir rápido vuelve a ser una ventaja: se construye lo justo para enseñar algo concreto y aprender de la reacción. Cómo hacerlo sin hipotecar lo que venga después está en cómo lanzar un MVP rápido sin hipotecar el producto, y qué buscar en quien te ayude a construirlo, en el partner de desarrollo de una startup.
La misma lógica que una especificación
Esto no es nuevo para quien trabaja con agentes de código. En el desarrollo guiado por especificaciones (Spec-Driven Development, SDD), primero se escribe qué tiene que cumplir el código y después se construye; así el agente no decide por su cuenta qué se quería. Lo explicamos en qué es SDD y cómo mantiene el código controlado, y por qué recupera el análisis previo sin perder la entrega corta en lo mejor del waterfall y lo mejor de la agilidad.
La hipótesis de negocio es esa especificación un nivel más arriba: no dice qué tiene que hacer el código, sino qué tiene que ser verdad en el mercado. Y tiene el mismo enemigo. Un producto que nadie del equipo sabe por qué se construyó así se parece mucho a la deuda de comprensión del código que nadie sabe explicar. En una empresa ya establecida, la versión de esto es la tesis de valor que conviene pedirle a un equipo antes de invertir en IA.
Antes de construir
Si estás preparando tu primer producto y quieres contrastar con alguien de fuera qué hipótesis estás probando y cómo vas a saber si es cierta, hablemos. La conversación empieza por la hipótesis, no por el producto.
Preguntas frecuentes
¿La IA ha matado el MVP?
Ha matado una de sus funciones. El producto mínimo viable nació para aprender lo máximo sobre los clientes con el mínimo esfuerzo. Cuando un agente construye una versión completa en días, el esfuerzo deja de ser el límite, pero el aprendizaje sigue exigiendo clientes reales. Steve Blank dejó de llamar MVP a esos productos y los llama «productos iniciales sin probar».
¿Qué es un «Initial Untested Product»?
Es el nombre que Steve Blank da, en su serie de septiembre y octubre de 2026, a los productos que sus estudiantes de Stanford construyeron con IA desde el primer día. Parecen un MVP, pero no se han contrastado con ningún cliente: son un producto inicial sin probar, no una prueba de nada.
¿Qué tiene que incluir la hipótesis por escrito?
Tres cosas antes de la primera línea de código: qué se cree (quién tiene el problema, cuál es y por qué pagaría por resolverlo), qué lo desmentiría (una señal concreta que haría cambiar de idea) y qué se va a comprobar con clientes reales, con cuándo se decide seguir o cambiar. Es una propuesta de onext a partir de la idea de Blank, no una plantilla suya.
¿Sirven las entrevistas simuladas con IA para validar una idea?
Como ensayo, quizá; como prueba, no. Blank cuenta que sus estudiantes usaron la IA en lugar de clientes para validar, y en la nueva versión de su clase las entrevistas reales califican a las simuladas, nunca al revés.
¿Construir rápido con IA es un error?
No. Blank no critica la velocidad: critica confundir un producto pulido con una prueba. Construir rápido sigue siendo útil para enseñar algo concreto a un cliente y aprender de su reacción. El error es dar por validado lo que solo está construido.
¿Qué tiene que ver esto con Spec-Driven Development?
Es la misma lógica en otro nivel. En el desarrollo guiado por especificaciones (Spec-Driven Development, SDD), primero se escribe qué tiene que cumplir el código y después se construye. Con una idea de negocio pasa igual: primero se escribe qué tiene que ser verdad y después se construye lo mínimo para comprobarlo.
Fuentes
- Steve Blank, «The Year AI Came For Us: Teaching Entrepreneurship Will Never Be The Same», Poets&Quants, 21 de septiembre de 2026.
- Steve Blank, «AI Killed The MVP – Long Live The IUP», Poets&Quants, 24 de septiembre de 2026.
- Steve Blank, «The World Outside The Classroom Changed, The Class Didn't», Poets&Quants, 29 de septiembre de 2026.
- Steve Blank, «Lean LaunchPad: The Next Generation», Poets&Quants, 1 de octubre de 2026.
- Eric Ries, «Minimum Viable Product: a guide», Startup Lessons Learned, 3 de agosto de 2009.
- Las citas de fuentes en inglés están traducidas por onext. La tabla y las tres preguntas de la hipótesis son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →