Qué es un MVP y cómo plantear la primera versión de tu producto
Qué significa producto mínimo viable, qué debe incluir la primera versión de una aplicación y los errores que la convierten en un proyecto sin fin.
MVP son las siglas en inglés de «producto mínimo viable»: la versión más pequeña de un producto que permite comprobar si resuelve el problema para el que se construye. Es un concepto sencillo que se aplica mal con mucha frecuencia, casi siempre por el mismo motivo.
Se entiende «mínimo» como «barato» o «a medio hacer», cuando lo que significa es «centrado».
Qué es un MVP y qué no es
- Es un producto que alguien puede usar de verdad para resolver un problema real
- No es una maqueta ni una demostración que solo funciona cuando la enseñas tú
- No es la versión completa con funciones recortadas por todas partes
- No es un prototipo desechable: lo que se construye bien se aprovecha
La palabra importante es «viable». Si nadie puede usarlo para algo útil, no enseña nada, y un MVP existe para enseñar.
Qué incluir en la primera versión de una aplicación
La pregunta que ordena todo es: ¿cuál es la única cosa que tu producto tiene que hacer bien para que alguien lo quiera usar? Eso entra. Lo que no sirve directamente a esa cosa, espera.
- El recorrido principal del usuario, completo y sin atajos
- Lo imprescindible para que sea seguro y legal: acceso, datos personales y pagos si los hay
- Una forma de saber cómo se usa: qué hace la gente y dónde se atasca
- Nada de paneles de configuración para casos que todavía no existen
Los errores más habituales al plantear un MVP
- Querer que la primera versión esté a la altura de competidores que llevan años en el mercado
- Añadir funciones «por si acaso» antes de tener un solo usuario
- Construir todo el sistema de administración antes que lo que ve el cliente
- Recortar la calidad en lugar de recortar el alcance
- No decidir qué se quiere aprender con la primera versión
El cuarto es el más caro. Recortar funciones es reversible; construir mal para ir rápido obliga a rehacer justo cuando el producto empieza a funcionar.
Cómo decidir qué va después del MVP
Con la primera versión en uso, las decisiones dejan de ser opiniones. Se ve qué partes se usan, cuáles se ignoran y qué pide la gente que no estaba en ninguna lista. La hoja de ruta sale de ahí, no de la reunión inicial.
Por eso conviene construir el MVP pensando en que va a crecer: con una base ordenada, el código a tu nombre y sin atajos que luego haya que deshacer.
Un MVP no es la mitad de un producto. Es un producto entero que hace una sola cosa.