El término Mínimo Producto Viable (MVP) fue popularizado en el año 2008 por el emprendedor norteamericano Eric Ries y es parte esencial de la metodología lean, filosofía que se ha impuesto en las políticas de inversiones, tanto en empresas maduras, como de las startups. Ries definió un MVP como la versión de un producto nuevo que permite recolectar la mayor cantidad de feed back de un posible cliente con el mínimo esfuerzo
La definición de MVP es lo suficientemente sencilla como para extenderse rápidamente, tiene la lógica aplastante de algo evidente como escuchar al cliente antes de seguir invirtiendo, pero es tan subjetiva que delimitar la versión mínima del producto suele ser una tarea problemática.
A pesar de que el concepto MVP ha calado en los equipos de dirección de proyectos, son habituales los errores y confusiones cuando se trata de aplicarlo.
MVP sobredimensionado
Cuando la persona que define el MVP es la misma que ha ideado el nuevo producto, el MVP suele terminar sobredimensionado. En el proceso creativo, el creador de un producto asume simultáneamente el rol del comprador y el del proveedor. No suele ser fácil que renuncie a parte de la funcionalidad que ha ideado para crear una versión disminuida del producto. En ese sentido, siempre es aconsejable que alguien ajeno al proceso creativo tome el papel de comprador para aislar las funcionalidades necesarias en el MVP.
MVP no es una versión barata del producto
El MVP no es la versión barata del producto. La definición de MVP indica que debe llevar el mínimo esfuerzo, pero ese mínimo no siempre es poco esfuerzo. Los productos innovadores suelen estar soportados por tecnologías que requieren un desarrollo a medida. El desarrollo a medida arranca en presupuestos mínimos elevados.
Diseño del MVP
El MVP se diseña en la fase de planificación del proyecto y nunca durante el desarrollo del mismo. Es habitual que los directores de proyecto se acuerden del MVP cuando en pleno desarrollo anticipan retrasos en las fechas de finalización. En ese momento, para evitar retrasar la salida al mercado, recurren al diseño del MVP. Definir el MVP en pleno desarrollo implica desvirtuar el concepto de versión mínima, puesto que incluiría las funcionalidades que ya están completadas en el momento de diseñarlo. Estas funcionalidades quizás no estarían incluidas en el MVP si se hubiera diseñado antes de arrancar el desarrollo.
Funcionalidades del MVP
Las funcionalidades seleccionadas para el MVP son una consecuencia del tipo de feed back que se desea recabar del cliente.. El punto más delicado en la definición de MVP es qué feed back quiero recabar de los primeros clientes. Nuestro consejo es incorporar en el MVP la funcionalidad necesaria para probar el modelo de negocio. Si el éxito del negocio se basa en una adopción masiva del producto, el MVP debe incluir la funcionalidad necesaria para testar la velocidad de adopción. Si el negocio está basado en el pago de un precio por un producto nuevo, el MVP debe conseguir que el usuario entienda el objetivo de ese producto, el problema que resuelve y el precio del producto. De esta forma, el usuario afrontará la decisión de si merece la pena pagar a cambio de resolver el problema. Por último, si el producto compite con otros establecidos en el mercado, el MVP debe incluir la funcionalidad que lo diferencia de la competencia, con el fin de conocer si ese atributo diferencial basta para atraer al cliente.
Nuestro consejo es incorporar en el MVP la funcionalidad necesaria para probar el modelo de negocio.
Casos prácticos
Tomemos el caso de Facebook. Cuando Facebook se lanza al mercado ya existían redes sociales. Por tanto, el MVP de Facebook no debería probar la aceptación de un producto nuevo, sino la diferenciación que en ese momento introducía: un público más selecto y énfasis en compartir fotos. Esos elementos diferenciales deberían estar incluidos en el MVP. Para el MVP resultarían superfluas funcionalidades como chats, mensajerías avanzadas o tagueo de imágenes.
Uber fue el primer servicio pensado para alquiler de vehículos particulares. Es un hecho que el usuario paga por el servicio de taxi, luego no sería crítico testar si el usuario aceptaba pagar un precio por el servicio. El MVP de Uber debería probar si existían conductores dispuestos a usar su vehículo privado para alquiler de transporte y si los usuarios serían capaces de cambiar el taxi por un vehículo particular. Una funcionalidad poco enriquecida, pero que alcance a ambos usuarios, sería el MVP más adecuado.
Observar otros productos en el mercado es un buen ejercicio para poner de acuerdo a un equipo sobre el alcance del MVP, razonado cuál sería el MVP más adecuado en opinión de cada uno. Es una técnica que ayuda a alinear los principios sobre los cuales se razonará posteriormente su propio MVP.
