Qué es un MVP de software y cómo lanzar el primero sin construir de más

Un producto mínimo viable es la primera versión de un producto con lo justo para que un grupo de usuarios reales lo use para resolver su problema. Es «mínimo» porque deja fuera todo lo que no es indispensable, y «viable» porque lo que sí incluye funciona de verdad: se puede usar, sin explicaciones, y no se rompe.

Su propósito no es ahorrar: es aprender. Con un MVP en manos de usuarios descubres qué usan, qué ignoran y por qué estarían dispuestos a pagar, antes de invertir en todo lo demás.

En deportes, MVP significa «jugador más valioso». En software y en negocios, siempre es producto mínimo viable.

El error más común es llamar MVP a un prototipo bonito que nadie puede usar, o a un producto a medias donde cada función está empezada y ninguna terminada. Un MVP hace pocas cosas, pero las hace completas.

Piensa en el recorrido de un usuario, de la primera pantalla a resolver su problema. El MVP es ese recorrido y nada más:

1. Entrar: registro o acceso, lo más corto posible. A veces ni siquiera hace falta cuenta.
2. La tarea central: la una o dos cosas por las que alguien usaría el producto. Completas, con sus casos normales resueltos.
3. El resultado: lo que el usuario se lleva (un documento, un menú publicado, un pedido enviado), visible y compartible.
4. Lo mínimo para operarlo tú: ver usuarios, corregir un dato, saber qué está pasando.
5. Medición: saber cuántos llegan, cuántos completan la tarea y cuántos regresan.

Todo lo demás (reportes elaborados, integraciones, roles finos, personalización, una app móvil) puede esperar a que el uso real diga si hace falta.

Mínimo no significa improvisado. Hay cosas que son baratas de decidir al inicio y caras de cambiar después:

• Cómo vas a cobrar. Por usuario, por lugar, por uso o por plan: cambia cómo se modelan los datos. MenuFacil, por ejemplo, cobra por lugares, y cada lugar activa un restaurante; el modelo tiene que sobrevivir a pruebas gratuitas, descuentos y dos monedas.
• Quién puede ver qué. Aunque el MVP tenga un solo tipo de usuario, los datos de un cliente no deben mezclarse con los de otro.
• Dónde se decide lo importante. En Brosino, todo resultado y todo saldo se decide en el servidor; el navegador nunca decide nada. Es la diferencia entre un producto que aguanta usuarios reales y uno que se puede engañar.
• De quién es el código y las cuentas. Si un proveedor construye tu MVP, que el código, la base de datos y las cuentas queden a tu nombre desde el primer día.

• Escribe la frase «un [usuario] usa esto para [resultado]». Todo lo que no ayuda a esa frase sale de la primera versión.
• Cambia pantallas por procesos manuales mientras se pueda: aprobar a mano, enviar un correo tú mismo, dar de alta clientes uno por uno.
• Quita pasos de entrada. Cada campo de registro es gente que no llega a la tarea central; en Brosino, por ejemplo, se entra como invitado, sin crear una cuenta.
• Deja fuera lo que «estaría bien tener». Si nadie lo pide cuando el producto ya está en uso, no hacía falta.

Un MVP no se termina: se convierte en la base del producto. Con usuarios reales, cada etapa siguiente se decide con datos en lugar de suposiciones: lo que más se usa se mejora, lo que se pide se agrega y lo que nadie toca se quita.

Por eso importa que el MVP esté bien construido por dentro aunque haga poco por fuera. Si la base aguanta, cada etapa se suma encima; si no, lo siguiente es reescribirlo.