Cómo lanzar un MVP que sirva: hacer 1 cosa muy bien antes de querer hacer 10

La sigla MVP se gastó. Hoy le dicen MVP a cualquier prototipo a medio terminar, a una landing con un botón de "lista de espera", o peor, a un producto completo pero feo. Vamos a poner las cosas en su lugar.

Qué es un MVP en serio

Minimum Viable Product. Las tres palabras importan. Mínimo: lo más chico que se pueda. Viable: qué funcione de verdad para alguien. Producto: no un mockup, no una idea, un producto.

La pregunta no es "que features pongo". La pregunta es "que es lo único que tiene que hacer mi producto para que un usuario pague (o use, si todavía no monetizas)". Todo lo demás, en la versión 2.

El caso Mi Seguro de Auto

Cuando armamos Mi Seguro de Auto la tentación era resolver todo el mercado de seguros: autos, motos, hogar, vida, ART. Lo que hicimos fue lo contrario. Arrancamos con un solo vertical (motos) y un solo flujo (cotizar en 5 pasos sin llamada telefonica).

Esa decisión define todo el resto. No hay calculadora de seguro de vida en el menú. No hay opción de cotizar el auto del cuñado. Hay un botón que dice cotizar moto, y eso lleva al usuario por cinco pantallas hasta tener un número. Punto.

Resultado: la gente entiende para que sirve en 3 segundos. La aseguradora del otro lado puede medir conversión. Y el equipo de desarrollo puede iterar sobre algo concreto, no sobre una plataforma teorica.

Los 3 errores típicos que matan un MVP

Error 1: Confundir MVP con "versión barata". Un MVP no es la misma cosa con menos plata. Es OTRA cosa, más chica, más focalizada, mejor terminada en lo poco que hace. Si tu MVP te da vergüenza, no es porque le falten features. Es porque las que tiene están mal.

Error 2: El sindrome del board de Trello. El equipo arma una lista de 80 funcionalidades, las prioriza, y termina con un MVP de 40. Sigue siendo demasiado. La pregunta correcta no es "que sacamos", es "si tuviera que entregar algo manana, qué sola feature dejo". Empezas por esa.

Error 3: Lanzar en silencio. Un MVP que no se mide es un demo. Antes de codear, definis: cual es la métrica que dice si esto funciona o no. Si es una plataforma de cotización, la métrica es cotizaciones completadas, no visitas. Si es un CRM, son leads que avanzan de estado, no usuarios registrados.

El checklist concreto

Antes de empezar a programar el MVP, escribí en una hoja:

1. Una frase: qué problema resuelvo y para quien.
2. Una métrica: cómo se que funciono (número concreto, no "engagement").
3. Un flujo: de inicio a fin, paso a paso, sin ramas opcionales.
4. Una fecha: cuándo sale a usuarios reales (no a tu mama, usuarios reales).
5. Una salida: qué pasa si la métrica no se cumple en 60 días.

Si no podés responder esas cinco preguntas, todavía no tenés un MVP. Tenés una idea. Y la idea no es lo difícil, la ejecución si.

Cuánto tiempo lleva un MVP real

Depende del vertical. Para que tengas referencia: un cotizador como Mi Seguro de Auto, hecho desde cero, va de 4 a 8 semanas si el alcance está bien acotado. Un CRM como La Carolina con pipeline de estados y propuestas, 8 a 12 semanas. Una plataforma con IA como Tontin, donde el modelo de retención y la memoria entre sesiones son críticos, 12 a 20 semanas.

Si te ofrecen un MVP "completo" en 2 semanas, lo que te van a entregar es un template comprado en ThemeForest con tu logo arriba. No es un MVP.

Conclusión

Un MVP es una apuesta. La apostas sobre una hipótesis específica (esta gente paga por esto) y la testeas con el producto más chico posible que la pueda validar. Cuanto antes salga a usuarios reales, antes sabes si la hipótesis era buena. Y si no era, perdiste 8 semanas en vez de 8 meses.

Si tenés una idea en la cabeza pero no sabes por donde arrancar el alcance, escribinos. En 30 minutos definimos juntos cual es el alcance mínimo viable real de tu producto.

---

Por Esteban Aleart, Founder & Lead Engineer de Pair Programming.