Hay empresas que pasan nueve meses construyendo algo que nadie usa. No porque el equipo sea malo, sino porque nadie validó la hipótesis antes de empezar a programar. El MVP es la respuesta directa a ese problema.

Minimum Viable Product, o Producto Mínimo Viable, es la versión más pequeña de un producto que aún resuelve el problema real de alguien. Fíjate en la palabra: real. No es un boceto, no es una demo para stakeholders, no es una pantalla bonita en Figma. Es un producto pequeño, pero entero para quien lo usa.

Qué es un MVP, y con qué se suele confundir

La confusión más común: tratar un MVP como producto incompleto. No lo es. Si el usuario no logra terminar la tarea que vino a hacer, no importa cuán liviano esté, no es un MVP, es una entrega a medias. El recorte se hace en amplitud, es decir, cuántas cosas hace el producto, no en profundidad, o sea, qué tan bien hace lo que hace.

Piensa en cómo los buenos restaurantes prueban platos nuevos. El chef sirve una versión limitada, en algunas mesas, antes de imprimirla en el menú. El cliente paga, come, da feedback. Si funciona, entra al menú oficial. Si no, fue un experimento barato, y no un lanzamiento fallido.

Por qué empezar pequeño realmente paga

Tres cosas cambian cuando lanzas con un alcance acotado. Primero, el feedback deja de ser 'creo que al usuario le va a gustar' y se convierte en 'el usuario lo usó'. Segundo, el costo de descubrir que el camino era otro cae mucho: tres semanas no es lo mismo que nueve meses. Tercero, el equipo aprende a entregar e iterar, en vez de planificar para siempre.

Cómo recortar el tuyo

No empieces por la lista de funcionalidades. Empieza por el usuario que quieres atender y por la primera tarea que él necesita completar para extraer valor. Todo lo que esté fuera de ese camino queda fuera del MVP, incluso si parece importante. Y 'parece importante' no vale como argumento.

Aquí es donde la mayoría de los equipos tropieza: quieren meter 'solo una funcionalidad más'. Cuando se dan cuenta, el MVP se convirtió en una v1 completa, atrasada y cara. Resiste. La funcionalidad excluida va al backlog. Puede entrar después, si los datos lo piden.

Un MVP no es una fase del proyecto, es una postura. Los equipos que entienden esto entregan rápido toda la vida, no solo al principio.

Lanzar y parar es desperdicio. La ganancia real viene del ciclo: entrega pequeña, medición, decisión, próxima entrega. En tres meses ese loop te da una claridad que ninguna planificación previa puede ofrecer. En seis, sabes si la apuesta original era buena.