Producto mínimo viable (MVP)

Un producto mínimo viable (PMV) es la versión más pequeña de un producto que permite a un equipo obtener información esencial sobre si los clientes lo desean. Este concepto fue popularizado por Eric Ries en su libro The Lean Startup. Su característica principal no es que sea pequeño o barato, sino que está diseñado para responder a una pregunta específica, y que dicha pregunta se refiere a un aprendizaje validado sobre el comportamiento del cliente, en lugar de una opinión interna sobre su viabilidad.

El error más frecuente es considerarlo sinónimo de una primera versión con menos funcionalidades. Bajo la presión de los plazos, los equipos reducen el alcance, lanzan un producto incompleto, lo denominan MVP y luego no miden nada en particular, lo que no produce ni un buen producto ni una lección útil. La clave está en qué hipótesis específica pondrá a prueba la versión y qué resultado llevaría al equipo a cambiar de rumbo. Si no hay respuesta, la versión es un producto pequeño, no un producto mínimo viable.

La parte viable del término también se descuida. Una versión mínima que no funciona, o que falla en su única función, proporciona evidencia sobre la implementación en lugar de sobre la demanda. Que los clientes rechacen un producto por ser lento, defectuoso o confuso no le dice nada al equipo sobre si la propuesta subyacente tiene valor. Todo lo que se incluya debe ser lo suficientemente bueno como para someter la idea a una prueba justa, incluso si el alcance general se reduce drásticamente.

Varios patrones establecidos responden a las necesidades del cliente sin necesidad de desarrollar un producto completo. Los enfoques de atención personalizada ofrecen el servicio manualmente a los primeros clientes para comprender sus necesidades reales antes de automatizar cualquier proceso. Las implementaciones tipo "Mago de Oz" presentan una interfaz funcional con intervención humana. Las pruebas de páginas de destino miden la respuesta del usuario a la propuesta antes de que comience el desarrollo. Cada uno de estos métodos genera evidencia conductual, mucho más sólida que las intenciones declaradas recopiladas en encuestas y entrevistas sobre productos hipotéticos.

Este enfoque se adapta mucho mejor a algunos contextos que a otros. En industrias reguladas, en sistemas críticos para la seguridad y en ventas empresariales, donde una mala primera impresión puede cerrar un mercado durante años, lanzar software deliberadamente incompleto conlleva costes que superan el aprendizaje. En estos entornos, es mejor aplicar la misma lógica mediante prototipos, proyectos piloto con participantes informados y lanzamientos graduales a audiencias limitadas, en lugar de lanzar públicamente un producto mínimo.

Decidir de antemano qué resultado justificaría la detención del equipo es lo que da sentido al ejercicio, y es el paso que con mayor frecuencia se omite. Sin un umbral preestablecido, cualquier resultado puede interpretarse como alentador: un bajo uso se convierte en un problema de marketing, una baja retención en un problema de incorporación, y el proyecto continúa gracias a la explicación que lo salva. Anotar, antes del lanzamiento, qué nivel de adopción o retención justificaría continuar, qué nivel justificaría un cambio de enfoque y qué justificaría detenerlo por completo, convierte el lanzamiento en una prueba real. Además, protege al equipo, ya que un umbral documentado y acordado por las partes interesadas es mucho más fácil de invocar que un juicio posterior.

Utilizado correctamente, el concepto mantiene a un equipo honesto sobre la diferencia entre construir y aprender, y es más valioso donde la incertidumbre sobre la demanda es realmente alta. En la práctica, la hipótesis y el estándar de evidencia se establecen a través de investigación de producto, la construcción se encuentra con desarrollo de productosy la disciplina de definir de antemano qué resultado desencadenaría un cambio de dirección es lo que diferencia este enfoque de simplemente lanzarlo pronto. startups En particular, esa disciplina determina si el tiempo limitado de vuelo se emplea en aprender o simplemente se desperdicia.