La técnica del Producto Mínimo Viable nos puede ayudar a despejar incógnitas sobre la viabilidad de nuestro negocio. Pero muchas veces la viabilidad no es nuestra incertidumbre más prioritaria.

Como decíamos en otro post, el Producto Mínimo Viable (MVP) es una técnica muy útil pero poco entendida. Hay quien considera que el MVP debe ser mínimo desde una perspectiva del usuario/cliente (“la funcionalidad mínima para que al usuario le resulte útil y nos pague”) y quien le da a esta característica la perspectiva del proveedor (“el experimento más sencillo y barato que podemos realizar para despejar una incertidumbre de negocio”).

Pero no podemos olvidar que el MVP es un enfoque cuyo objetivo último consiste en evitar el construir productos que los clientes no desean. Los campos del software y la Web 2.0 proporcionan ejemplos de MVPs que han llegado a ser muy habituales:

• Presentaciones, animaciones, vídeos, mockups… para validar ideas, conceptos y diseños iniciales.
• Smoke test con una landing page que describe los beneficios de nuestro nuevo -y todavía inexistente- producto e invita a sus visitantes a registrarse/comprar. Contabilizando esos clics obtenemos una medida del interés del futuro producto para sus potenciales clientes.  Habitualmente el tráfico hacia la página se compra con anuncios PPC.
• La clásica técnica de pruebas  de usabilidad conocida como “Mago de Oz” o “Turco Mecánico”, que consiste en simular una cierta funcionalidad por medios manuales. Así podemos comprobar si una funcionalidad compleja -pero que todavía no hemos desarrollado-  le podría resultar útil a sus usuarios.

Como vemos, estas técnicas buscan despejar incertidumbres esenciales sin necesidad de embarcarse en la creación de un “producto” o algo similar por lo que el cliente vaya realmente a pagar. Por eso decíamos que el MVP no debe ser realmente un producto. En un MVP -como en todos los casos de investigación de mercado- la clave está en priorizar nuestras incertidumbres/hipótesis a validar, en definir qué información deseamos adquirir y en diseñar una manera creativa y barata de conseguirla.

En cuanto a cuáles son las incertidumbres más importantes relacionadas con un producto, la respuesta depende del caso y del punto de vista. Probablemente si le preguntamos a un partidario del design thinking nos dirá que la incertidumbre más importante es la “deseabilidad”, mientras que un entendido en experiencia de usuario optará por la “usabilidad”… y un ingeniero resaltará la “factibilidad”. En general, según diferentes enfoques y perfiles, solemos hablar de las siguientes áreas de experimentación y validación de un producto (a veces no totalmente disjuntas):

• Deseable: ¿cuánto les gusta el producto a los usuarios? ¿quieren usarlo?
• Útil: ¿cómo resuelve el producto los problemas de los usuarios? ¿les sirve para algo?
• Usable: ¿el producto va a ser fácil de utilizar para sus usuarios? ¿pueden usarlo?
• Factible: ¿vamos a poder construir el producto con la tecnología disponible?
• Viable: ¿el producto va a ser un negocio rentable?

Así pues, si hablamos del Producto Mínimo Viable no hay razón para que no lo hagamos también de Productos Mínimos Factibles o Usables… o Deseables. Dependiendo del caso y el momento las incertidumbres prioritarias estarán en una u otra área. En un ejemplo extremo como podría ser un medicamento contra el cáncer los riesgos solo van a estar del lado de la factibilidad, ya que la deseabilidad, utilidad, viabilidad, etc. casi se dan por descontadas.

En la realidad, es posible que una cierta hipótesis -y el experimento correspondiente- esté a caballo de dos o más de estas áreas: por ejemplo, el precio puede tener que ver con la viabilidad pero también con la deseabilidad. Sin embargo, como dice el manual de Estadística deberíamos diseñar nuestros experimentos de modo que los resultados fueran atribuibles a una sola variable.

Este reciente énfasis en el desarrollo de productos dirigido por hipótesis viene motivado por la confluencia del mundo de la Web 2.0 y una serie de enfoques de diseño y experimentación aplicados a la innovación. Estos enfoques se popularizaron durante los últimos años del pasado siglo gracias a la disponibilidad y al abaratamiento de nuevas tecnologías. Técnicas como la simulación, el prototipado rápido o la química combinatoria han ayudado a construir experimentos y “prototipos de alta fidelidad” en las industrias de la automoción, los circuitos integrados, el software o la farmacia.

