MVP son las siglas de Minimum Viable Product — producto mínimo viable. Es la versión más pequeña de tu producto que ya resuelve un problema real para un usuario real y te permite aprender de su uso.
Bien entendido, un MVP no es un producto «a medias»: es un producto completo con un alcance deliberadamente reducido. Lo que entra, funciona bien; lo que no es esencial, se deja para después.
Qué NO es un MVP
- No es una demo ni un prototipo de usar y tirar.
- No es tu producto final con la mitad de las pantallas a medio hacer.
- No es una excusa para entregar algo de baja calidad. La barra de calidad es la misma; lo que se recorta es el número de funcionalidades.
Por qué empezar por un MVP
- Validas la hipótesis antes de gastar el presupuesto completo.
- Llegas antes al mercado y a los primeros usuarios de pago.
- Aprendes qué construir después con datos de uso, no con suposiciones.
- Reduces el riesgo financiero: si la idea no funciona, lo descubres barato. Puedes ver rangos en la guía de cuánto cuesta desarrollar un software a medida.
Cómo definir el alcance de tu MVP
1. Identifica el camino crítico
Es la secuencia mínima de pasos que lleva al usuario desde que entra hasta que obtiene valor. Por ejemplo: registrarse → crear un proyecto → invitar a alguien → recibir el primer resultado. Todo lo que no esté en ese camino queda fuera de la primera versión.
2. Usa una matriz de prioridades
Clasifica cada funcionalidad en: imprescindible (sin esto no hay producto), importante (fase 2) y deseable (algún día). El MVP es solo la columna «imprescindible». Si dudas de si algo es imprescindible, probablemente no lo sea.
3. Define una métrica de éxito
¿Qué número te dirá si funciona? Registros, activación, retención a 7 días, primera compra, tareas completadas… Elígelo antes de empezar a construir, no después.
De la idea al MVP, semana a semana
- Semana 1 — Discovery. Objetivos, usuarios, camino crítico, métrica de éxito y alcance cerrado por escrito.
- Semana 2 — Diseño. Flujos y pantallas del camino crítico sobre un sistema de componentes.
- Semanas 3 a 6 — Desarrollo en sprints. Entregas cada una o dos semanas que ya puedes probar en un entorno real.
- Semana 7 — QA y ajustes. Pruebas de los flujos reales, corrección de errores y revisión de rendimiento.
- Semana 8 — Lanzamiento. Despliegue, analítica conectada, primeros usuarios y recogida de feedback.
El plazo depende del alcance real. Un MVP con un solo camino crítico y sin integraciones complejas entra en esta ventana; añadir pagos, varios roles o apps nativas la amplía. Así es como estructuramos el proceso en Polplab.
Errores comunes al construir un MVP
- Meter demasiadas funcionalidades «ya que estamos».
- Perseguir la perfección visual antes de validar el problema.
- Saltarse el discovery y empezar a programar el día uno.
- Lanzar sin analítica: sin datos, el MVP no cumple su función de aprendizaje.
- No hablar con usuarios después del lanzamiento.
Qué medir tras el lanzamiento
- Activación: porcentaje de usuarios que llegan al primer momento de valor.
- Retención: ¿vuelven a los 7 y a los 30 días?
- Embudo del camino crítico: en qué paso se caen.
- Feedback cualitativo: cinco o diez entrevistas dicen más que mil registros silenciosos.
En resumen
Un MVP es la vía más rápida y barata de comprobar si tu idea resuelve un problema real. Defínelo por su camino crítico, mantén la calidad y mídelo desde el primer día. Si quieres ver el resultado de este enfoque, echa un vistazo a uno de nuestros proyectos.