Cabecera personalizada

El blog de Mikel Niño
Emprendimiento digital, startups, Big Data Analytics y nuevos modelos de negocio

Deconstruyendo el MVP: de "Producto Mínimo Viable" a "Prueba Mínima con Valor"

El concepto del "Minimum Viable Product" (MVP) o "Producto Mínimo Viable", siendo uno de los elementos clave de la metodología Lean Startup, parece también un concepto del que cuesta entender la esencia y que suele malinterpretarse. Creo que gran parte de este efecto se debe a que nos quedamos demasiado con las palabras concretas que componen la "etiqueta" que Eric Ries decidió utilizar y el significado que tienen para nosotros. Por esa razón suelo explicar el concepto de MVP manteniendo el acrónimo pero eligiendo otras palabras que ayuden a recordar su significado y que a su vez sean más próximas a la esencia que encierra. Así, en vez hablar de "Minimum Viable Product" prefiero explicarlo como "Minimum Valuable Proof" ("Prueba Mínima con Valor"). Voy a detenerme en cada palabra para explicar el motivo de este ligero cambio en la etiqueta (que no en la esencia o el sentido del concepto).

Lo que podemos decir sin mucho temor a equivocarnos es que la idea de "Mínimo" está bastante clara :-) Esta es quizá la parte del acrónimo que recoge la esencia "lean" del método, tratando de evitar el despilfarro de recursos y de acortar el tiempo en el que podemos completar una vuelta al ciclo "construir-medir-aprender".

En cuanto a la "P", creo que centrarnos demasiado en la idea de "Producto" nos despista de la naturaleza real del MVP ya que, como bien dice Ramli John en esta entrada de su blog, "the MVP is not about the product". Por esta razón prefiero utilizar la palabra "Prueba" ("Proof"), que podemos interpretar de dos maneras que explican claves importantes acerca del MVP:
  • "Prueba" entendida como el proceso de probar, es decir, como un experimento, ya que está es la verdadera naturaleza del MVP,
  • y "Prueba" entendida como la evidencia que buscamos obtener gracias al MVP, ya que experimentamos "por experimentar" sino que queremos evidencias que nos permitan confirmar la veracidad de nuestras hipótesis acerca del producto y del potencial de negocio que esperamos que le rodee.

Respecto a la "V", en mi opinión resultaría más clarificador mantener la idea original de MVP como algo "Valuable" (algo que aporta "Valor"), ya que esto nos permite explicar una relación de doble sentido del valor que esperamos obtener con el experimento:
  • Valor para el emprendedor, por el aprendizaje validado que le permite validar/refutar sus hipótesis y asunciones, y de esa manera confirmar si va por el buen camino e identificar qué es necesario cambiar o si debe "pivotar" por completo,
  • pero también valor para el cliente potencial, ya que la experiencia de interacción con el MVP debe aportarle el valor (o recrearlo de la mejor manera posible, en función del estado de desarrollo y automatización de nuestra solución) que esperamos aportarle con la solución final. Dicho de otra manera, el énfasis no está tanto en el aspecto que adopta lo que le estás poniendo delante al cliente potencial, sino en que sea capaz de simular de la mejor manera posible el contexto y la experiencia de uso reales en las que se manifiesta el problema y se aplica la manera de solucionarlo (como una imagen vale más que mil palabras, he aquí un ejemplo perfecto para ilustrar esta idea). Sólo así conseguiremos el feedback adecuado respecto al potencial de nuestra apuesta de solución.


[See here for the English version of this entry]

2 comentarios:

  1. Anónimo3/6/14 10:02

    Dicen que el diablo se esconde en los detalles... y la comprensión de los conceptos en los matices: ¡Muy Vien Presentado! (no voy a dejar que la ortografía me estropee estropee unas buenas siglas)

    ResponderEliminar
  2. Personalmente he meditado el asunto y llegué a estas conclusiones. Si, realmente la naturaleza del PMV implica dos cosas que eventualmente no le quedan bien claras a Steve Blank por tratar de resaltar las iteraciones con los clientes. 1. "Algo" con unos requerimientos mínimos.
    2. Ese algo implica necesariamente unas pruebas o interacciones con los clientes para mejorar.
    Ese "Algo" puede ser un producto en si o una descripción apropiada de ello.

    ResponderEliminar