Un Mínimo Producto Viable (MVP) no tiene porqué ser un prototipo ni tampoco una versión mínima del producto que con el que puedas empezar a vender
Imagen de @JeisBlack que ha subido la foto a @unsplash
El otro día mantenía con un compañero una discusión sobre qué es un MVP y que no es un MVP que me parece un reflejo vivo de la confusión que muchas personas tienen sobre este concepto de “Mínimo Producto Viable”. Él defendía que si no se tiene un producto que se pueda exponer al cliente comercialmente, entonces no tienes un MVP. Pero otras personas creen que hasta una entrevista lean de problema es un MVP. ¿por qué hay tanta diferencia?
Definiciones famosas de lo que es un MVP
Si nos ceñimos a las definiciones existentes quizás podamos aclarar tanto lío. Los creadores del término dicen…
“A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Es decir: Un MVP es aquella versión del producto que permite al equipo recoger la máxima cantidad de aprendizajes validados acerca de los clientes con el menor esfuerzo. Sin embargo, en innumerables charlas Eric Ries insiste en que, a pesar del nombre, construir un MVP no se trata de crear una versión mínima del producto y que por ejemplo un experimento del test de humo (smoke test) es un MVP.
“A minimum viable product (MVP) is not always a smaller/cheaper version of your final product. It’s about Smart Learning.”
Steve Blank dice que un MVP no es siempre una versión pequeña o más barata de tu producto final y que todo es cuestión de aprendizaje inteligente. Aunque Steve Blank durante mucho tiempo habló del concepto “the minimum feature set” para designar ese conjunto mínimo de funcionalidades que se ha de implantar para convencer a los “visionarios” o “early evagelists” que son los que sin duda ven el potencial del producto y están dispuestos a probarte aunque todavía no lo tengas del todo desarrollado.
“A Minimum Viable Product is the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back).”
Un MVP, dice Ash Maurya, es la cosa más pequeña que puedes construir que entrega valor al cliente (y como lo hace un bono, parte de ese valor, se retorna). Ash Maurya es el promotor de la idea de la ecuación de valor un concepto muy útil que está directamente relacionado con la necesaria evolución de los MVPs. Esta ecuación es una forma sencilla de hacer comprender la necesidad de que el cliente perciba el valor del producto claramente, antes de poder captar dinero de él.
Y es que, si la ecuación de valor no se cumple ¿Qué sentido tiene intentar lanzar tu MVP al mercado?
“Building stuff does not make you a startup […] Startups are building blindly, without focus, as well as falling victim to the “IKEA effect.””
En una entrada fantástica Bill Aulet dice que construir “cosas” no hace que seamos una startup y que la gran mayoría de éstas están obsesionadas con los MVPs desarrollando a ciegas, sin foco, y siendo finalmente víctimas de lo que él llama “el Efecto IKEA” [1]
Con ese término yo me imaginada al emprendedor intentando vender al supuesto cliente un montón de piezas difícilmente ensamblables, pero no tiene nada que ver con esta idea. Con esto del efecto IKEA lo que pretende explicar Bill es el cambio de actitud del emprendedor que pierde la capacidad de seguir ahondando (preguntando, descubriendo) pues se pone a la defensiva con su producto por el mero hecho de haberlo construido.
En definitiva, un MVP siempre ha de ser funcional, es decir, que sea la materialización de la propuesta de valor (UVP). Yo me quedo con la definición más purista: Un MVP es un conjunto concreto de la menor cantidad posible de funcionalidades que permite recoger la máxima cantidad de aprendizaje acerca de los clientes con el menor esfuerzo.
“Un MVP es un conjunto concreto de la menor cantidad posible de funcionalidades que permite recoger la máxima cantidad de aprendizaje acerca de los clientes con el menor esfuerzo.”
[1] El efecto IKEA es un término acuñado en una Paper de Michael Norton, Daniel Mochon y Dan Ariely en donde se demuestra que cuando conseguimos construir algo nosotros mismos, tendemos a valorarlo mucho más que si lo compramos. Más información en el paper de Hardvard.
Pero lo que está claro es que un MPV implica un compromiso del equipo emprendedor para iterar: probar cosas diferentes o experimentar. Por eso insisto en que los conceptos MVP y experimento son equivalentes.
“A Minimum Viable Product Is Not a Product, It’s a Process. […] Eric Ries called it Lean. Kent Beck and other programmers called it Agile. Whatever you call it, the point is to find out which of your assumptions are wrong by getting feedback on your product from real users as quickly as possible. ”
Un MVP no es un producto, es un proceso, se explica en este artículo de YCombinator. Llámalo Lean o Agile, o como quiera que lo llames. Lo que está claro es que el objetivo es descubrir lo más rápidamente posible cuál de tus hipótesis son falsas gracias a la opinión sobre tu producto que tienen los usuarios.
El mayor desafío en un MVP es que “M "está en contradicción con la" V”: es muy difícil de construir algo que es a la vez viable y mínimo, al mismo tiempo.
Si un MVP sí ha de ser “mínimo”, y “viable” al mismo tiempo, pero no ha de ser un “producto”. La “P” podríamos decir que proviene del concepto “premeditado”, como se propone en este vídeo genial que explica los casos de ejemplo de famosos MVPs (Buffer, Dropbox y Zappos)
Es decir, que un MVP ha de ser un intento deliberado de aprender sobre el cliente y sobre la demanda de mercado antes que se disponga de un Producto Máximo Posible 😊. Y existen muchos casos de ejemplo que lo demuestran, como por ejemplo...
“Un MVP ha de ser un intento deliberado de aprender sobre el cliente y sobre la demanda de mercado antes que se disponga de un Producto Máximo Posible”
BUFFER
Buffer es una aplicación que te ayuda a compartir contenidos en las redes sociales. En estas imágenes se muestran ejemplos de sus primeros MVP. En las dos propuestas únicamente permitía publicar en la red social de Twitter pero en la segunda, a diferencia de la primera, se valida si el cliente está dispuesto a pagar por ello. En concreto si el cliente decidía pagar por el servicio, podía seleccionar el modelo de pago, aunque no había forma humana de introducir los datos de la tarjeta de crédito para pagar. Este MVP o experimento les permitió validar la intención de compra. Según parece, el fundador Joel Gascoigne, dijo que después de esos resultados, no dudaron en desarrollar la primera versión funcional del producto real. Y todavía lo recuerdo pues ¡yo lo pagaba! Hoy es un producto freemium mucho más amplio.
Diferentes MVPs de Buffer
Dropbox
Dropbox es un servicio de sincronización y almacenamiento de ficheros en la nube. Uno de los problemas con los que se enfrentaban durante sus primeros días era conseguir que la sincronización de ficheros funcionase para todas las plataformas existentes (Mac, Windows, Linux…). Uno de sus fundadores, Drew Houston decidió hacer un vídeo de 3 minutos para demostrar el proceso desde el principio hasta el final. En el vídeo Drew explica cómo funciona Dropbox moviendo cartulinas con el dedo y en él incluyó todo tipo de “geeks” o frikadas orientadas a atraer early adopters que funcionaron como un hechizo. El vídeo se convirtió en viral, he hizo que la lista de beta testers pasara de 5,000 a 75,000 en tan solo una noche, cuando el vídeo fue promocionado a través de la plataforma DIGGS, que es un agregador de enlaces de interés.
Zappos
Este es uno de los ejemplos de MVP más famosos que existen. En 1999 el co-fundador Nick Swinmurn quería construir una ecommerce de zapatos pero no sabía si la gente lo iba a utilizar. Por ello se recorrió todas las zapaterías de la zona, hizo fotos a los zapatos que creía adecuados, creó una web simple en donde subió las fotos y habilitó el botón de comprar. En cuanto alguien pulsaba para comprar unos zapatos, Nick bajaba a la tienda, compraba los zapatos, los cambiaba de caja e iba a correos a enviar el paquete. Esto es lo que se llama un test de humo en donde simulas el funcionamiento del producto servicio, en este caso sin necesidad de tener una infraestructura montada, ni un inventario. La clave está en que el usuario no se daba cuenta y se consiguen clientes reales que pagan por un producto real, validando la intención de compra. Al final Zappos fue comprado por Amazon en 2009 por ¡1.2 billones de dólares!
Un MVP no tiene porqué ser un producto
Para mí, que sea “funcional” significa “que sirva para algo” al emprendedor, en concreto que le sirva para aprender más rápido que si lo construye de verdad. No nos olvidemos que el objetivo principal de un MVP es el de descubrir y validar el cliente y el modelo de negocio.
“Que sea “funcional” significa “que sirva para algo” al emprendedor, en concreto que le sirva para aprender más rápido que si lo construye de verdad”
Entonces si aceptamos esto último, puede hacerse un MVP de parte del modelo de negocio que no implique la oferta de valor. Tal es el caso por ejemplo de abordar un test de conserje en donde ofreces el servicio, o parte del mismo, como si fueras un conserje de hotel, totalmente manual antes de tener el producto.
Y así, dentro del concepto de MVP nos caben experimentos de bajo nivel tales como…
La realización de entrevistas de solución con Ilustraciones y Storyboards
Abordar sesiones de diseño de la Solución utilizando Storyboards, escenarios y Roleplay
Salir a la calle y hablar con la gente realizando un test de comprensión
Crear una teaser sin saber programar+ hosting en cualquiera de las plataformas para crear webs que hay como por ejemplo squarespace
Montar un Marketplace con sharetribe o Shopify
La gran mayoría de los MVP “dan asco”
Y es que se han lanzado verdaderas cutreces al mercado con la excusa del concepto MVP…
“The problem with Minimum Viable Products is that they are very rarely worthy of dramatic praise, very rarely produce exceptional value, and very rarely earn the attention of the influencers & amplifiers (or at least the early adopters) critical to getting traction.”
El problema con un MVP es que raramente son dignos de ser elogiados, muy raras veces proveen de un valor excepcional y muy raramente atraen la atención de influenciadores y “amplificadores” ( o por o menos de “early adopters”).
Rand Fishkin propone en su entrada que a la hora de lanzar el producto que no seas mínimo, que seas excepcional. Y que siempre puedes experimentar con grupos cerrados hasta alcanzar algo que realmente valga la pena para el público general.
Pero existe una frontera más que difusa entre los diferentes tipos de MVPs. Es muy fácil perder early adopters si tu producto no mejora rápido (frenéticamente). A mí me pasó, después de meses siendo súper rápidos y cuando teníamos a 10 agencias de viajes dispuestas a probar lo que les contábamos, perdimos el “tempo” lean + Agile + experimentación y decidimos abandonar. ¡Pero esa es otra historia!
Un último consejo final: Los fundadores han de ser capaces de evolucionar los primeros prototipos de MVPs de baja fidelidad en MVPs de alta fidelidad y para ello no se puede externalizar el desarrollo de la startup. Lee el artículo de Steve Blank los propios fundadores los que programen.
Más información y recursos útiles sobre este tema: lee los diferentes tipos de MPVs y más ejemplos en la sección de herramientas para MVPs.