Mínimo Producto Viable: ¿Qué es y Para qué?

Construir un producto en un startup es diferente

El proceso para desarrollar un producto en un startup o en cualquier ambiente con altos niveles de incertidumbre, es muy diferente al modelo usado tradicionalmente. En un startup, tanto el problema (lo que el cliente necesita) como la solución (lo que debe hacer el producto) son desconocidos. Esto requiere una combinación de un proceso iterativo para entender el problema del cliente a través de hipótesis y experimentos y al mismo tiempo, desarrollar la solución a través de datos y retroalimentación. En la práctica este proceso requiere desarrollar prototipos y múltiples versiones del producto para mostrarlo a los clientes e irlo refinando en base a sus reacciones.

Este enfoque, el cual combina elementos del Proceso de Desarrollo de Clientes de Steve Blank y métodos de desarrollo ágil, se conoce como un lean startup, y el Mínimo Producto Viable (MVP por sus siglas en inglés) es una estrategia clave para ayudar a los startups a construir su producto mientras aprenden lo que el mercado necesita, al enfocarse en realizar múltiples iteraciones del producto para depurarlo con base en la retroalimentación de los clientes.

Un MVP permite aprender sobre los clientes

Un Mínimo Producto Viable es una versión de un producto que permite a un equipo recabar la mayor cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo posible. Es usado para probar rápidamente de manera cuantitativa y cualitativa la respuesta del mercado a un producto o una funcionalidad específica. Un MVP tiene sólo aquella funcionalidad requerida para mostrar el producto al cliente y su principal objetivo es evitar el desarrollar productos que los clientes no quieran y maximizar la información obtenida sobre los clientes con base en el costo y esfuerzo invertidos.
A pesar de su nombre, el MVP no se trata solamente de crear un producto. Es una estrategia y un proceso enfocados en crear y vender un producto a un grupo de clientes. Es un proceso iterativo de generación de ideas, desarrollo de prototipos, presentación, recolección de datos, análisis y aprendizaje. Si el objetivo es simplemente crear algo rápido, un MVP en sí no es realmente necesario. En la mayoría de los casos, un MVP requiere esfuerzos adicionales en invertir tiempo en hablar con clientes, definir métricas y analizar los resultados.

Un MVP esté enfocado en early adopters y clientes visionarios

Un MVP contiene sólo la funcionalidad mínima requerida para aprender de los “earlyvangelists” – clientes visionarios y early adopters. Típicamente, el producto está enfocado en este tipo de clientes, los cuales en principio son más tolerantes, están más dispuestos a proporcionar retroalimentación y poseen mayor capacidad para entender la visión del producto con sólo un prototipo o información básica del producto, además de ayudar a llenar los ‘huecos’ en la funcionalidad deseada.

Un MVP puede ser diferente dependiendo del producto

No hay una fórmula exacta para definir un MVP ya que se requiere cierto nivel de criterio y depende del contexto del producto. Por ejemplo, al equipo de IMVU, un cliente de Instant Messaging en 3D, le tomó 6 meses crear su MVP original, en contraste con otras compañías donde la primera versión llega a tomar 5 años antes del lanzamiento. Sin embargo, en otras ocasiones puede tomar hasta 2 semanas desarrollar cierta funcionalidad que al final nadie quería, cuando una simple prueba a través de anuncios en Google hubiera podido demostrar en unos días que nadie estaba interesado.

Un MVP permite aprender y cambiar de dirección si es necesario

El mayor desperdicio que puede haber al crear un producto es construir algo que nadie quiera. Un MVP busca comprobar que efectivamente el producto resuelva una necesidad del mercado antes de tener que invertir demasiados recursos en su desarrollo.

Normalmente se construye un primer prototipo y después de mostrarlo a algunos clientes (aún si nadie lo quiere inicialmente), a través de iterar rápidamente es posible corregir el rumbo sin tener que invertir esfuerzo de más, gracias a la retroalimentación frecuente que se tiene, comparado con pasar meses encerrados construyendo el producto “perfecto” para después darse cuenta que no era lo que el mercado quería. Lo importante es recordar que si el producto resuelve una necesidad real, un MVP permite alcanzar una gran visión en pequeños incrementos.

Una metáfora que ayuda a ilustrar cómo funciona el proceso, es el concepto del ciclo de Observar/Orientar/Decidir/Actuar que tiene sus fundamentos en teoría militar. Según John Boyd, el creador del modelo, “la clave de la victoria es ser capaces de tomar las decisiones apropiadas más rápido que el enemigo”.

El mismo principio aplica a los startups, los cuales normalmente se enfrentan al problema de tener que maniobrar en terreno con condiciones confusas o desconocidas, por lo que deben tener la capacidad de generar hipótesis, aprender rápidamente y reaccionar ante condiciones desconocidas. Un MVP, es una de las herramientas críticas que permite lograr este aprendizaje, ya que permite realizar múltiples iteraciones, las cuales facilitan el aprendizaje y la flexibilidad.

