MVP no es solamente sobre productos apartir de cero
¿Cómo desarrollar un “nuevo producto” de un producto ya existente?
Son muchos ejemplos de startups que tuvieron una idea, desarrollaron una version minima, se la ofrecieron para clientes iniciantes y empezaron a validar hipóteses rapidamente hasta crear un nuevo producto. Yo siempre leí muchos artículos que abordaban esto, sobre cómo el MVP ayudó a validar una nueva idea.
Sin embargo, algunas veces nuestro desafio es desarrollar un “nuevo producto” de uno ya existente, u otras veces tenemos una version antigua que necesita mejorias, o puede ser que en el comienzo el desarrollo inicial fue tan rápido que la estructura necesita ser reorganizada. En casos como éste, el desafio es un poco diferente y me gustaría compartir algunos aprendizajes que tuve junto con el equipo que trabajé.
El desafio
El escenario en el que estábamos era el de una gran empresa que tenía un producto bien establecido en el mercado, que estaba pasando por una transformación en el negócio. En un corto plazo, las ventas, que antes eran hechas por canales físicos, habían crecido por aplicaciones.
Las ventas crecieron a tal punto que el canal digital fue uno de los principales canales de ventas, y nuestro equipo necesitaba ayudar a escalonar ese canal. Además, teníamos algunos desafíos técnicos. Por ejemplo, la estructura no era escalable, no podríamos poner nuevos productos en esa app. De hecho, una funcionalidad que fue muy importante para el crecimiento del producto ya estaba antigua. Nuestro desafío estaba puesto: Ayudar al negocio a crecer con todo un sistema legado. ¿Qué aprendemos con esa experiencia?
- MVP tal vez no sea la respuesta
La primera solución que pensamos fue desarrollar un MVP en que solamente las funcionalidades más importantes estarían incluidas. Nosotros sabíamos cuáles funcionalidades eran las más utilizadas y cuáles eran más lucrativas, entonces pensamos en priorizar por esa razón.
En este momento, encontramos el primer obstáculo: la empresa no estaba dispuesta a crear un MVP sin perder negocios. Tomar la decision de solamente sustituir una versión antigua por una nueva cuando ésta estuviera al 100%, es una gran pérdida de oportunidad lanzar antes y empezar a validar hipótesis. Un gran aprendizaje que tuvimos es que en ese momento es importante que haya transparencia de todos los involucrados. Cuál es el real problema? Muchas veces el MVP no es la respuesta para el problema, y sí el código obsoleto.
2. Asegurese que todos están alineados
El segundo aprendizaje que tuvimos está relacionado a los alineamientos. Como el producto ya existía, muchas personas interesadas estaban involucradas.
Es muy importante tener atención a los alineamientos con todos los stakeholders, porque es muy probable que todas ellas/ellos tengan un gran interés en los resultados de la entrega. Vamos a tener personas con más interés en tecnología, otros en experiencia del usuario y es claro que cada uno tiene una expectativa diferente. Muchas veces pensamos en hacer los alineamientos solamente en el momento de delivery para informar sobre el andamiento del proyecto, pero nosotros nos dimos cuenta que si hubiéramos hecho los alineamientos con antecedencia podríamos haber estado alineados y muchas discusiones habrían sido evitadas.
Para conseguir lo anterior, usted puede utilizar una serie de actividades. Evalúe la aplicación de Lean Inception o montar un Canvas con todos los stakeholders, solo recuerde ponerlos todos juntos y alinear cuáles desafíos usted va a enfocarse para resolver, que hipótesis va a validar e incluso si va a ser un MVP.
3. Vale la pena pensar en Arquitectura
El tercer aprendizaje que tuvimos fue que vale la pena invertir un tiempo pensando en arquitectura. El producto en que trabajamos era muy consolidado en el mercado, entonces no estábamos en un escenario de muchas incertidumbres. En este caso, podíamos dedicarnos un tiempo pensando en una arquitectura más robusta, por más que en el punto de vista del usuario no hubiera mucho valor. Usted puede mostrar que esa inversión se paga a medio plazo porque existe una ganancia de tiempo con eficiencia de procesos y que el equipo no necesita perder mucho tiempo en el futuro con problemas de manutenciones de código legado.
Esto realmente se comprobó cuando tuvimos que hacer evoluciones continuas y la arquitectura y códigos estaban muy preparados. Tuvimos mucha facilidad para promover esas evoluciones.
Desarrollar un MVP de un producto que ya existe es diferente a desarrollar uno desde cero, tiene sus particularidades. Cada uno está en un momento diferente en el mercado y por eso hacer una evaluación sobre su momento es muy importante para la toma de decisiones y de cuál estrategia seguir, pensando en el tiempo disponible, costos y esfuerzos que se pueda economizar.
Evaluar si MVP es la respuesta, cuál hipótesis tenemos que validar, hacer alineamientos iniciales con todos los interesados y tener una preocupación con arquitectura, estos fueron gran aprendizajes que nos llevamos del desafío que vivimos. ¿Usted también ya pasó por eso? ¿Tiene algún aprendizaje para compartir con nosotros? ¡Dejelos acá en los comentarios!
Y si usted quiere aprender junto con nuestro equipo acá en Concrete, eche un vistazo aquí y postule a una de nuestras vacantes. Vamos a aprender juntos.
