La mayoría de los MVPs no lo son

La sigla se ha estirado hasta significar cualquier cosa que un fundador lanza con prisa. La versión que sobrevive es, sobre todo, un ejercicio de marketing. La que ayuda es una apuesta falsable — y casi nadie escribe la apuesta antes de empezar.

Hace unos meses un fundador nos mostró su MVP. Era una aplicación web funcional, construida en siete semanas por un freelancer que encontró en Workana. Tenía autenticación, dashboard, tres flujos centrales, panel de admin e integración con Stripe. Le costó US$ 7.000. Estaba orgulloso, y nos había convocado porque quería ayuda para “escalarlo”. Le hicimos una pregunta: ¿qué te enseñó este MVP que no supieras antes?

Hizo una pausa. Dijo que a los clientes les gustó. Después dijo que tres se habían registrado. Después dijo que dos de los tres eran amigos. Y nos quedamos en silencio un minuto, porque ambos llegamos a la misma conclusión al mismo tiempo. El MVP no había validado nada. Había construido algo. Son cosas distintas.

Eric Ries acuñó “minimum viable product” en 2008. La frase aparece en The Lean Startup con una definición específica y cuidadosa — la versión de un producto nuevo que permite al equipo recoger la mayor cantidad de aprendizaje validado sobre clientes con el menor esfuerzo posible. Léelo dos veces. La unidad de salida no es un producto. La unidad de salida es aprendizaje. Todo lo demás es efecto secundario.

Casi nadie que use el término en 2026 lo usa como Ries lo entendía. La sigla se ha estirado hasta significar cualquier cosa que un fundador lanza con prisa, y la versión que gana en LinkedIn es sobre todo un ejercicio de marketing — una app funcional, un tweet de lanzamiento, una captura de tres registros y un post sobre “validar product-market fit”. Eso no es validación. Es teatro vestido con vocabulario de validación.

La corrupción es estructural

La razón por la que el MVP dejó de funcionar como mecanismo de aprendizaje no es que los fundadores se hayan vuelto perezosos. Es que el costo de construir el artefacto cayó más rápido que el costo de averiguar qué debería testear ese artefacto. En 2008, construir una aplicación web funcional desde cero requería seis ingenieros y cuatro meses. La fricción obligaba al fundador a pensar mucho qué construir, porque construir cualquier cosa era caro. En 2018, con no-code y freelancers baratos, el costo se desplomó. En 2024, con desarrollo asistido por IA, se desplomó otra vez.

Lo que no cayó — lo que no podía caer — fue el trabajo cognitivo de decidir qué testear. Definir la afirmación falsable, diseñar el test que de hecho la falsearía, elegir la métrica, elegir la población, elegir el umbral: ese trabajo tiene la misma dificultad en 2026 que en 2008. No es un problema de herramientas. Es un problema de pensamiento.

Pasó algo extraño. El costo de construir cayó casi a cero, mientras el costo de decidir qué construir se mantuvo constante. El camino de menor resistencia pasó a ser: salta el pensar, empieza a construir. Fundadores que antes habrían sido obligados por la economía a tener claridad ahora pueden saltarse la etapa entera. El MVP dejó de ser un test y se convirtió en una construcción. Y el vocabulario quedó — porque “MVP” sigue sonando disciplinado, aunque el trabajo no muestre nada de la disciplina que el término implicaba originalmente.

El resultado es una categoría de artefacto que llamamos MVP teatral. Parece un MVP. Cuesta lo que un MVP costaría. Se lanza en el plazo de un MVP. Pero no le dice nada al fundador que ya no supiera, porque ninguna afirmación se especificó antes de empezar a construir.

El test que importa: escribe la apuesta primero

El único cambio que convierte un MVP teatral en uno real es brutalmente simple. Antes de cualquier línea de código, el fundador escribe una frase:

“Si, para [fecha], no hemos visto [comportamiento específico] de [población específica], en [umbral específico], estamos equivocados respecto a [afirmación específica].”

Esta frase no es un eslogan. Es un contrato. Compromete al fundador con una afirmación falsable y con una definición de fracaso. Las dos mitades importan. Sin la afirmación, no hay nada que testear. Sin la definición de fracaso, no hay aprendizaje — cualquier resultado puede racionalizarse como “prometedor”.

