Cuando hablamos de MVP (Minimum Viable Product) tendemos a pensar con una versión simplificada del concepto que hay detrás de estas siglas. Normalmente pensamos en la mínima funcionalidad que necesito tener para sacar un producto al mercado y ser competitivo. Este enfoque nos puede llevar a cometer errores que pueden hacer que nuestro producto o idea deje de funcionar más rápidamente de lo que pensamos o peor aun, que nunca lleguemos a tener el producto listo.
El concepto de Mínimo Producto viable (Minimum Viable Product) es un concepto que viene definido en el libro Lean Startup de Eric Ries como:
“Aquella versión de un nuevo producto que permite a un equipo recolectar la máxima cantidad de aprendizaje validado acerca de los usuarios con el menor esfuerzo”
Tenemos que tener cuidado en no confundir un MVP con Funcionalidad Mínima comercializable (Minimum Marketable Feature, MMF). La diferencia entre ambos radica en que con el MMF buscamos entregar valor al usuario final, mientras que con el MVP buscamos aprendizaje sobre el producto, sin tener que entregar un valor real.
Es decir el MVP responde a ¿qué es lo mínimo que necesito para conseguir salir al mercado a validar mi hipótesis de negocio y entender las verdaderas necesidades del usuario? Y entonces, ¿qué podemos hacer?
Consejo 1: Tener una hipótesis
Hay múltiples motivos por los que nos podemos lanzar a desarrollar un nuevo producto. Normalmente hemos vivido una necesidad en nuestras propias carnes, las extrapolamos al resto del mundo y en nuestra cabeza se convierte en una necesidad real del mercado. Esto puede ser cierto, o no. Y aquí es donde entra el concepto hipótesis. Es imposible saber qué necesitan los demás, qué necesita el mercado, sin preguntarles. Por mucho que creamos que sabemos lo que quiere la gente, podemos estar equivocados, y para esto necesitamos una hipótesis. Según Lean, es el primer paso, mucho antes de construir un MVP.
1. Definir las hipótesis que queremos comprobar.
2. Definir unas métricas para validar esta hipótesis
a. Coste de adquisición de clientes
b. Recurrencia
c. Valor del cliente en el tiempo
d. Mercado, etc
3. Construir un MVP para aprender.
Consejo 2: Entender lo que espera el usuario
Tenemos la percepción de que si se nos ocurre una idea, tenemos que tirar con ella hasta el final, sin preguntar a nadie, sin necesidad de feedback. Hay muchos casos de errores millonarios por no ir a pedir feedback al mercado. Algo tan sencillo como validar tu hipótesis en el mercado lo más rápido posible, puede ahorrarte mucho dinero. Para ello existen múltiples herramientas y técnicas que nos permitirán en las primeras fases del desarrollo de nuestro producto afinar el tiro inicial.
Lo ideal en este punto es utilizar técnicas que impliquen directamente a los usuarios potenciales. Muchas veces no tenemos esta opción en los primeros momentos, aunque son algunas de las formas más eficiente de entender y definir correctamente una hipótesis para un buen MVP. Algunas de las opciones que tenemos son:
- Encuestas a usuarios potenciales
- Prototipado
- Análisis de mercado, etc
Es cierto que muchas veces no se pueden realizar estas técnicas por no conocer al usuario final o no tener disponibilidad de estos o presupuesto. Para ello existen otras técnicas que aunque no son tan eficaces, ya que no es un feedback directo, nos permiten empatizar con el usuario y ponernos en su lugar para entender sus necesidades. Algunas técnicas muy conocidas son:
- Sesiones de Inception
- User Personas
- Mapas de empatía
- Business Canvas Model, etc
Consejo 3: Lanzar un MVP no nos hará ricos al momento
Debemos entender que el MVP que lancemos al mercado puede no darnos el beneficio deseado. Como decíamos al inicio, un MVP se utiliza para validar una hipótesis y conseguir aprender rápidamente por dónde ajustar nuestro enfoque. Pretender hacer algo que nos haga ricos al instante no hará otra cosa que frustrarnos. Pocos MVPs suelen ser rentables en sus primeras versiones. Porque son eso, primeras versiones que nos permiten pivotar (hacer pequeños cambios en nuestro producto para adaptarnos) y entender en profundidad cómo estamos de cerca o de lejos de que nuestra hipótesis de beneficios.
Hay muchos casos de empresas con ideas revolucionarias en sus primeras versiones, no sólo el MVP, que fracasaron estrepitosamente como producto. Google, Facebook, Twitter, Uber, etc. Todas ellas sacaron primeras versiones que no eran ni de lejos lo que conocemos ahora. Sin embargo les permitió entender el entorno en el que se movían, las necesidades de los potenciales clientes. Es decir, les ayudó a entender cuál era el mercado objetivo y cómo pivotar para ganarlo. Lo importante es aprender de la información que obtenemos y saber pivotar al poner nuestro MVP en el mercado. Aquí podéis ver el timeline de Uber.
Consejo 4: Probar nuestra hipótesis en el mercado
Como ya hemos comentado hay muchas maneras de recopilar feedback valioso. Tendemos a pensar que un MVP es la mínima funcionalidad necesaria, que tiene que salir bonito o si no no atrae, que tiene que tener muchas funcionalidades para llegar mas lejos, y no tiene porqué ser así. En la mayoría de los casos podemos salir con menos funcionalidad y nuestro producto ya es útil para validar una hipótesis. Hay muchas formas de obtener feedback sin necesidad de liberar el producto completo.
Un ejemplo sencillo de entender lo que esperar son las Landing Page. Imaginad que queremos lanzar una nueva web. Mientras empezamos a desarrollarla, generamos una Landing Page para que la gente empiece a tener curiosidad. Muchas veces incluso incluimos un formulario de feedback. Es importante que los responsables de desarrollo de producto estén funcionando a toda máquina desde el primer momento. No hay que esperar a tener el producto desarrollado para poder validar si hay interés en el mercado. Podemos hacer uso otra vez de encuestas, sesiones de feedback, etc.
En cualquier caso, es muy importante que cuando nuestro producto tenga una nueva funcionalidad, la abramos a recibir feedback por parte de usuarios, o gente lo más cercana a ellas. Muchas veces ante la imposibilidad de contar con el usuario, realizamos validaciones desde dentro del equipo de desarrollo de producto. Esto es un problema porque nos impide ver más lejos de nuestras ideas y la hipótesis no puede ser validada.
Consejo 5: Maximizar el trabajo no realizado
Este es uno de los problemas más graves que nos podemos encontrar. Cuando tenemos una idea en la cabeza, tendemos a ir a máximos. Somos capaces de desarrollar y visualizar rápidamente lo que queremos conseguir. El problema es que tenemos que ir poco a poco si queremos asegurar el éxito del producto. Además cuando el producto no es desarrollado por un equipo interno, si no que se externaliza una parte o todo el desarrollo, esto se acentúa porque tendemos a maximizar el trabajo que van a realizar en lugar del valor que vamos a aportar.. Este error va directamente ligado al principio 10 del manifiesto ágil, donde se comenta explícitamente y de manera concisa:
“La Simplicidad — el arte de maximizar el trabajo no realizado — es esencial”
Pero ¿qué significa exactamente esto? ¿Maximizar algo que no se hace? Pues está claro, no hagas nada que no vayas a necesitar. No hagas nada que suponga un esfuerzo mayor que el retorno que vas a recibir. No hagas nada de lo que no estás seguro, vas a invertir más tiempo en darle vueltas que en hacerlo. Pongamos un ejemplo para entenderlo.
Imaginad que estamos desarrollando un producto nuevo. Este nuevo producto requiere una serie de servicios con un CRUD. Esto nos genera 4 funcionalidades a desarrollar: Create, Read, Update, Delete. Imaginad por un momento que todas las funcionalidades son independientes y cuestan lo mismo en cuanto al desarrollo. Imaginemos también que es un producto completamente nuevo.
¿Qué sentido tiene desarrollar el Delete? Mucha gente dirá que es necesario, pero ¿si no tengo nada creado, para que quiero el borrar? Algo parecido nos ocurre con el Update, ¿para qué necesito tener la funcionalidad de actualizar algo si no tengo nada creado aun?
De esas 4 operaciones, ¿cuál sería nuestro producto mínimo viable? Con las premisas dadas deberían ser el Create y Read. A continuación, si la hipótesis fuera válida, seguiría desarrollando el Delete y por último el Update (hasta tener esta funcionalidad desarrollada un Update se ejecutaría Borrando y creando de nuevo).
Conclusión
Elaborar un buen MVP que nos ayude a validar nuestra hipótesis de negocio no es tarea sencilla. Requiere un esfuerzo continuado desde la ideación hasta la validación del feedback recibido. Sin una forma de validar nuestra hipótesis de negocio, ésta no es más que eso, una hipótesis, que posiblemente se quede en una buena idea. Debemos ser capaces de generar feedback lo antes posible, validar muy rápido y generar cambios de manera iterativa para encontrar el mercado al que interesa nuestro producto. Solo de esta forma conseguiremos pasar de un MVP a un producto de éxito.
Imagen: Unsplash | @uxindo
Deja un comentario