Entendiendo el Minimum Viable Product (MVP) en Scrum: Outcome vs. Output

¿Qué es un Minimum Viable Product, cómo te lleva el trabajo con él al éxito y qué enormes ventajas aporta todo esto para ti, tu equipo y tus clientes?

En este artículo aprenderás todo sobre el MVP y descubrirás por qué la diferencia entre Outcome y Output decide sobre el éxito o el fracaso de tu producto.

Diferencia entre Outcome y Output en el MVP

Quien desarrolla un producto para sus clientes debería preguntarse en primer lugar qué necesidades tienen realmente estos clientes y qué problemas debe resolver el producto. Una vez aclaradas estas preguntas, puede comenzar el desarrollo del producto, porque solo entonces queda claro qué resultado (Outcome) desean los clientes. Si el resultado deseado es, por ejemplo, que los clientes puedan desplazarse más rápido de A a B, el producto (Output) podría ser un automóvil. Pero no tiene por qué serlo, ya que también un monopatín entregaría el Outcome deseado, y además sería más barato y rápido de desarrollar que un automóvil.

Curiosamente, la mayoría de las empresas ni siquiera se ocupan del Outcome para los clientes antes del desarrollo del producto: parten de una idea de producto fija y se concentran únicamente en entregar exactamente ese Output con los paquetes de trabajo o features correspondientes.

El enfoque exclusivo en el Output: un riesgo empresarial

¿Por qué es tan arriesgado este enfoque y por qué la concentración exclusiva en el Output puede tener consecuencias fatales para una empresa?

Quien trabaja con un enfoque Big-Bang quiere completar su producto al 100% antes de entregarlo al cliente. Esto puede llevar a que:

• la empresa invierta demasiado tiempo y dinero en el desarrollo,

• los clientes ya no necesiten el producto porque durante el largo tiempo de desarrollo un competidor lanzó una variante mejor,

• el mercado para el producto ya no exista porque las circunstancias y necesidades han cambiado,

• nadie compre el producto porque fue diseñado completamente alejado del gusto y las necesidades de los clientes,

• el producto se haya vuelto tan sobredimensionado, complejo y caro que los clientes prefieran una variante más simple y económica de la competencia.

En resumen: el riesgo es grande de que las empresas destinen todos los recursos durante un período demasiado largo a una idea de producto rígida, pero que después el producto no se venda. ¿Cómo se puede evitar este problema de forma sencilla y ágil? La solución se llama: Minimum Viable Product.

¿Qué solución ofrece el Minimum Viable Product en Scrum?

Si tú y tu empresa ya trabajan con Scrum, quizás ya hayas oído hablar de ello: Minimum Viable Product (MVP) significa el producto mínimo viable. Si trabajas, por ejemplo, como Product Owner para tu empresa, deberías concentrarte siempre en el Outcome basado en la necesidad del cliente. En el ejemplo mencionado anteriormente, eso sería llegar más rápido de A a B.

¿Qué puede ser exactamente un producto mínimo viable en el contexto de esta necesidad del cliente? La siguiente imagen del blog de Crisp lo muestra:

Naturalmente, el automóvil es solo una metáfora del producto que el cliente originalmente deseaba: su necesidad es llegar más rápido de A a B y piensa que para eso necesita un automóvil.

Con la metodología del Minimum Viable Product, tú como Product Owner te aseguras de que tú y tu equipo Scrum entregueis productos mínimos viables (MVPs) al cliente en iteraciones rápidas y pequeñas. Lo importante es que siempre mantengas el Outcome deseado en mente y entregues MVPs con los que el cliente pueda satisfacer su necesidad al menos en lo básico:

La fila superior de la imagen muestra que no tiene sentido venderle al cliente simplemente las primeras piezas terminadas del automóvil, ya que con ellas seguramente no podrá desplazarse más rápido de A a B. La fila inferior muestra, en cambio, que tanto un monopatín como un patinete, una bicicleta y una motocicleta pueden entregarse como MVPs al cliente, ya que un desplazamiento más rápido está garantizado con cada una de estas soluciones.

