MVP es la versión más simple de un producto que se creará y se pondrá a disposición de los usuarios para validar una idea y recopilar datos esenciales para validar la dirección del negocio.
Este concepto surgió en Silicon Valley, una región que alberga muchas startups y empresas de tecnología y ganó impulso después de la publicación de El libro Lean Startup del autor Eric Ries.
.jpg)
(https://www.caroli.org/en/mvp-minimum-viable-product/)
Piense en grande, comience con algo pequeño, aprenda rápido.
Esto significa que nuestro producto evolucionará a partir de su forma mínima de operar, y la manera en la que evolucionará, será en base al aprendizaje que podamos obtener de nuestros usuarios. Trabajo colaborativo, si nos volvemos a mirar el manifiesto ágil.
La base de un Mínimo producto viable es la evolución iterativa, pero ¿qué significa esto?, significa que, a partir de una idea principal y muy simple, pero funcional, con visión y objetivo claro, entregándoselo a un grupo seleccionado de usuarios, (a estos usuarios les llamamos early adopters), ellos serán los encargados de entregarnos información valiosa como feedback, datos y con esta información podemos pivotear, iterar, y en cada iteración podemos evolucionar nuestra idea.
El MVP nos permitirá también validar las hipótesis propuestas para el producto, sabemos que cualquier cosa que desarrollemos sin la validación de nuestros usuarios, no es más que una hipótesis, cuando obtenemos feedback de ellos es que esa hipótesis se vuelve válida o fallida, esto basado en los procesos empíricos, donde exploramos las ideas, experimentamos con esas ideas, aprendemos de esas ideas y ajustamos de acuerdo a la información de uso.
Cuando comencé a trabajar con este concepto de MVP, no entendía bien cuál era el objetivo, entonces lo que hacíamos con el equipo era, dividir el producto completo en hitos funcionales, y en cada sprint entregar las funcionalidades acordadas, ninguna de esas funcionalidades evolucionaba, ni mejoraba, ni tenía espacio para ser inspeccionada, sólo se le entregaba a los usuarios.
Esta forma de trabajar el "MVP", me llevó a la reflexión, respecto al sospechoso parecido que tenía con la metodología cascada.
Entonces me preguntaba, ¿qué era lo que hacía al MVP, algo distinto de lo que veníamos haciendo con cascada?
Lo primero, volví al manifiesto ágil, al principio aquel que reza que el arte de maximizar el trabajo no realizado es esencial. La Simplicidad. Ése era nuestro problema, en ese momento, lo que queríamos con el equipo era entregar la funcionalidad a la perfección y no dejarla que evolucione en base al aprendizaje. Lo perfecto es enemigo de lo bueno.
Otra experiencia fue cuando enfocábamos el MVP hacia los aspectos técnicos del producto, tal como era la arquitectura, sabíamos que, si no teníamos una arquitectura definida, no podríamos realizar los desarrollos, sin embargo, eso nos alejaba de nuestros usuarios, a ellos definitivamente y por más importante que fuera la arquitectura, no les impactaba ese aspecto.
La reflexión era entonces, como equilibramos la evolución de la arquitectura a la par de la evolución de la funcionalidad. El manifiesto también tiene algo para eso: Las mejores arquitecturas, requisitos y diseños emergen de equipos autogestionados.
La primera vez que logramos con un equipo un MVP, lo logramos en 1 mes y medio. Nunca había entregado un producto de software funcionando en tan corto tiempo, era algo muy sencillo, pero que nos servía muchísimo para validar nuestros supuestos y aprender.
Primero, ¿cómo identificamos el MVP? La idea del producto nace a partir de un dolor que nos provocaba demora en tiempos, y falta de transparencia en algunos aspectos de nuestro trabajo. Descubiertos estos dolores, identificamos una oportunidad de mejora, y establecimos un objetivo super claro de lo que queríamos lograr en el largo plazo con el producto. Con este Product Goal, pudimos también visualizar dos cosas; el dolor más grande que teníamos y qué hipótesis/beneficios eran los primeros que queríamos validar. Por lo que nuestro MVP se enfocó en estos últimos puntos
Contar con un equipo empoderado y creativo, esto fue crucial para generar un MVP robusto, y de alta calidad. Al momento de comenzar a desarrollar, todo el equipo conocía el dolor, y sabía cómo era que actualmente era solventado, por lo que las propuestas de nuevas formas de resolver fueron super importantes por dos cosas; la primera que, eran técnicamente factibles, y la segunda era que, hacían que la solución que proponían fuera mucho mejor que la forma actual de resolver.
Le dimos mucho espacio a los desarrolladores para que resolvieran de forma simple los desafíos que les pasábamos, en cada Planning, la conversación giraba en torno a un objetivo claro que queríamos alcanzar. Si bien es cierto, los desarrolladores necesitan un mínimo de información para poder avanzar (ese equilibrio aún lo estamos buscando), también es cierto que fomentamos mucho la colaboración, trabajar día a día, generar espacios para la resolución de dudas y por qué no, también para el debate.
La visión del producto estaba clara, sabíamos adónde queríamos llegar y flexibilizamos mucho el cómo lograrlo. Trabajamos en un roadmap que nos ayuda a clarificar la visión, cada cierto tiempo la revisamos y la adaptamos de acuerdo con lo que vamos aprendiendo de nuestros usuarios.
Stakeholders comprometidos con el producto, trabajamos mucho el discovery y los stakeholders siempre tuvieron tiempo para participar y para dar ideas.
Pero, no todo fue miel sobre hojuelas.
Los principales Obstáculos que se nos presentó cuando trabajamos con el concepto de MVP, tiene que ver mucho con el mindset:
Colaboración y Aprendizaje: el MVP es una herramienta tremendamente útil para facilitar el aprendizaje respecto de los usuarios y del producto, el aprendizaje se comparte. Entonces, ¿Cuál es el problema en todos esto?, precisamente el aprendizaje, no siempre estamos dispuestos a ser "conejillos de india" de un producto, y a veces esto genera desconfianza, más aún si es un producto que estás comercializando - el caso de las Software Factory, debe ser el más complejo- o si quisiera ser prontamente comercializado.
Diseño Centrado en el Usuario: Aquí pueden ocurrir dos cosas: una que le creemos y le hacemos caso en todo al usuario, aun cuando lo que nos esté pidiendo no sea lo mejor y aun cuando nosotros lo sabemos, y lo segundo es que no siempre los usuarios tienen tiempo para participar de las actividades necesarias para generar un MVP.
Discovery Continuo: Comprender que el descubrimiento de un producto no es una fase sino más bien algo que continuamente se debe realizar, es de lo más importante, saber cómo equilibrar las actividades de discovery, sin descuidar las entregas constantes de valor, es un desafío. La clave está en entender que las actividades de product discovery, es una forma sistemática de ver y entender el negocio.
Humildad Intelectual: No nos gusta saber que no sabemos, pero la mayoría de las veces, ni siquiera sabemos lo que no sabemos. Tampoco nos gusta la incertidumbre y cruzamos los dedos para poder construir sobre algo seguro (por eso nos llenábamos de documentos de levantamientos). Aquí la clave es trabajar sobre la frustración y tolerancia al fallo, aceptar que nos equivocamos e implementar mecanismos para asimilar y ser conscientes de nuestros aprendizajes, será crucial para adquirir el mindset.
Por último, la ansiedad y el mal manejo de las expectativas, puede también echar por tierra el MVP, o dejarte con un mal sabor de boca.
Si crees que el requerimiento funcional está claro, que este requerimiento no va a cambiar en ninguna circunstancia (¡y vamos que vivimos en un entorno VUCA!), no te recomiendo trabajar con un MVP, no le sacarás el provecho que entrega esta práctica y probablemente tu entorno tampoco lo valorará.
Asegúrate que todos a quienes quieras involucrar en estas actividades, cuenten con tiempo, o que puedan darse el tiempo de participar.
Si tus stakeholders, clientes, sponsors o inversionistas no entienden el concepto o no cuentan con el mindset necesario, te sugiero que primero puedas conversarlo con ellos, de manera de establecer y alinear esas expectativas. Puedes apoyarte en Roadmap de Producto, para dar transparencia a la visión del producto, aprovecha también el evento de Review, para recibir feedback y adaptar tu product backlog en consecuencia y colaboración con tus stakeholders, en resumen: Transparencia, Inspección y Adaptación.
.png)
