Recientemente tuve la oportunidad de debatir con un reducido [pero selecto] público acerca del concepto 'Minimum Viable Product' (MVP), una idea de la que se ha hablado bastante en los últimos meses en gran medida gracias a una entrevista que hicieron a Eric Ries los chicos de Venturehacks.
En estos momentos hay suficiente información disponible en el dominio público sobre MVP, desde una mini-guía elaborada por el propio Eric, hasta un buen artículo introductorio en la Wikipedia, como para que no sea necesario extenderse demasiado en esta entrada [pero al final lo haré, me conozco!].
En primer lugar, a mí me gusta entender el MVP como un EXPERIMENTO de negocio. En efecto, podríamos definirlo como el producto con el menor número de funcionalidades necesario para conseguir un objetivo específico de aprendizaje. Pero también podemos entenderlo como el producto con el menor número de funcionalidades necesario por el que los usuarios están dispuestos a pagar con algún tipo de recurso escaso, entendiendo por tal atención, información o dinero. No hay ninguna ley que impida que ganes dinero con un MVP. Es más, lo lógico sería que lo hicieras en algún momento. En este caso no lo veo tanto como un 'experimento' sino más bien un eficaz instrumento para conseguir tus objetivos de negocio al tiempo que minimizas los riesgos.
El MVP se entiende dirigido al mercado temprano, ese formado por Pioneros chalados [innovators, pioneers, coolhunters, trendsetters] junto con Visionarios pragmáticos [early adopters]. Juntos conforman aproximadamente el 17 por ciento de tu mercado. Si tu producto es verdaderamente innovador, son ellos a los que debes dirigirte primero. De esta manera, tu MVP puede entenderse como un medio para que tus clientes más innovadores te ayuden a encontrar [financiar] el producto o servicio 'definitivo'.
En realidad, en la búsqueda de tu modelo de negocio [completo, testeado, viable, escalable] no tendrás sólo "un" MVP, sino toda una serie de ellos, sucesivas versiones de tu producto o servicio que te permitirán ir consiguiendo objetivos de aprendizaje o negocio sucesivos. De hecho, Eric Ries ha llegado a decir que una start-up es una sucesión de MVPs. No le falta razón.
Este proceso se lleva a la práctica mediante iteraciones ultra-cortas del ciclo de desarrollo ['release early, release often']. Es una idea muy 'agile', estrechamente emparentada con enfoques de desarrollo software del tipo Test-Driven Development (TDD) [tal como lo veo, en TDD, primero escribes el test de la unidad funcional, luego codificas hasta que el test deja de fallar; con MVP, en cierto modo 'vendes primero, construyes después']. Eric relaciona el uso de MVPs con la gestión Lean [Lean como en Lean Manufacturing], pero también podríamos encontrar puntos de contacto con el trabajo del Coronel John Boyd, concretamente con su [archiconocido] OODA Loop, así con los planteamientos realizados desde la Teoría de las Limitaciones alrededor del flow management, sobre los que escribí en otra ocasión.
MVP tiene antecedentes en el Minimum Marketable Feature Set [MMFS] de la Incremental Funding Methodology [IFM] desarrollada por Mark Denne y Jane Cleland-Huang, autores de Software by Numbers, un clásico de la literatura de la ingeniería del software. También los chicos de 37 signals, desarrolladores de servicios como Basecamp, han contribuido a popularizar el concepto [aunque no mencionen explícitamente el termino MVP] con la publicación hace unos años de su libro Getting Real [lectura obligada]. Pero sobre todo, MVP está en deuda con uno de los más importantes Principios detrás del Manifiesto Agile, el que nos recuerda que la Simplicidad, entendida como el arte de maximizar el trabajo no hecho, es esencial.
El MVP no es un concepto exclusivo de las empresas puras de internet. Estoy trabajando con muchos emprendedores de la "economía real" utilizando el concepto de Producto Mínimo Viable a través de metodologías que he ido poniendo a punto en colaboración con mis clientes. También esas metodologías son, a su manera, MVPs.
Hace unos meses supe que una empresa de Portland disputa el copyright del término Minimum Viable Product a Eric Ries, pero no conozco los detalles del tema.
Mario, aunque acabo de leer el libro llevo unos meses arrancando mi idea de negocio con esta filosofía de lean startup. Los que estén interesados les invito a opinar o colaborar sobre www.comefruta.es
Posted by: Jose Luis Montesino | 05/18/2012 at 12:57 PM
Gracias por tu comentario, Iván.
Las tres funcionalidades básicas de cualquier social network service, son, en mi humilde opinión:
- Creación de perfil
- Búsqueda de perfil
- Comunicación con otros perfiles
Todas ellas con las respectivas medidas para garantizar la privacidad e intimidad de la persona.
Posted by: Mario | 09/10/2009 at 11:36 AM
Muy interesante el concepto y además me has dejado pensando por qué tres funcionalidades se decantaron para la red social que crearon.
Posted by: Iván Hernández Perera | 09/10/2009 at 11:35 AM
Ángel, qué buen ejemplo! Me lo apunto :)
Posted by: Mario | 09/08/2009 at 01:22 PM
Estoy muy de acuerdo con el planteamiento de la necesidad de liberar lo antes posible un producto con una calidad minimanmente aceptable y añadir las posibles mejoras aportadas por los usuarios en fases posteriores.
Y mucho más hoy en día en el que los requerimientos cambian de un día para otro y las decisiones, estrategias o gustos de los usuarios varrían muy rápidamente.
En mi caso, me ha tocado discutir en más de una ocasión para hacer ver a mis clientes la posibilidad de retrasar o no incluir determinadas funcionalidades que ellos creían "imprescindibles" el día de los lanzamientos para que una vez los usuarios se adapten a las herramientas puedan incluso definir de una manera mucho más detallada sus necesidad.
Me anoto tu entrada para un futuro post :)
Saludos
Posted by: Jconsu | 09/08/2009 at 11:56 AM
Esta es de las que uno dice: "y por qué no ve lo habían contado antes".
En un proyecto de migración de versión de un CRM tiramos a la basura más de un 30% del desarrollo que se había realizado en la primera intalación porque nadie lo utilizada. Esto fue clave para finalizar el proyecto dentro del plazo previsto. Los que con toda seguridad no llegaron a tiempo fue los que hicieron la primera implantación en la que se dedicaron cientos o miles de horas para algo que nadie iba a utilizar.
Me apunto a MVP: empezar con los imprescindible. Y añadiría: continuar con los que vayamos identificando como necesario junto con los usurios. O no continuar añadiendo funcionalidad que puede no ser necesario.
Posted by: Angel | 09/08/2009 at 11:44 AM