¿Qué ventajas aporta un MVP?

Entregar MVPs a clientes, testers y early adopters tiene las siguientes grandes ventajas:

• Recibes feedback muy temprano en el proceso de desarrollo: ¿esta primera versión del producto ya cumple los deseos del cliente? ¿Funciona como se esperaba? ¿El diseño es adecuado? ¿Hay quizás otros deseos o deseos adicionales detrás de la necesidad original del cliente?

• Un aprendizaje rápido genera un gran progreso: si después del primer feedback del MVP ya sabes qué es importante para el cliente y de qué puede prescindir, la segunda iteración mostrará una gran mejora.

• Las adaptaciones son posibles en cualquier momento: el desarrollo iterativo asegura una alta flexibilidad. En lugar de tener que rediseñar laboriosamente un producto terminado después de 3 años de desarrollo, puedes realizar cambios después de cada iteración sin gran esfuerzo.

• Generas ingresos tempranamente: como puedes cobrar por tus primeros MVPs, reduces considerablemente el riesgo empresarial.

• Clientes entusiasmados mediante la reducción del precio y el tiempo de desarrollo: si en nuestro ejemplo anterior resulta que el cliente ya está completamente satisfecho con la bicicleta porque satisface su necesidad, como Product Owner detienes el desarrollo del producto exactamente en ese punto. Como has desarrollado la bicicleta 1. más rápido y 2. más barato que un automóvil, puedes ofrecer al cliente una solución satisfactoria de forma temprana que le cuesta menos.

Un ejemplo típico de Minimum Viable Product

Un buen ejemplo de MVP es el túnel de la autopista A1 en Colonia: en lugar de concentrarse en las necesidades de reducción de ruido de los vecinos y entregar primero medidas más pequeñas y relativamente económicas como un límite de velocidad, asfalto silencioso y barreras antirruido como Minimum Viable Product, y construir sobre el feedback de los vecinos, los responsables solo tenían su Output en mente: ¡un túnel antirruido de última generación!

Después de largos años de construcción y las consiguientes interrupciones del tráfico, se creó un llamado túnel antirruido que costó 200 millones de euros. Como muestra el feedback, forzosamente tardío, de los vecinos, el túnel no resolvió el problema, sino que, por el contrario, empeoró la situación de ruido.

¿Por qué vale la pena trabajar con el MVP?

Especialmente cuando el producto final aún no está completamente claro y no se ha asegurado empíricamente que los clientes lo comprarán tal cual, es decisivo para el éxito pensar en Outcomes y necesidades de los clientes y acercarse a ellos mediante MVPs.

E incluso con productos donde ya conoces el panorama completo, como por ejemplo un camión, la entrega incremental de Minimum Viable Products puede valer la pena. Porque posiblemente tu cliente descubra que está satisfecho con muchas menos funcionalidades de las que pensaba originalmente. Y un cliente que obtiene la solución a su problema más rápido y por menos dinero es un cliente altamente satisfecho.

¿Quieres conocer más datos interesantes sobre el trabajo con Scrum e información sobre cómo el trabajo ágil hace a tus clientes más satisfechos y a tu empresa más exitosa? En nuestra Guía Scrum encontrarás todo lo que necesitas para comprender los fundamentos. En nuestros entrenamientos certificados de Scrum aprenderás cómo aplicar Agile en la práctica.

¿Qué es un producto?

Lee qué es realmente un producto en Scrum y cómo crear una definición de producto.
=> ¿Qué es un producto?

¡Así será exitoso el Refinement!

Como Product Owner, define el Outcome para el próximo Sprint y mejora los resultados del Refinement con estos trucos.
=> Product Backlog Refinement

¿Cómo desarrollar una visión de producto?

Descubre cómo desarrollar una visión de producto en 3 simples pasos como Product Owner.
=> Desarrollar visión de producto