Qué es un MVP y por qué casi todos los que se lanzan no lo son

El término lleva veinte años en circulación y ha acabado significando “la primera versión”. Con ese significado no sirve para nada, porque toda primera versión es la primera versión.

Un MVP es otra cosa, y la diferencia tiene consecuencias de dinero.

Las dos condiciones

Mínimo: lo más pequeño que puede ser sin dejar de responder la pregunta.

Viable: un cliente real puede resolver un problema real con él. No una demo, no una simulación. Alguien lo usa en su trabajo y consigue algo.

La palabra que falta en la sigla y que hace todo el trabajo es la pregunta. Un MVP sin una pregunta explícita escrita antes de empezar no es un MVP, es una versión pequeña. Y una versión pequeña no enseña nada, porque cuando los resultados llegan no hay criterio para interpretarlos.

Preguntas válidas: ¿lo siguen usando a las cuatro semanas? ¿pagan cuando termina la prueba? ¿lo usan para lo que pensábamos o para otra cosa?

Pregunta no válida: ¿les gusta?

Las cuatro versiones falsas

El producto entero pero peor. Todas las funcionalidades planeadas, cada una a medias. Es lo contrario de un MVP: máximo alcance, mínima calidad. No responde ninguna pregunta porque cuando algo falla no sabes si es la idea o la ejecución.

La demo con nombre de MVP. No lo usa nadie de verdad, se enseña en reuniones. Eso es un prototipo, y está bien que lo sea, pero cuesta una décima parte y conviene no pagarlo como un MVP. La comparación completa está en prototipo o MVP: cuál necesitas.

El MVP eterno. Se lanzó hace dos años y sigue llamándose MVP para justificar que le falten cosas. La etiqueta pasó de ser una fase a ser una excusa.

El MVP sin pregunta. El más común. Se construye, se lanza, se mira el uso y se saca la conclusión que a cada uno le convenía. Sin criterio previo, los datos confirman lo que ya pensabas.

Cómo se decide qué entra

La regla que funciona: una sola cosa que la persona pueda terminar.

No tres funcionalidades a medias. Un camino completo, de principio a fin, con sus estados de error y sus casos raros resueltos. Un MVP que hace una cosa bien enseña muchísimo; uno que hace cuatro cosas a medias solo enseña que estaba a medias.

Para elegir cuál, la pregunta es cuál es el momento en que el cliente obtiene algo que le sirve fuera de tu producto. Ese es el camino que tiene que estar entero. Todo lo demás puede esperar, hacerse a mano por detrás o directamente no existir.

Lo que sí puede faltar

En un MVP bien acotado pueden faltar el panel de administración, la facturación automática, la configuración avanzada, las integraciones, los informes y prácticamente todo lo que no esté en ese camino. Muchas de esas cosas se pueden hacer a mano durante meses sin que el cliente lo note ni le importe.

Lo que no puede faltar es que funcione de verdad para el caso que sí cubre. Un MVP con un camino roto no mide la idea, mide la implementación.

Lo que hay que hacer antes

Un MVP responde si lo siguen usando. Es una pregunta cara y llega la tercera.

Antes está saber qué problema resuelves y para quién, que es discovery y cuesta semanas, no meses. Y después está saber si lo quieren y lo entienden, que es lo que responde un prototipo probado con gente real.

Llegar al MVP sin esas dos respuestas significa gastar meses para averiguar algo que se averiguaba en semanas. El método de la primera fase está en qué es un sprint de discovery.

Cuándo sí toca ir directo

Cuando ya tienes clientes pagando por el problema resuelto de otra forma, normalmente a mano o con hojas de cálculo.

Ahí la demanda está validada por la vía más fiable que existe, que es que alguien ya paga. Lo que no sabes es si aguantan el cambio a tu herramienta, y eso solo se mide con producto real.

Después del lanzamiento

El MVP no termina cuando se lanza, termina cuando contestas la pregunta. Y eso implica decidir de antemano cuánto vas a esperar y qué número te haría cambiar de opinión.

Sin ese compromiso previo, lo que pasa siempre es lo mismo: los resultados son ambiguos, alguien propone darle un poco más de tiempo, y el MVP se convierte en el producto por inercia.

Si estás en el punto de decidir el alcance, la definición para desarrollo deja el problema, los flujos y la lista de trabajo listos en tres semanas. Y si lo que necesitas es enseñar algo antes de construirlo, eso es el prototipo validable.