La sigla se usa para todo y terminó significando "menos". Menos features, menos calidad, menos tiempo. Y así, el MVP pasó de ser una herramienta para aprender a ser una excusa para entregar algo que no está.
Vale la pena recuperar qué era.
Qué es en realidad
Un producto mínimo viable es la forma más barata de contestar una pregunta. Nada más que eso.
Lo importante es que primero hay una pregunta. Si no sabés qué querés averiguar, no estás haciendo un MVP: estás haciendo una versión 1 chiquita, que es otra cosa y se justifica distinto.
Preguntas reales que hemos ayudado a contestar:
- ¿La gente va a comprar esto online, o siempre va a querer hablar con alguien?
- ¿El proceso manual que hacemos hoy se puede automatizar sin romper la calidad?
- ¿Los clientes van a cargar sus datos ellos mismos, o va a haber que hacerlo por ellos igual?
Cada una define un MVP distinto. Y ninguna necesita un producto completo para contestarse.
Mínimo no es "de mala calidad"
Acá está el malentendido más caro.
Mínimo es en alcance: menos cosas. No en calidad: las pocas cosas que hace las tiene que hacer bien.
Un MVP de tienda puede tener cinco productos y ningún filtro. Lo que no puede tener es un checkout que a veces cobra dos veces. Porque entonces lo que aprendés no es si la gente compra: es que la gente no vuelve cuando le cobrás mal.
El recorte va por el lado de qué hace, nunca de qué tan bien lo hace.
El truco de recortar de verdad
Cuando pedimos "sacá todo lo que no sea imprescindible", la lista que vuelve suele seguir teniendo todo. Porque todo parece imprescindible visto desde adentro.
La pregunta que sí funciona: ¿qué pasa si esto no está? No "¿sirve?" —todo sirve— sino qué se rompe concretamente si falta.
Muchas veces la respuesta es "lo hace alguien a mano". Y ahí está la clave: en un MVP, hacerlo a mano es una feature válida. Si tenés veinte pedidos por semana, alguien puede procesarlos a mano mientras aprendés si el negocio existe. Automatizarlo antes de saberlo es construir sobre una hipótesis.
Lo que casi nunca se recorta
Hay cosas que aunque el alcance sea mínimo tienen que estar, porque sin ellas el MVP no puede cumplir su función de enseñarte algo:
- Medir. Un MVP sin analítica no contesta ninguna pregunta. Es la parte que más se olvida y la que le da sentido a todo el ejercicio.
- No perder datos. Si el experimento sale bien, esos datos son el comienzo de lo que sigue.
- Seguridad básica. "Es sólo un MVP" no es un argumento cuando se filtran los datos de tus primeros clientes, que además son los que más te importan.
Cómo termina
Un MVP tiene tres finales posibles y los tres son buenos:
- La hipótesis se confirma y ahora sabés qué construir en serio.
- La hipótesis se cae y te ahorraste el proyecto entero. Este es el más valioso y el que peor se recibe.
- Aprendés que la pregunta estaba mal y aparece la que había que hacer.
El único mal final es que quede como está: en producción, sin haber contestado nada, creciendo a parches encima de decisiones que se tomaron para un experimento. Eso ya no es un MVP: es deuda técnica con buena prensa.
Por eso, cuando arrancamos uno, la conversación incluye qué pasa después. Si la respuesta es "y bueno, lo seguimos usando", no es un MVP. Es una versión 1 con poco presupuesto, y conviene decirlo con todas las letras y diseñarla como tal.
En nuestros casos hay proyectos que arrancaron así. Si tenés una idea y no sabés por dónde empezar, escribinos: a veces la mejor primera versión es más chica de lo que pensás.
