← Volver al blog

Qué es un MVP y qué no (casi todos lo definen mal)

"Hagamos un MVP" es una de esas frases que todos aceptan en una reunión y que cada uno entiende distinto. Y cuando hay plata de por medio, esa diferencia de interpretación es la que después se discute por mail.

Si estás por contratar un desarrollo y te ofrecen un MVP, esto te sirve para saber qué estás comprando.

Las dos palabras que importan

Producto Mínimo Viable. Casi siempre se discute la primera y se ignora la segunda.

Mínimo significa que hace pocas cosas. Una sola, idealmente.

Viable significa que esa cosa funciona de verdad. Que se puede usar, que no pierde datos, que si cobra plata la cobra bien.

El error frecuente es tratar "mínimo" como permiso para que también sea frágil. No lo es. Un MVP puede hacer una sola cosa, pero esa cosa tiene que estar terminada. Si tu MVP procesa pagos, los pagos no pueden fallar el 10% de las veces. Podés no tener reportes, no tener app móvil, no tener panel de administración — pero lo que hay, anda.

La analogía que se usa siempre es buena: un monopatín es un MVP de un auto, porque te lleva de A a B. Media carrocería sin motor no es un MVP de nada. Las dos son "mínimas". Solo una es viable.

Qué no es un MVP

No es un prototipo. Un prototipo se mira, un MVP se usa. El prototipo de Figma que hice para el rediseño de Mexx navega y parece real, pero no procesa una compra. Sirve para validar si la gente entiende una interfaz. No sirve para saber si alguien paga.

No es una demo. Una demo funciona con datos preparados y un camino ensayado. Un MVP tiene que aguantar a alguien haciendo las cosas en el orden equivocado.

No es "la versión 1 con menos funcionalidades". Esta es la confusión más cara. Si ya sabés que el producto tiene mercado y qué tiene que hacer, no necesitás un MVP: necesitás construir bien la primera versión, por etapas. Llamarlo MVP no te va a dar permiso para saltarte la calidad.

No es una excusa. "Es un MVP" no justifica que se pierdan datos ni que la pantalla principal tarde ocho segundos.

Entonces, ¿para qué sirve?

Para contestar una pregunta de negocio que todavía no sabés contestar, gastando lo menos posible.

Cuando construí GymSmartAccess, la pregunta era si un dueño de gimnasio de barrio pagaría una cuota mensual por dejar de perseguir socios para cobrarles. Todo lo que ayudaba a contestar eso entró. Todo lo demás quedó afuera: reportes avanzados, multi-sede, app nativa, rutinas de entrenamiento.

Pero los cobros funcionaban de verdad. Porque si los cobros fallaban, la respuesta que iba a obtener no era sobre mi pregunta: era sobre mi ejecución.

Ese es el punto sutil. Un MVP mal ejecutado no responde tu pregunta, la contamina. Si la gente no vuelve, nunca vas a saber si fue porque la idea no servía o porque el producto andaba mal.

Cómo saber si lo que te ofrecen es un MVP de verdad

Tres preguntas que podés hacer en la primera reunión:

¿Cuál es la pregunta que este MVP contesta? Si la respuesta es una lista de funcionalidades y no una pregunta de negocio, no es un MVP: es un presupuesto con un nombre lindo.

¿Qué queda explícitamente afuera y por qué? Un buen alcance viene con una lista de exclusiones. Si nadie te la puede decir, el alcance no está decidido y va a crecer.

¿Qué pasa si la respuesta es que no? Un MVP tiene que contemplar el escenario donde la idea no funciona. Si el plan solo tiene sentido asumiendo éxito, no estás validando: estás construyendo con esperanza.

Lo que cuesta hacerlo mal

Los dos fracasos son simétricos y los vi los dos.

Un MVP demasiado grande te gasta el presupuesto antes de aprender nada. Llegás al mercado con catorce meses encima y descubrís lo que podrías haber descubierto en tres.

Un MVP demasiado frágil te da un no que no significa nada. La idea capaz era buena; nunca lo vas a saber.

El punto justo es incómodo a propósito: poquísimas funcionalidades, ejecutadas en serio.

Si querés ver cómo se decide ese recorte en concreto, lo escribí en de idea a MVP.