Qué es un MVP: el producto mínimo viable explicado con ejemplos reales y sus límites

Un producto mínimo viable es un experimento, no un producto pequeño

Quien pregunta qué es un MVP suele esperar un tipo de producto: una aplicación pequeña, una primera versión a medias. Se parece más a un experimento que trae un producto consigo. Wikipedia en inglés define el producto mínimo viable como una versión con las funciones justas para que los primeros clientes la usen y den su opinión para el desarrollo posterior. Una cafetería que prueba los pedidos anticipados con un formulario sencillo para sus habituales, antes de pagar una aplicación, ya ha hecho uno.

Según el mismo artículo, el término lo acuñó y definió Frank Robinson en 2001 y lo popularizaron Steve Blank y Eric Ries. De Ries es la fórmula que citan los fundadores: en agosto de 2009, en su blog Startup Lessons Learned, lo llamó la versión de un producto nuevo que permite a un equipo reunir el máximo aprendizaje validado sobre los clientes con el menor esfuerzo. El aprendizaje es el resultado; el esfuerzo, el coste.

Lo que un MVP no es: borrador, prototipo, demo para inversores

El nombre confunde, y el propio Ries lo admite: el MVP, pese a su nombre, no consiste en crear productos mínimos. En el extracto de su libro The Lean Startup que TechCrunch publicó en 2011 añade que no es necesariamente el producto más pequeño imaginable y que, a diferencia de un prototipo, su objetivo es probar hipótesis de negocio fundamentales, no solo cuestiones de diseño o técnicas. Un prototipo demuestra que algo puede funcionar. Un MVP muestra si los clientes reales lo quieren.

Tampoco es un permiso para lanzar algo roto. El artículo de Wikipedia recoge la crítica: los productos por debajo de la calidad mínima esperada pierden frente a competidores que llegan con un listón más alto, y las opiniones negativas sobre un lanzamiento temprano pueden dañar la reputación de la empresa. Una demo para inversores es otra cosa: enseña lo que podría existir a quienes nunca lo usarán. Lo único que hace un MVP tiene que funcionar bien.

La pregunta que responde y la hipótesis escrita antes del código

El sitio de The Lean Startup resume el propósito en una línea. La pregunta no es si este producto se puede construir; las preguntas son si debería construirse y si cabe levantar un negocio sostenible a su alrededor. Un equipo competente con tiempo suficiente construye casi cualquier cosa. Que unos desconocidos cambien un hábito y paguen por el resultado es una incógnita hasta que alguien lo intenta.

Wikipedia da un ejemplo. En 2015, especialistas de la Universidad de Sídney idearon el robot Rippa para automatizar las tareas agrícolas y el control de malas hierbas. La hipótesis técnica, que el robot distinguía las malas hierbas del cultivo, ya estaba demostrada; la de negocio, que sería una herramienta viable en una granja en funcionamiento, no. Una empresa pequeña escribe esa distinción en una frase antes de cualquier código: quién es el cliente, cómo resuelve hoy el problema, qué hará con el producto y qué cifra en qué fecha contará como un sí.

Tres tipos de MVP, cada uno con un ejemplo documentado

El tipo más ligero no contiene producto alguno. Ries cuenta la historia de Dropbox en el extracto de TechCrunch: el software no se podía demostrar en forma de prototipo, así que su director ejecutivo, Drew Houston, grabó un vídeo sencillo de tres minutos para los usuarios pioneros de la tecnología. Según Houston, la lista de espera de la beta pasó de 5000 a 75 000 personas literalmente de la noche a la mañana. Aquí, concluye Ries, el vídeo era el producto mínimo viable. Una página que recoge inscripciones funciona igual.

El segundo tipo es una landing page que pide algo más que un correo. Joel Gascoigne, fundador de Buffer, describió la suya en el blog de la empresa en febrero de 2011. La primera versión eran dos páginas para comprobar si la gente se plantearía siquiera usar la aplicación. Después intercaló una página de precios para ver qué plan elegían los visitantes, y unos pocos pulsaron en los de pago. Solo entonces construyó el producto, y el primer cliente de pago llegó en los cuatro días siguientes al lanzamiento.

El tercer tipo es un servicio hecho a mano detrás de un escaparate sencillo. El artículo de Wikipedia sobre el lean startup, citando a Ries, describe cómo Nick Swinmurn, fundador de Zappos, comprobó si los clientes comprarían zapatos por internet. Fotografió las existencias de zapaterías locales, publicó las fotos, compró los zapatos a precio completo al cerrar cada venta y los envió al cliente. El tipo más simple es una sola función bien hecha: Gascoigne quería tomar la programación de publicaciones de las aplicaciones de Twitter y hacerla excelente.