Cómo construir un MVP

El objetivo principal en el proceso de desarrollo de un startup es minimizar el ciclo de decisión, el cual consiste en Construir – Medir – Aprender a través de ideas, código y datos, buscando minimizar el tiempo total en cada iteración. El proceso es repetido hasta que se obtiene el producto que efectivamente responde a la necesidad del mercado o hasta que se determina que el producto no es viable. La figura 1 ilustra este proceso.


Figura 1. Proceso de desarrollo de MVP

Algunas tácticas que pueden ser usadas en cada etapa del proceso son:

• Construir: Generar lotes pequeños y producción continua.
• Medir: Realizar pruebas A/B para verificar hipótesis.
• Aprender: Construir un mínimo producto viable, apoyarse en análisis de causa raíz.

Ejemplos y técnicas

A continuación se mencionan algunas técnicas y ejemplos prácticos de MVPs en acción:

Sólo un landing page. Este enfoque es lo que podríamos llamar “vender antes de construir”, y consiste en empezar solamente con una página web de inicio (landing page) describiendo el producto a desarrollar con un link para solicitar más información. Se utiliza publicidad en Google u otros medios para generar tráfico a esta página y ofrecer el producto. En este sencillo experimento es posible comprobar cuánto interés hay en el producto – por ejemplo, si 0% de los visitantes hace click en la oferta de compra, entonces no hay razón para desarrollar el producto, ya sabemos que no hay interés en él. Es mejor usar esos recursos para redefinir el producto y encontrar qué características son las que efectivamente desea el mercado.

Probar funcionalidad específica. Insertar un link a una nueva funcionalidad en una aplicación web, el cual dirige a una sección con mayor información o solicitando al usuario registrar su interés. Los links son registrados y sirven como una medida de qué tan necesaria es esa funcionalidad. Por ejemplo, Fliggo (un servicio para compartir videos) empezó a ofrecer una versión pagada además de su versión básica preguntando a sus clientes si querían recibir una notificación cuando el nuevo producto estuviera listo. Al hacer esto, pudieron medir el interés de los usuarios: si muy pocos se registraban, sabían que ese no era lo que los clientes deseaban sin haber tenido que construir el producto completo.

Eliminar funcionalidad, enfocarse en una sola cosa. La idea original para Grooveshark (servicio de música en línea), era combinar elementos de Limewire, eBay, Wikipedia, Facebook, LastFM e iTunes. Después de darse cuenta que el producto iba a ser increíblemente complejo (un monstruo de Frankenstein, de acuerdo a uno de los fundadores), la compañía se enfocó en ofrecer una simple función: buscar una canción y reproducirla. Después de probar varias hipótesis, empezaron a agregar funciones adicionales.

Crear un producto sencillo. El primer prototipo de Twitter fue creado en un periodo de dos semanas, el cual fue suficiente para que varios usuarios lo pudieran probar. Si dos semanas parecen demasiado, considera que el MVP de Cloudomatic, un servicio para promover aplicaciones en línea, fue construido en un fin de semana. De ahí la frase: “hay una versión de 2 semanas de lo que sea”.

Manualización (flintstoning). Para comprobar si un cliente requiere o no cierta funcionalidad pero sin tener que realizar un desarrollo completo, se puede utilizar la estrategia de flintstoning, la cual consiste en dar la apariencia de que algo se hace de forma automatizada, aunque en realidad tras bambalinas se haga manualmente. El término viene de Los Picapiedra (The Flintstones), que movían sus automóviles con los pies. Existe una historia de una persona que quería vender autos en línea, pero esto requería escribir un producto bastante complicado y no sabía si funcionaria o no. Así que creó un website con formas, pero todo el procesamiento de la información era manual —lo que pasaba detrás de escenas era realizado a mano— y esto fue suficiente para confirmar que el negocio podría funcionar.

Lanzar 1.0 e iterar rápidamente. La recomendación más importante es lanzar la primera versión del producto e iterar con base en la retroalimentación de los clientes. Por ejemplo, PayPal empezó como un servicio de transferencia de dinero entre PDAs y al poco tiempo se dieron cuenta de que no había mucha demanda para este producto. Sin embargo, también notaron que la funcionalidad de transferir dinero por email (una función a la que ni siquiera le habían puesto mucha atención) estaba atrayendo múltiples usuarios y el resto es historia. Otros ejemplos incluyen la primera versión de Facebook, Windows, y hasta el iPod 1.0 (se pueden encontrar imágenes de todas estas primeras versiones en Wikipedia). La regla de oro para saber cuándo lanzar viene de Reid Hoffman, fundador de LinkedIn: “Si no te da vergüenza la primera versión de tu producto, es que esperaste demasiado para lanzar.”