No construyas un MVP. Construye algo que pueda sobrevivir.

Hace poco vi una escena demasiado común y demasiado cara.

Un equipo celebraba el lanzamiento de su "MVP" como si hubiera cruzado una meta. Habían salido rápido, habían mostrado avance, habían calmado a los socios, habían puesto algo allá afuera. Y, sin embargo, en la misma reunión de celebración ya se notaba el problema. Cada cambio nuevo parecía una cirugía. Cada aprendizaje dolía. Cada ajuste de pricing rompía una parte del flujo. Cada intento de pivotear obligaba a tocar piezas que nunca debieron quedar pegadas entre sí.

No habían construido un primer producto.

Habían construido una trampa con demo.

Y sí, parece que la conversación sobre el MVP está envejeciendo mal. No porque validar rápido sea mala idea. Eso sigue siendo correcto. El problema es otro. El problema es que se confunde "mínimo" con "precario", "viable" con "más o menos funciona", y "salir rápido" con "endeudarse antes de entender qué están construyendo".

El problema no es lanzar poco. El problema es lanzar algo torcido.

Hay una diferencia brutal entre una primera versión enfocada y una primera versión improvisada. La primera sabe qué está probando. La segunda solo quiere existir lo antes posible.

Marty Cagan lo dijo hace años de una forma que todavía le pega al centro del asunto: la pregunta importante no es si alguien podría usar tu producto. La pregunta es si alguien querría usarlo. En su distinción entre minimal product y viable product, el golpe no va contra la velocidad. Va contra la ilusión. Porque un producto puede funcionar, verse decente, pasar una demo y seguir sin tener ninguna posibilidad real de adopción.

Eso ya sería suficiente para incomodarnos. Pero en 2026 el problema es peor.

Hoy construir se volvió más barato. Prototipar se volvió obscenamente rápido. Según SVPG, no es raro que un equipo serio de discovery produzca 10 a 20 prototipos por semana cuando está tratando de aprender de verdad. Y ahí hay una pista importante: cuando prototipar se vuelve tan barato, la conversación deja de ser "cómo construimos más" y pasa a ser "qué merece convertirse en producto".

Si sigues usando "MVP" para nombrar cualquier cosa que salga a producción rápido, estás mezclando dos trabajos completamente distintos: construir para aprender y construir para sostener.

Construir para aprender no es lo mismo que construir para quedarse

Esta es la confusión que sale carísima.

En discovery, construyes para reducir incertidumbre. Prototipas para entender valor, usabilidad, factibilidad, negocio. Ahí sirven los artefactos desechables, los experimentos raros, los atajos conscientes, los flujos incompletos, incluso el humo bien puesto si te permite aprender una verdad importante.

En delivery, en cambio, ya no estás probando una intuición. Estás creando una pieza que debe tolerar carga, errores, soporte, cambios de contexto, pricing nuevo, integraciones, operaciones, seguridad, datos reales y usuarios de verdad haciendo cosas que nunca imaginaste.

Es otro deporte.

Lo absurdo es que muchos equipos usan la misma palabra para ambos momentos y luego se sorprenden cuando el supuesto MVP se transforma en un pequeño monstruo. Un monstruo que nadie quiere reescribir porque "ya está andando", pero que nadie puede escalar, corregir o pivotear sin romper tres capas de decisiones apuradas.

Ese es el pecado original de muchísimos productos nuevos: se confunde el primer aprendizaje con el primer cimiento.

Yo no lo llamaría MVP.

No porque la etiqueta esté prohibida. Porque ya se llenó de malos hábitos.

La palabra, en teoría, prometía foco. En la práctica, demasiadas veces termina justificando apuro, deuda prematura y productos que nacen cansados.

Por eso prefiero pensar en una primera versión que pueda evolucionar.

No es el producto mínimo posible.

Es el producto más pequeño que ya nace con una lógica clara, una arquitectura respirable y una capacidad real de cambiar sin autodestruirse.

• no optimizas solo por velocidad inicial;
• optimizas por velocidad de aprendizaje más velocidad de cambio;
• diseñas el núcleo antes que los adornos;
• separas lo que estás validando de lo que luego tendrá que escalar;
• evitas acoplar decisiones que probablemente van a mutar en los próximos tres meses.

En otras palabras: no sales con una miniatura de producto. Sales con una primera especie.

Una especie capaz de mutar sin dejar de reconocerse.

La resiliencia no es un lujo técnico. Es una decisión de producto.

Cuando digo resiliencia no estoy hablando de sobreingeniería ni de una obsesión técnica vacía. Estoy hablando de algo mucho más brutal: de si tu primera versión fue pensada para absorber aprendizaje o para defenderse de él.

