Abandone sus ideas preconcebidas y aprenda por qué las empresas de éxito adoptan el MVP como clave para hacer felices a sus clientes.
Por Arbi Vartan y Jeff Brinkerhoff
Slalom ama el Agile. Estamos entusiasmados con los beneficios reales y cuantificables que hemos visto que obtienen las empresas gracias a él, y estamos hablando de algunas de sus mayores ventajas en una serie de publicaciones en el blog y en un seminario web ágil gratuito: véalo a la carta.
El MVP, o Producto Mínimo Viable, es básico en la práctica de Agile. Y también es algo que genera resistencia. Hemos escuchado a nuestros clientes decir cosas como: «Nuestros ejecutivos no quieren el mínimo, quieren la mejor calidad posible». Efectivamente, ¿por qué no querrían hacer lo mejor posible? Es una gran pregunta, pero una basada en un malentendido del MVP.
Acudido por Frank Robinson en 2001, y popularizado por Eric Ries a través de su libro Lean Startup, el MVP se ha convertido en un pilar de los equipos de producto de alto rendimiento en todo el mundo. ¿Por qué Google ha sido tan dominante durante tanto tiempo? ¿Por qué Apple fabrica algunos de los productos más populares del mundo? ¿Por qué Netflix no sólo ha sobrevivido, sino que ha prosperado más allá de su modelo de negocio original? Muchos factores contribuyeron, pero un hilo común es que todos ellos utilizan el MVP.
¿Entonces qué es el MVP? Aquí está la definición de Eric Ries: Aquella versión de un nuevo producto que permite a un equipo recoger la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo.
Como deja claro esta definición, el MVP no es un producto con la menor funcionalidad posible necesaria para un lanzamiento público. No tiene nada que ver con el lanzamiento público de un producto en absoluto. Más bien, el MVP es la clave para utilizar el método científico para construir productos. Es puramente un mecanismo para el aprendizaje validado, utilizado para probar hipótesis y descubrir lo que va a satisfacer las necesidades de los clientes.
Tira el término si debes, pero mantén el concepto
En Slalom, hemos integrado el concepto del MVP tanto en la forma en que construimos productos para las empresas como en la forma en que nos asociamos con ellas para cosechar los beneficios de la incorporación de los principios y prácticas ágiles en su modelo de negocio. Sin embargo, después de más de veinte transformaciones ágiles en empresas y cientos de asociaciones en distintos sectores, hemos descubierto que a veces es más sencillo no forzar el uso de términos como el MVP. Algunos han cambiado al término «Producto Mínimo Amable», y Henrik Kniberg (más conocido por su trabajo con la cultura de ingeniería de Spotify) propone el uso de los términos Producto Más Temprano Comprobable, Producto Más Temprano Utilizable y Producto Más Temprano Amable.
Cualquiera de estos términos está bien. Agile trata de equipos más felices y productivos, no de la terminología. Nuestro enfoque para este o cualquier otro concepto Ágil mal interpretado y poco claro es omitir la palabra y hacer las siguientes tres preguntas:
- ¿Por qué hacerlo? En el caso del MVP, se trata de aprender rápido, así como de los principios subyacentes: satisfacción del cliente, mejora continua y simplicidad.
- ¿Qué haría falta para hacerlo en mi empresa? ¡Oh, el poder del encuadre! En lugar de preguntar si se puede hacer, nos centramos en los bloqueos -organizativos o de otro tipo-. La respuesta a esta pregunta suele consistir en la aceptación de personas que se creían inamovibles.
- ¿Y si no lo hacemos? Otra estrategia de encuadre: centrarse en los costes de seguir con el statu quo. Esto puede crear una sensación de urgencia y establecer una alineación en torno a una nueva forma de trabajar.
He aquí una historia sobre los peligros del statu quo: Un proyecto para una empresa con la que trabajamos recientemente implicaba dedicar seis meses a un importante lanzamiento de software que afectaba a más de 200 usuarios internos. Se encerraron en una habitación y completaron la construcción y todas las pruebas. Y sólo en ese momento solicitaron la opinión de un puñado de analistas de negocio apoderados, no de usuarios reales. Este tipo de actividad, demasiado tarde para tener un impacto real, y sin un verdadero enfoque en el aprendizaje validado, apenas puede considerarse como una solicitud de comentarios. En realidad es un intento de validar lo inevitable.
El resultado era predecible. Dado que ya se había gastado tanto tiempo y dinero, se sintieron obligados a seguir adelante, y los 200 usuarios rechazaron el nuevo software debido a su lento rendimiento y falta de usabilidad. Se gastaron seis meses y más de 12 millones de dólares, y lo único que se consiguió fue que los equipos de negocio y de tecnología se señalaran con el dedo.
Ahora imagina este mismo escenario con un MVP desplegado a un grupo de usuarios finales al principio del proyecto. Los desarrolladores podrían aprender inmediatamente lo que estaban haciendo mal, y luego desplegar otros MVP mejorando iterativamente con cada uno hasta el despliegue de un producto final-desarrollado con y aprobado por los usuarios reales. Otra ventaja: los usuarios del grupo de prueba se implicarían a fondo en el proyecto y lo evangelizarían entre sus compañeros.
Hemos visto cómo se desarrollaba exactamente ese escenario, y por eso creemos firmemente en el MVP, sea cual sea su nombre.