El "Minimum Viable Product" (MVP) entendido como táctica y no como producto

Hemos analizado anteriormente el concepto de "Minimum Viable Product" (MVP) o "Producto Mínimo Viable", una de las herramientas básicas dentro de la práctica de Lean Startup. Son varias las referencias que podemos encontrar advirtiendo de los errores más habituales que se cometen a la hora de llevar a la práctica este concepto. Creo que gran parte de ellos se deben a la literalidad con la que muchas veces nos tomamos las "etiquetas" que nos vienen dadas para designar un recurso dentro de un método o manera de trabajar (en este caso el MVP). En esta entrada quiero destacar alguna de las ideas que me parecen más importantes para solucionar estas confusiones.

Gran parte de los malentendidos vienen por el uso de la palabra "Producto" y el sentido tradicional que le damos a dicho término dentro de un contexto de desarrollo de soluciones digitales (incluso empleando metodologías de trabajo incremental), donde se van construyendo prototipos o productos parciales orientados a una demostración funcional del modo de empleo de la solución final que estamos creando. En estos casos siempre estaríamos hablando de "codificar" todo o parte del producto software final, cuando en realidad el concepto de MVP, a pesar de su nombre, está más ligado a la idea de una "herramienta de contraste" (sea en el soporte que sea) con la que podamos facilitar al cliente [1] una mínima interacción cuyo resultado podamos analizar y, sobre todo, [2] una percepción completa del valor de lo que podría ser la solución final, pero sin contar necesariamente con la implementación software (ni siquiera parcial) de dicha solución. No estaríamos por tanto hablando de "productos" en el sentido tradicional, sino más bien de diferentes "tácticas" a adoptar para exponer nuestra propuesta de solución a nuestros potenciales clientes.

Dado que el grado de desarrollo de nuestra propuesta de solución y, lo que es más importante, nuestra certeza sobre lo correcto de la misma serán diferentes según avance nuestro trabajo, en función de dicho avance podremos manejar diferentes planteamientos de MVP. Por poner algunos ejemplos, si nos encontramos en los primeros pasos en los que sólo tenemos una idea de cómo se describe la solución a los clientes y cuáles son sus características principales, podemos crear una  página web ("landing page") con dicha información y recogiendo (¡y analizando!) las muestras de interés de potenciales compradores. Si tenemos una idea más clara de cómo es el proceso completo que resuelve el problema, antes de invertir demasiados recursos en programación, podríamos incluso utilizar ciertas tácticas ("mago de Oz", "conserje") para resolver manualmente todo o parte del proceso sin tener que construir todo el software necesario para su automatización, pero pudiendo ofrecer al potencial cliente una simulación de la experiencia integral que tendría usando el producto una vez construido.

Vemos por tanto que podemos contar con un abanico de diferentes "tácticas MVP", algunas más cercanas que otras a la idea que tradicionalmente tendríamos de un producto digital, pero todas ellas basadas en la idea del MVP como un medio para un fin (contraste y aprendizaje), es decir, tácticas soportadas en elementos de muy diversa índole y con mayor o menor grado de construcción de producto software, pero siempre dirigidas a validar si la orientación que le estamos dando a la solución va por el buen camino y si realmente hay una cierta masa de clientes que la podría adoptar.

[See here for the English version of this entry]