Porque eso es lo que demasiados MVP ignoran. Construyen como si el aprendizaje fuera a terminar pronto. Como si después del lanzamiento las preguntas duras se acabaran. Como si bastara con salir y luego recién pensar.

Pero la realidad es al revés.

No necesitas una versión mínima. Necesitas una versión que no se rompa cada vez que la realidad te contradiga.

Cuando lanzas, recién empiezan las preguntas caras.

• ¿Qué parte del flujo realmente importa?
• ¿Qué comportamiento del usuario contradice tu historia favorita?
• ¿Qué promesa comercial no resiste uso real?
• ¿Qué parte del producto necesita doblarse sin quebrarse?

Si tu primera versión no fue pensada para convivir con esas preguntas, no lanzaste más inteligente. Lanzaste más frágil.

El error más común: enamorarse de la feature antes de entender el sistema

La mayoría de las ideas nuevas no mueren por falta de entusiasmo. Mueren porque se construyen como features aisladas, no como sistemas con una hipótesis detrás.

Se arranca por la pantalla visible. Por el flujo que se puede mostrar. Por el onboarding que se ve bonito en una demo. Y nadie pregunta cuál es la unidad mínima de valor real. Nadie separa qué parte del producto debe quedar fija y cuál debe seguir blanda. Nadie define dónde puede cambiar el modelo sin obligarte a rehacer toda la experiencia.

Por eso me gusta tanto la lógica del "build to learn vs build to earn". Porque te obliga a decidir en qué modo estás. Si estás aprendiendo, no finjas que tu prototipo ya es producto. Si estás construyendo producto, no te comportes como si siguieras jugando con humo.

Esa claridad evita dos desastres igual de frecuentes: productos que salen a producción demasiado inmaduros para sostenerse, y productos que se sobreconstruyen antes de haber validado una razón real para existir.

La gracia está en otro lugar: descubrir rápido, sí; productizar con criterio, también.

Lo que deberíamos construir primero no es un MVP. Es un núcleo.

Un núcleo de valor.

Un núcleo de arquitectura.

Un núcleo de aprendizaje.

A veces eso se parece a un prototipo con datos vivos. A veces a un slice vertical muy delgado, pero completo. A veces a un flujo limitado que ya toca el problema real de punta a punta. No necesitas todo. Pero sí necesitas que lo que sí construyas tenga sentido bajo presión.

Basecamp lo explica bien cuando insiste en integrar una pieza real, terminarla y usarla para subir la montaña en vez de dispersarse en cien tareas paralelas. Y la idea del walking skeleton, popularizada en el mundo de software por gente como Martin Fowler, apunta a algo igual de valioso: una tajada mínima, real, integrable y desplegable, que te deja probar el sistema entero antes de llenarlo de músculo.

Esa idea me parece muchísimo más fértil que la del MVP clásico. Porque no te pregunta: "¿qué es lo mínimo que puedo sacar?" Te pregunta algo mejor: ¿cuál es la pieza más pequeña que ya me enseña cómo este producto va a vivir, crecer y cambiar?

Ese matiz cambia todo.

Cambia cómo diseñas.

Cambia cómo priorizas.

Cambia a quién metes temprano en la conversación.

Y cambia cuánto te va a costar aprender después.

Si tu "MVP" no tolera pivotes, en realidad era una maqueta cara

Voy a decirlo más duro.

Si tu primer producto no soporta cambios de pricing, de canal, de segmento, de promesa o de flujo principal sin pedirte cirugía mayor, entonces no construiste una base. Construiste una puesta en escena.

Eso puede servir para vender humo, levantar una ronda o ganar tiempo político dentro de una empresa. Pero no sirve para aprender con dignidad.

Y aprender con dignidad debería importarnos más.

Porque casi ninguna idea llega viva a mercado en su forma original. Cambia el cliente. Cambia el uso. Cambia la propuesta. Cambia el ticket. Cambia el canal. Cambia incluso el problema que pensabas resolver. Si tu producto inicial no estaba preparado para esa conversación con la realidad, entonces no era un primer paso. Era un costo hundido disfrazado de agilidad.

Tal vez el lenguaje ya nos quedó chico

A veces una palabra se vuelve peligrosa no porque esté mal en su origen, sino porque el mercado la llena de malos hábitos.

Eso le pasó a MVP.

Durante años sirvió para pelear contra el perfeccionismo. Bien. Hacía falta. Pero después se convirtió en coartada para productos apurados, experiencias torcidas y decisiones técnicas que envejecen peor que la idea que las justificó.

Por eso yo la dejaría descansar un rato.

Y hablaría, mejor, de una primera versión que pueda evolucionar. De un núcleo vivo. De algo que no nazca roto en nombre de la velocidad.

Porque salir es fácil de romantizar.

Seguir sin quebrarte ya es otra liga.