Recortar el alcance: un usuario, un escenario, un resultado

En el alcance se tuercen la mayoría de las primeras versiones, y ninguna fórmula lo resuelve. Ries lo reconoce en su guía: hace falta criterio para decidir, en cada contexto, qué MVP tiene sentido. Elige un tipo de usuario, el que se topa con el problema más a menudo. Elige un escenario, el camino desde que abre el producto hasta que obtiene lo que vino a buscar. Elige un resultado que el usuario pueda ver y tú puedas contar.

Gascoigne dijo que la primera versión le llevaría una semana; fueron siete, y aun así tuvo que dejar fuera el registro guiado paso a paso que había planeado. Los recortes se parecen de un proyecto a otro: un segundo rol de usuario, los ajustes, un panel de administración que una hoja de cálculo sustituye durante un mes, las integraciones, una aplicación móvil junto a la web. Nada de eso es mala idea. Cada cosa responde a una pregunta que nadie ha hecho todavía.

Qué medir tras el lanzamiento y qué cuenta como respuesta

El día del lanzamiento produce cifras, y la mayoría halagan. Wikipedia, en la entrada dedicada al lean startup, separa dos clases. Las métricas de vanidad dan la imagen más favorable posible sin reflejar lo que mueve el negocio; el ejemplo típico es el número de usuarios nuevos por día. Si captar a cada usuario con publicidad cara cuesta bastante más que los ingresos que aporta, ganar más usuarios podría llevar pronto a la quiebra. Las métricas accionables son las que conducen a una decisión de negocio fundamentada.

En una primera versión las cifras accionables son pocas. Cuántos de los que vieron la oferta probaron el producto, cuántos volvieron sin recordatorio, cuántos pagaron. Gascoigne presentó las suyas: unos dos meses y medio después del lanzamiento, más de 500 usuarios y alrededor de un 4 % que pasaba a planes de pago. Una respuesta necesita además un umbral fijado de antemano; si no, cualquier resultado se lee como un estímulo. El sitio de The Lean Startup nombra la decisión siguiente: cuando los motores del modelo de negocio no se mueven, es hora de pivotar o corregir el rumbo de forma estructural.

Tres errores: un año construyendo, ninguna cifra, interés por cortesía

El primer error es la obra interminable. El sitio de The Lean Startup lo describe así: demasiadas startups empiezan con un producto que creen que la gente quiere y pasan meses, a veces años, perfeccionándolo sin enseñárselo nunca, ni en una forma muy rudimentaria, a un posible cliente. Cuando los clientes comunican por fin, con su indiferencia, que la idea no les importa, la startup fracasa. Ries es igual de estricto consigo mismo: en su guía recuerda dos semanas dedicadas a una función que absolutamente nadie quería y las considera demasiado tiempo.

El segundo error es lanzar sin nada que medir: sin umbral ni contador en la única acción que importa, de modo que cualquier resultado parece un avance. El tercero es confundir la cortesía con la demanda. Los amigos elogian la idea, los visitantes dejan un correo, y nada de eso les cuesta nada; la página de precios de Gascoigne hacía que el interés costara un clic más. El método también tiene un límite: Wikipedia cita investigaciones según las cuales un lanzamiento temprano puede perjudicar más que ayudar si un competidor puede imitar el producto y no hay otra barrera.

Qué preparar antes de encargar un MVP a un estudio

Algunas de estas pruebas no necesitan desarrollador. Una página con una oferta y un formulario, un vídeo corto, un servicio prestado a mano a los diez primeros clientes: el dueño de un negocio puede hacerlas solo antes de pagar por software. Encargar tiene sentido cuando solo un producto que funciona puede responder la pregunta: cuentas de usuario, pagos, datos que no se pueden perder, un escenario demasiado largo para simularlo a mano. Incluso entonces, el encargo es la hipótesis, no una lista de pantallas.

Así que lleva una hoja: el único usuario, el único escenario, el resultado que debe obtener, la cifra y la fecha que contarán como un sí, y lo que ya te han enseñado las pruebas más baratas. VITON13 Studio construye MVP de aplicaciones web a partir de encargos así; el alcance y el coste están detallados en la guía y en la página del servicio enlazadas. Con esa hoja, la pregunta de qué es un MVP se vuelve práctica: cuál es la versión más pequeña capaz de demostrar que te equivocas.