En sectores donde el desarrollo es enormemente caro, complejo y arriesgado, la experimentación ha servido para eliminar riesgos de todo tipo y en todas las fases del desarrollo (desde la concepción, no sólo en la verificación final). Pero estas técnicas sólo son eficaces si conllevan un cambio de mentalidad: un experimento que “falla” (que no confirma nuestras hipótesis) no es un fracaso, el único experimento que fracasa es el que no nos permite aprender nada. La clave está es utilizar estas técnicas desde el principio y -por supuesto- pensando en los prototipos como algo desechable que sirve para aprender, no como la base para el desarrollo del producto.

Siempre hay sorpresas y es mejor descubrirlas antes de construir el producto y de que éste se encuentre en fase beta… o liberado. Si no lo hacemos así el resultado sí que será realmente un fracaso en el que habremos utilizado a la organización de ingeniería/fabricación para construir el “prototipo más caro del mundo” y a los clientes reales como involuntarios (y decepcionados) “conejillos de indias”.

Para concluir, y volviendo al Producto Mínimo Viable, creo que es un caso de una idea muy buena (aunque no totalmente original) pero con un nombre muy desafortunado.

Este post en «Marketing & Innovación».

[¿Estás interesado en identificar oportunidades de mercado, valorando y priorizando los riesgos? Este documento te enseña cómo descubrir y comprender mercados que todavía no existen.]

Uno de los conceptos clave del “emprendimiento ágil” es el de Producto Mínimo Viable. Pero aunque la idea resulta intuitivamente atractiva y comprensible, la realidad es que se aplica de formas muy diferentes y existe una cierta confusión sobre lo que realmente significa en la práctica.

Sin duda uno de los conceptos más mencionados en los últimos dos años es el de Producto Mínimo Viable (MVP, Minimum Viable Product); tanto que no puedes hablar con un emprendedor 2.0 sin que te intente vender SU MVP. Esta técnica se suele aplicar en contextos de emprendimiento ágil (Lean Startup, Customer Development), originalmente en el mundo de las aplicaciones Web 2.0. En esencia se trata de un experimento controlado, consistente en salir al mercado con un producto preliminar que nos permita obtener feedback y medir resultados, aprender e iterar nuestro producto. Pero en este post me gustaría centrarme no tanto en lo que es el MVP como en algunos mitos y concepciones erróneas sobre él.

En primer lugar, la idea de experimentar en el mercado para ir refinando innovaciones discontinuas no es nueva (recordemos el Probe and Learn y otros enfoques) y el propio concepto de MVP tiene antecedentes muy ilustres en forma de Minimum Marketable Feature Set y otros.

Sin embargo, el MVP suele ser un concepto no muy bien entendido y aplicado, probablemente -y esto es mi opinión- porque incluso en el círculo de sus promotores (Eric Ries, Steve Blank, Ash Maurya…) la idea parece haber tenido varias versiones. (Aplicando la terminología al uso, diríamos que el MVP es un concepto que ha “pivotado” ;- ).

Por ejemplo, según Steve Blank uno de los principios del Customer Development es “salir de la oficina” y descubrir cuál es el conjunto mínimo de prestaciones por el que los clientes pagarán en la primera versión del producto.  Este conjunto mínimo es lo que ha pasado a llamarse “producto mínimo viable” y una manera de descubrirlo es preguntarse “¿Cuál es el problema más pequeño o menos complicado que los clientes nos pagarían por resolver?”. Como Steve explica, todavía no estamos comercializando nuestro producto a un público general, sino que estamos vendiendo nuestra visión a los visionarios –valga en este caso la redundancia- pero proporcionándoles inicialmente un conjunto mínimo de características. Estos visionarios-evangelizadores, que adoptarían y promoverían inicialmente el producto y nos proporcionarían feedback (y dinero) para iterarlo y mejorarlo, se denominan “earlyvangelists” en la jerga del Customer Development.

Por su parte, Eric Ries define el MVP como ese producto que posee solo aquellas prestaciones (y no más) que nos permiten despertar el interés de los early adopters, algunos de los cuales nos pagarán en dinero o nos proporcionarán feedback. Sin embargo, en otro post Eric define el MVP como esa versión de un nuevo producto que nos permite adquirir el máximo aprendizaje validado sobre los clientes con el mínimo esfuerzo. Aparentemente, según esta segunda definición el objetivo del MVP es más general que simplemente comprobar si los clientes nos dicen que están dispuestos a pagar… o si efectivamente pagan. Pero sobre todo, la diferencia más importante radica en el hecho de que en la primera definición quien decide cuándo se ha alcanzado el producto mínimo es el cliente (interesándose o pagando por él) y en la segunda definición es el proveedor (si el experimento le permite despejar una incertidumbre de negocio).

