¿Mínimo? ¿Viable? ¿PRODUCTO?

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. ]

Categorías: desarrollo de producto, descubrimiento de mercados, gestión de producto