Tres fundadores con los que trabajamos el año pasado usaron una versión de esa frase antes de definir la primera construcción. Uno escribió: “Si, en los sesenta días posteriores al lanzamiento, menos del 30% de las clínicas pequeñas que onboardeamos han iniciado sesión en el dashboard al menos tres veces en su segundo mes, la tesis de cuidados asincrónicos es errónea y debemos pivotar.” Sesenta días después, el número era 11%. No lanzaron una v2. Volvieron a entrevistar a las clínicas, descubrieron que el cuello de botella no era el interés por cuidados asincrónicos, y reconstruyeron en torno a un flujo totalmente distinto. Ese MVP hizo exactamente lo que un MVP debe hacer. No entregó un producto para escalar. Entregó una tesis para dejar de construir encima.

Los otros dos fundadores se negaron a escribir la frase. Preguntamos. Dijeron que no podían elegir un número porque no sabían qué número era razonable. Señalamos que no saber qué número es razonable es exactamente el problema que el MVP debe resolver. Si no puedes articular cómo se ve el éxito antes de empezar, no vas a poder reconocer éxito o fracaso al terminar. Solo podrás racionalizar el resultado que te tocó.

Por qué la frase es la parte difícil

La razón por la que la mayoría de los fundadores se salta la frase es que la frase los obliga a confrontar las partes del negocio que dejaron vagas. Para escribir una afirmación falsable, hay que conocer al cliente con suficiente especificidad para nombrarlo. Hay que conocer el comportamiento con suficiente especificidad para instrumentarlo. Hay que conocer el umbral con suficiente especificidad para defenderlo. Ninguna de esas es una habilidad técnica. Todas son disciplina comercial.

Por eso el problema del MVP rara vez es un problema de ingeniería. Es un problema de claridad comercial disfrazado de problema de construcción. El fundador contrata a un desarrollador porque al desarrollador se le puede contratar. El trabajo de claridad no tiene un proveedor obvio. Así que el fundador compra lo que se puede comprar, lanza lo que se puede lanzar, y la pregunta original — ¿qué estamos testando? — se va abandonando silenciosamente por el camino.

Un buen partner de ingeniería es la penúltima línea de defensa contra esto. Un buen partner de ingeniería se niega a empezar a codear hasta que el fundador haya respondido a las cuatro preguntas: ¿qué afirmación estamos testando, qué comportamiento la falsearía, cuál es la población, cuál es el umbral? La última línea de defensa es el propio fundador. Si el partner no empuja y el fundador no escribe la frase, lo que se lanza es, en el mejor de los casos, una aplicación funcional, y el fundador descubre un año después que gastó cuarenta mil dólares aprendiendo nada.

Lo que un MVP no es

El punto de escribir todo esto no es ser puristas con el término. Es señalar un error de categoría que cuesta runway a los fundadores. Así que, para evitar dudas:

Un MVP no es un producto pequeño. Puede ser pequeño o grande; lo que importa es si está montado para testear algo. Un MVP no es un lanzamiento. Lanzar es una actividad aparte, a veces parte del test, a veces no. Un MVP no es “la cosa que lanzamos antes de construir el producto real”. Si lo que lanzas no cambia una decisión real basada en su resultado, llamarlo MVP es solo prestarle dignidad al término original.

Tampoco es el máximo que se puede construir en tres meses. La mayoría de los fundadores, cuando se les obliga a reducir alcance, reducen en el eje equivocado — recortan la pulidez y conservan la amplitud. Un MVP de verdad recorta la amplitud, con fuerza, y conserva la pulidez suficiente para que la fricción del cliente real sea observable. Ocho funciones a medio hacer te dicen menos que dos funciones bien hechas, porque la fricción del cliente es la variable, no la superficie.

La versión del término que valdría conservar

Hemos pensado en tirar la sigla a la basura. Está tan corrompida que defenderla cansa. Pero hay un uso que sigue mereciéndose el espacio, y la disciplina de distinguirlo vale más que el trabajo de inventar otra palabra.

La versión que merece quedarse es el artefacto más pequeño que, puesto frente a un cliente real, genera un sí o un no a la hipótesis pendiente más cara. Ese es el test. Tres cosas tienen que ser ciertas para que el artefacto califique. Tiene que ser lo bastante pequeño como para que la construcción no supere al aprendizaje. Tiene que estar frente a un cliente real — no un amigo, ni un diseñador, ni el equipo. Y tiene que producir una respuesta — sí o no — que cambie lo que el fundador construye a continuación.

Si tu MVP no cambia lo que construyes después, no es uno. Sea lo que sea, no es de lo que hablaba Ries. Y la pregunta que vale la pena hacerse, antes de escribir la spec, es la misma que nuestro amigo en São Paulo no supo responder: ¿qué me enseñaría esto que ya no sé?

Si no puedes decirlo, no construyas. El MVP más barato es el que no lanzas — porque escribir la frase es lo que de verdad le debías a la empresa.