Creo que tanto la definición de Blank como la primera de Ries son demasiado restringidas y centradas en el MVP como “producto” orientado a que unos early adopters nos paguen con dinero y/o feedback. (Todos entendemos la diferencia entre un producto y, por ejemplo,  una presentación de un concepto ¿verdad?) Son definiciones obviamente influidas por los conceptos de Core Benefit / Generic Product de T. Levitt en los años 60, el de Minimum Marketable Feature Set de la Incremental Funding Methodology y el de “producto umbral” para vender en el early market antes de desarrollar un producto completo para “cruzar el abismo”. En esa línea, hace varios años que en este blog defendemos que salir al mercado con conjuntos de características reducidos -pero enfocados en “resolver bien un problema”– contribuye a reducir no sólo el time-to-market sino también el time-to-adoption de un nuevo producto.

Pero en una startup -o en el caso de una innovación discontinua- hay muchas incertidumbres relacionadas con el modelo de negocio en general que habría que despejar antes de descubrir si los visionarios pagan por nuestro producto y cómo nos pueden ayudar a mejorarlo. Por ejemplo: si hay un problema en el mercado, a cuánta gente afecta, cómo de importante y urgente es el problema para ellos, si existen soluciones/alternativas ya disponibles (seguro que sí, aunque solo sea el statu quo), cuál es el grado de satisfacción con esas soluciones…

El problema de esas primeras definiciones es que pueden llevar a pensar que el MVP es uno, mínimo, viable y producto, cuando en realidad no tiene por qué ser ninguna de esas cosas.

El MVP no es único -como corresponde a cualquier proceso iterativo- y la naturaleza y contenido de cada MVP/experimento dependerá del aprendizaje que queramos adquirir o de la incertidumbre que queramos eliminar.  Nuestro proceso de aprendizaje en el mercado es en parte una sucesión de MVPs.

El MVP no es mínimo, al menos en un sentido “matémático”: no hay procedimiento infalible que nos permita definir el MVP en cada caso y el proceso depende en gran medida de nuestro buen juicio y el sentido común. Y no debe ser mínimo desde la perspectiva del usuario, sino desde nuestra perspectiva como experimentadores: debe ser el experimento más barato que nos permita capturar la información que necesitamos.

El MVP no es viable, en la interpretación habitual de viabilidad económico-financiera (a menos que por “viable” entendamos que “nos permite obtener un aprendizaje validado”). Aunque sí hay un caso particular en el que el MVP tiene esta característica: el de un MVP que consiste efectivamente en un experimento para comprobar la viabilidad del producto (¿los clientes compran y pagan? ¿cuánto? ¿en qué proporción? ¿cuánto nos cuesta conseguirlos como clientes?…)

Pero lo que radicalmente no debería ser un MVP es un producto (o una “versión” de un producto). Si tu primer MVP es algo parecido a un producto (que en su forma actual resulta útil a algún cliente y por lo que está dispuesto a pagar) estás prescindiendo del beneficio principal de este enfoque en cuanto a validación de las hipótesis básicas. Además, un producto -o algo parecido a él- suele exigir invertir cuantiosos recursos en desarrollo y una vez que este proceso está en marcha puede ser difícil cambiar sustancialmente el rumbo. Si esperas a tener algo desarrollado para hacer experimentos puede ser demasiado tarde.

Por eso prefiero definiciones de MVP como ésta (adaptada de Wikipedia): MVP es una estrategia dirigida a evitar el construir productos que los clientes no desean y que busca maximizar la información que se adquiere acerca de nuestros clientes por cada euro invertido. Es un proceso iterativo de generación de ideas, prototipado, recogida de datos, análisis y aprendizaje.

En un próximo post veremos algunos ejemplos de MVPs, hablaremos de cómo utilizar esta técnica para resolver incertidumbres de toda índole relacionadas con un nuevo producto y analizaremos el papel del prototipado en este proceso.

¿Qué opináis? ¿Cuál es vuestra experiencia con el MVP?

Este post en «Marketing & Innovación».

[¿Estás interesado en identificar oportunidades de mercado, valorando y priorizando los riesgos? Este documento te enseña cómo descubrir y comprender mercados que todavía no existen. ]