Antipatrones de un MVP

por | Dic 14, 2021 | Agile | 0 Comentarios

A la hora de crear un producto en un entorno tan cambiante como es el de la tecnología, necesitamos herramientas para validar las hipótesis antes de hacer grandes desembolsos. Herramientas como el Minimum Viable Product (MVP).

En 1999, en pleno auge por las puntocom, Nick Swinmurn pensó que era un buen momento para crear un sitio online de venta de zapatos. Los siguientes pasos para crear la empresa podrían ser crear un sitio web con un gran catálogo, comprar a las marcas diferentes modelos y tallas, buscar un local donde almacenar todo el material, crear una pasarela de pago en la web… Sin embargo, en lugar de eso, Nick habló con varias zapaterías de su barrio para pedir si podía fotografiar su inventario y subirlo a su web. Si alguien se interesaba por el producto, él se comprometía a comprar los zapatos en la tienda para enviárselos al cliente. Nick quería validar su idea de venta online de zapatos empleando el mínimo producto posible. Había creado el MVP de Zappos.

Eric Ries describe en su libro El método Lean Startup un método para crear startup exitosas. Para ello se apoya en un circuito de feedback de información: Crear – Medir – Aprender. Por cada una de las hipótesis que queremos probar, completamos un ciclo completo. El MVP (Minimum Viable Product) es aquella versión del producto que nos permite dar una vuelta entera el ciclo de feedback con un mínimo esfuerzo y el mínimo tiempo de desarrollo.
El MVP de Zappos no requería de un gran desembolso de dinero debido a que se aprovechaba de las tiendas que ya existían en su barrio. El esfuerzo estuvo en fotografiar el catálogo de las tiendas y subirlo a la web. Y si algún cliente compraba en la web algún producto, sólo tendría que ir a la tienda y comprarlo para enviárselo. Sin embargo, este mínimo producto le sirvió para validar su hipótesis sobre las ventas online de zapatos. Diez años después de su creación Nick vendió Zappos a Amazon por 1.2 billones de dólares.

Hoy en día es común construir productos pensando en su MVP (recuerda este artículo sobre Lean Inception donde ya hablamos del MVP). Pero, con su uso generalizado, han llegado también los antipatrones:

  • El MVP debe evolucionar. En ocasiones nos encontramos con productos que son un MVP perpetuo. A esta versión del producto le faltan muchos elementos que pueden ser esenciales más adelante. Es difícil pensar que Zappos hubiera conseguido el mismo éxito si Nick hubiera seguido utilizando el método de la fotografía en las tiendas para vender los zapatos en su web. Una vez validada la hipótesis, se escoge otra para probar dentro del ciclo de feedback.

 

  • Junto con el MVP debemos crear un conjunto de métricas para medir su impacto. El éxito de esta versión mínima no está en cumplir con tiempos y presupuesto, si no en comprobar que estamos creando algo que alguien quiere. En el caso de Zappos, habrían de existir métricas como el número de compras, el número de usuarios de la web, el número de usuarios que repetían… Estos indicadores no sólo son métricas del éxito del producto. Se convierten en guías para la innovación del producto. ¿Qué tenemos que hacer para aumentar un 10% el número de clientes quieran repetir en nuestra tienda? ¿Cómo podemos incrementar las ventas un 20% en el siguiente trimestre? ¿Cómo incrementar en 0,5 puntos la satisfacción de los usuarios?

 

  • Lo contrario de un MVP que no evoluciona es un MVP que intenta salir con todas las características. Imagina la web de Zappos con una pasarela de pagos, unas imágenes de alta resolución y una autenticación de seguridad para poder acceder. Si se observa que los clientes no compran, ¿cómo podemos saber a qué es debido? ¿Será porque la pasarela de pago está caída? ¿O es que con la conexión a internet del cliente tardan mucho en cargar las imágenes en alta resolución? ¿El proceso de autenticación genera desconfianza en los clientes?

El MVP es una herramienta de innovación que debe servirte para validar de forma temprana las hipótesis de negocio y generar conocimiento para dirigir el desarrollo de tu producto. Pero, ¿qué pasa si nuestro MVP nos descubre que nuestro producto no tiene la aceptación que esperábamos? En ese momento tendremos que tomar la decisión de pivotar hacia otra hipótesis. Frente a lo difícil que pueda ser la decisión, conseguimos ahorrar tiempo y dinero en productos que no funcionan.

También te puede interesar.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies