Scrumízate
Últimamente todos oímos hablar de crear el producto viable mínimo. Es una tendencia actual que está siendo muy bien acogida por startups y nuevos proyectos. Se trata de una herramienta realmente útil, nos permite salir al mercado mucho más rápido de lo previsto y permite evolucionar según las necesidades que se plantean con su uso. Si quieres aprender a crear el producto viable mínimo puedes leer este post anterior.
Estamos en el mundo de las modas, y el desarrollo de software no es una excepción. Ciertas corrientes se convierten en tendencias y luego se expanden como las setas. Ejemplo de ello ha sido de forma global el mundo agile (como el propio Scrum), las metodologías de desarrollo orientadas al test (como el TDD), el uso de base de datos no relaciones (como mongoDB) y tantas otras que han desaparecido y tantas otras que aparecerán en el futuro.
Cuando una corriente pasa a ser tendencia muchos equipo la acogen. A veces parece una forma de justificar que se está trabajando bien, tan solo por el uso de una u otra metodología o tecnología. A mi parecer es importante valorar cual es la mejor solución a nuestras necesidades, independientemente de las tendencias. Una vez ha empezado el proyecto es nuestra responsabilidad verificar que todo se está aplicando correctamente para avanzar hacia el éxito. Sino hay que aplicar cambios para que nuestros esfuerzos sean de provecho.
Personalmente he vivido en primera persona, como desarrollador y en más de una ocasión, trabajar en un supuesto producto viable mínimo. El resultado siempre fue el mismo y se podría resumir en frustación. La frustación se expande entre el equipo y es una dinámica muy difícil de cambiar. Siempre que he experimentado esta sensación he pasado por las mismas fases.
Primero, en una fase muy temprana, te das cuenta que el supuesto MVP no tiene nada de mínimo. Está lleno de funcionalidades y características innecesarias. A medida que pasa el tiempo empiezas a dudar de la viabilidad. Cuando avanzas en un MVP necesitas empezar a tener feedback de usuarios o clientes, de no ser así la frustación empieza. Cuando las iteraciones sobre el proyecto no las haces en función del valor percibido por los usuarios la viabilidad queda en fuera de juego. En este punto, a veces, incluso te das cuenta que has estado trabajando en un proyecto que no era ni producto.
Por otro lado, cuando he trabajado en MVP bien definidos la sensación siempre ha sido de avanzar muy rápido, de estar trabajando en funcionalidades que aportan mucho valor a los usuarios o clientes y sientes que el trabajo que está haciendo el equipo ayuda a avanzar hacia el objetivo. La motivación se expande y todos hacen mejor su trabajo.
Qué significa producto viable mínimo? Empezaremos con la definición concreta de cada una de sus palabras. Según la RAE:
Producto: (1) Cosa producida. (2) Caudal que se obtiene de algo que se vende, o el que ello reditúa.
Viable: Dicho un asunto: Que, por sus circunstancias, tiene probabilidades de poderse llevar a cabo.
Mínimo: Tan pequeño en su especie, que no lo hay menor ni igual.
Ahora si miramos que dice la Wikipedia:
Un producto viable mínimo o MVP es la versión de un nuevo producto que permite a un equipo recolectar, con el menor esfuerzo posible, la máxima cantidad de conocimiento validado sobre sus potenciales clientes.
Se utiliza para obtener un conocimiento rápido y cuantitativo del mercado de un producto, o de algunas funcionalidades en particular. [...]
Un producto viable mínimo tiene solamente aquellas funcionalidades que permiten que el producto sea lanzado. Típicamente se lanza sólo a un segmento de todos los posibles clientes, tales como los early adopters [...].
Cuales son los errores más comunes en la definición del MVP?
1- Sobredimensionar el MVP
Uno de los errores más comunes en el proceso de definición del MVP es que termine con un nuevo producto sobredimensionado. Esto suele ocurrir si la persona que define el MVP es la misma que ha ideado el nuevo producto. En este caso es aconsejable que alguien ajeno al proceso creativo tome el papel de comprador (o usuario) para aislar las funcionalidades necesarias del MVP. Normalmente es muy complicado que la persona que ha ideado el nuevo producto pueda renunciar a una funcionalidad para crear una primera versión reducida del mismo.
2- No tener presente las capacidades del equipo
En la definición del producto viable mínimo deberemos tener presente las capacidades del equipo del que disponemos. Para crear un nuevo producto, muchas veces innovador, es necesario usar determinadas tecnologías y habrá que hacer desarrollos a medida. El éxito o fracaso en la creación del MVP irá ligado a tener los conocimientos y capacidades para poder realizarlo. En una startup es bueno que en la definición del MVP participe todo el equipo, o una representación de los distintos perfiles de los que se dispone. De un trabajo colectivo es más fácil que aparezca un MVP realista a las capacidades del equipo. De no ser así es fácil caer en errores que pondrán en juego el éxito del proyecto.
3- Pensar que el MVP es la versión barata del producto
Otro error muy común es pensar que el MVP es solo la versión barata o lite del producto. El MVP no hace referencia a las versiones o modalidades de pago del producto. Se trata de la definición de funcionalidades mínimas para que el producto pueda ser utilizado para sus potenciales clientes. Si centramos el MVP con la versión lite estaremos cometiendo el error de no probar las funcionalidades avanzadas con nuestros usuarios o clientes y seguramente no estaremos hablando de una versión mínima.
4- Incluir elementos no diferenciales en MVP
Cada vez que alguien os explique que está trabajando en un producto mínimo viabe y en su definición incluya elementos superfluos como chats, sistemas de mensajería avanzada, etiquetas, filtros, ciertas funcionalidades sociales... Vuestra respuesta, inequívocamente, debe ser que esto no es el producto mínimo viable. En este punto es fácil entrar en discusiones eternas acerca de lo necesaria que es una funcionalidad u otra. Un buen modo para terminar es poner el ejemplo del iPhone. El primer smartphone de Apple, que permitía enviar correos, tomar notas, un teclado muy cómodo... no contaba con la funcionalidades (imprescindibles?) de find y copy&paste. Si Apple las pudo recortar, que no recortaremos nosotros de nuestro MVP?
5- Relacionar la palabra viable con la rentabilidad
La palabra viable no hace referencia a la viabilidad económica del proyecto ni a su rentabilidad. Hace referencia a las funcionalidades. El MVP no es el producto con el que empezaremos a ganar dinero, sino que nos permitirá medir si nuestra idea es viable o no. En definitiva el MVP nos sirve para evaluar si hay gente dispuesta a usar nuestra aplicación o a pagar por el uso de nuestra plataforma. Unir la rentabilidad a la creación del MVP es muy arriesgado, no nos permitirá iterar a partir del feedback recibido de los usuarios o clientes y imprimirá mucha presión al equipo.
6- No incluir el tiempo en el planteamiento
Para una startup, en la creación de un nuevo producto, el tiempo es una variable muy importante. Una mala gestión del tiempo puede hacer fracasar un producto o incluso hacer quebrar una startup. El tiempo, aunque sea infinito de forma global, es limitado para una startup. Es limitado por la financiación de la que se dispone y en muchos casos requiere que su producto funcione y sea rentable antes de que se termine el dinero. Para ello es muy importante para la salud de la startup no unir la creación del MVP a la rentabilidad de la misma.
7- No escribir las historias de usuario
Las historias de usuario juegan un papel muy importante en la definición del MVP. Para escribirlas debemos responder a las preguntas: Quien lo quiere? Para qué lo quiere? Cual es el beneficio? A parte van unidas a unos criterios de validación. El MVP debe dar salida a las historias de usuario imprescindibles para validar el producto con clientes potenciales. Cuando se incluyen historias de usuario innecesarias destinaremos esfuerzos a generar una parte que no nos ayuda a nuestros objetivos.
Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate i comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
