¿MVP o MAP? Esa es la cuestión.

Lo primero que he hecho para escribir este post es buscar la definición de Mínimo Producto Viable (MVP a partir de ahora), y sí, he ido a Wikipedia. Allí lo definen como: “producto con suficientes características para satisfacer a los clientes iniciales, y proporcionar retroalimentación para el desarrollo futuro”. Parece una definición sencilla y clara, pero si habéis trabajado elaborando la estrategia de un producto o conceptualizándolo, os habréis dado cuenta de que hay muchas interpretaciones sobre qué es “suficiente” y, en consecuencia, qué es viable. Y estas diferencias provocan un riesgo importante para el éxito del producto.

Existe quien piensa que “suficiente” significa cuanto más, mejor para que el producto sea viable. Es decir, que cuantas más funcionalidades tenga mi producto, mejor va a ser este y, por tanto, mayor probabilidad de éxito. Sin duda, es una aproximación errónea: el usuario no va a utilizar toda esa avalancha de funcionalidad, seguro. Es mucho mejor investigar y consultar qué funcionalidad valora más, cuál te hace más diferencial con respecto a la competencia y apostar por ella, sacrificando otras que no aporten valor al usuario. Esto, además, te hará reducir no solo el tiempo de desarrollo, sino también su coste.

Aunque la definición no lo dice, normalmente cuando hablamos de tener una estrategia de MVP lleva implícito que queremos lanzar al mercado rápido. Esa rapidez, combinada con poblar de funcionalidad el producto, ya sabemos dónde nos lleva: a penalizar la experiencia de usuario y el diseño de la interfaz y a lanzar un producto con una calidad dudosa.

Además, debido a esta exigencia de tiempos (muchas veces trabajando con tiempos totalmente irreales en lo que a diseño y desarrollo se refiere) y amparándose en ese “suficiente”, hemos visto cómo el MVP se convertía en algo tan básico que la P de producto podría pasar a P de Piloto. En mi opinión, el error cuando se define de forma tan espartana el MVP es pensar que esa va a ser tu primera salida al mercado. Con ese MVP, vamos a poder probar y lanzarlo a un grupo muy, muy reducido de usuarios para recoger su feedback, y así poder fijar cuál será el producto a lanzar. Pero cuando hemos visto que no se ha utilizado para ese fin y se ha salido a producción, ha habido que añadir parches y evoluciones a toda prisa.

Para evitar esos malentendidos de cuánta funcionalidad es suficiente para que el producto sea viable, me gusta mucho más pensar en el Minimum Awesome Product (MAP) o Minimum Lovable Product (MLP): la mínima versión de un nuevo producto que aporta el mayor valor al usuario.

Hay personas que opinan que la evolución del MVP nos aportará el MAP, pero la realidad es que una evolución lineal de un MVP no lleva nunca al producto deseado. ¿Cuántas veces hemos entregado un MVP, dejando muchas cosas deseables fuera por salir en determinada fecha, y luego todo ese deseable ha caído en el olvido porque tocaba sacar lo siguiente? Debemos apostar por uno u otro para nuestra primera release, y esta apuesta va a depender del contexto de nuestro nuevo producto.

Escenario 1: Ya contamos con un producto igual dentro de la compañía

Ya hay productos digitales que tienen varios años (sí, ha llegado la hora del plan renove de muchos productos digitales, hasta la web de Renfe se renueva) y están pidiendo a gritos una renovación. Existe la creencia de que el MVP de la nueva web o app tiene que ofrecer, al menos, lo mismo que ya ofrecía la anterior. Pero, ¿y todos esos desarrollos que la nuevas tecnologías nos permiten y/o el cliente nos demanda? Pensar en un MVP que incluya todo eso nos haría alargar en exceso el tiempo de implementación, estaríamos renovando funcionalidad que el cliente no utiliza y, seguramente, estaríamos entregando nuevas opciones al usuario mucho más tarde que la competencia que ya tenga su producto digital al día.

En este caso, es mucho más acertado apostar por una estrategia MAP, y determinar con los datos de uso de nuestro producto digital ya operativo qué funcionalidad no es útil para nuestros clientes para o bien eliminarla o “migrarla” en releases posteriores. Además, y haciendo uso de la investigación y cocreación con clientes, poder identificar también qué funcionalidad añadir para mejorar la experiencia del cliente. De esta forma, tras el lanzamiento de la primera nueva versión tendremos clientes mucho más satisfechos.

Escenario 2: Vamos a lanzar un nuevo producto en un mercado saturado

En un mundo donde estamos totalmente saturados de productos digitales es esencial poder destacarnos de la competencia y llamar así la atención del usuario. Los clientes ya tienen toneladas de productos viables para elegir y algunos, probablemente, incluso sean bastante buenos. Solo un producto excelente puede ganar.

Una estrategia MVP nos puede hacer fijar una primera release igual a los productos que ya tiene la competencia, pero sin diferenciación no vamos a poder capturar cuota de mercado. Focalizarnos en incorporar algún efecto Wow, diferenciarnos, resolver algún pain point que no haya resuelto su competencia nos va a hacer crear un MAP con mayor probabilidad de éxito. ¿Podemos definir un MVP? Sí, si queremos validar la idea con un grupo de usuarios reducido o probar integraciones o experiencias muy complejas. Pero no hay duda de que lo que debemos lanzar al mercado es el MAP.

Escenario 3: Vamos a lanzar un producto disruptivo o sin competencia

Océanos azules cada vez hay menos, pero aún tiene que quedar alguno. Cuando encontramos una idea que aún no tiene competencia o algo totalmente disruptivo, la rapidez por lanzar cobra más importancia que nunca.

El “Awesome” del MAP va implícito en la idea y es en esta ocasión donde podemos apostar por versiones mucho más sencillas de producto, más MVP que nunca, con funcionalidad muy reducida, incluso penalizando (pero sin pasarse) la experiencia de usuario o el diseño.

Escenario 4: Creamos una nueva aplicación para cliente corporativo o interno

Cuando lo que vamos a desarrollar es una aplicación para cliente corporativo, la estrategia para abordar el producto también es diferente. Aquí no contamos con tanta competencia y saturación del mercado, y el usuario está más predispuesto a utilizar la nueva aplicación. Por lo que un enfoque de MVP puede ser más acertado en un entorno corporativo.

Sin embargo, no olvidemos que los usuarios están acostumbrados a una forma de trabajar, ya cuentan con unas herramientas y, seguramente, hayan vivido el fracaso de la implantación de otras tantas. Por lo que, aunque podamos permitirnos ciertas licencias a la hora de lanzar un producto y enfocarnos más en la viabilidad, debemos tenerlo en cuenta para ofrecerles algo de MAP que les haga enamorarse del nuevo producto cuando lo usen.

¿Mínimo Producto Viable o Mínimo Producto Alucinante?

En realidad, lo que menos importa es cómo se llame. Lo que sí importa es definir la estrategia de nuestro producto y delimitar el alcance de la tan ansiada primera release.