Ejemplos de productos mínimos viables (y por qué funcionaron)

La mayoría de los fundadores leen sobre MVP y aun así construyen demasiado. La razón es que 'producto mínimo viable' se ha estirado hasta significar 'versión pequeña del producto final,' que nunca fue lo que significó. Un verdadero MVP es la cosa más pequeña, a menudo vergonzosa, que te permite probar la hipótesis más arriesgada de tu negocio — y muchas empresas famosas empezaron con algo que apenas califica como producto.

Lo que sigue son ejemplos concretos de MVP que funcionaron, qué probó cada uno y qué puedes tomar sin copiar. El patrón en todos ellos es el mismo: elige la hipótesis que mataría el negocio si fuera गलत, y pruébala con la cosa más barata que produzca evidencia honesta.

Airbnb: un sitio de tres páginas y un colchón inflable

La primera versión de Airbnb fue un sitio web hecho en un fin de semana que ofrecía tres colchones inflables en el piso del apartamento de los fundadores durante una conferencia de diseño en San Francisco. No había sistema de reservas, ni pagos, ni reseñas, ni inventario más allá de lo que los fundadores poseían personalmente. Tres personas pagaron ochenta dólares cada una.

Lo que probaron fue la hipótesis más arriesgada: ¿pagarían desconocidos por dormir en la casa de un desconocido? Todo lo demás — pagos, escala, oferta, confianza — podía resolverse después, si y solo si la respuesta era sí. Esa disciplina es lo que la mayoría de los MVP no tienen; construyen las partes fáciles y se saltan la prueba de la parte difícil.

Dropbox: un vídeo de tres minutos

El primer MVP de Dropbox no fue software en absoluto. Fue un vídeo de tres minutos grabado en pantalla que mostraba cómo se sentiría una sincronización de archivos fluida, narrado por el fundador y lleno de referencias que el público objetivo (los primeros usuarios de Digg y Hacker News) reconocerían. La lista de espera pasó de cinco mil a setenta y cinco mil de la noche a la mañana.

La hipótesis que se estaba probando era si suficientes personas querían la experiencia como para justificar construir la compleja ingeniería debajo. El vídeo costó un fin de semana; la ingeniería habría costado un año. Invertir ese orden habría sido un desastre si no hubiera existido la demanda.

Zappos: zapatos de la tienda de enfrente

Antes de construir inventario, almacenes o logística, el fundador de Zappos fue a tiendas de zapatos locales, fotografió zapatos y los publicó en un sitio web básico. Cuando alguien hacía un pedido, volvía a la tienda, compraba los zapatos a precio minorista y los enviaba. Perdía un poco de dinero en cada venta y aprendía una enorme cantidad sobre la demanda.

El MVP probó si la gente compraría zapatos en línea en absoluto — en una época en que la sabiduría convencional decía que no lo harían. La infraestructura que con el tiempo definiría la empresa se dejó para más adelante hasta que la demanda quedó demostrada. Lo barato de la prueba era el punto, no una limitación.

Buffer: un experimento de landing page de dos páginas

El MVP de Buffer fue una prueba de dos páginas. La primera página describía el producto y tres niveles de precios; la llamada a la acción llevaba a una segunda página que decía que el producto aún no estaba listo y pedía al visitante que dejara su correo electrónico. El experimento medía dos cosas: si alguien hacía clic para ver los precios y qué nivel de precio elegía.

Solo después de que la página de precios generara registros significativos, el fundador escribió la primera línea de código. Esa secuencia — validar la disposición a pagar antes de construir — es el patrón menos utilizado en el trabajo de producto en etapas tempranas.

Stripe: instalación en siete líneas

El MVP más temprano de Stripe no era un panel pulido ni un sitio de marketing. Era un fragmento orientado a desarrolladores que prometía pagos en siete líneas de código, instalado manualmente por los fundadores para los primeros usuarios. Literalmente se sentaban junto a los desarrolladores e integraban la API por ellos — un servicio disfrazado de producto.

La hipótesis que se estaba probando era que la experiencia de pagos existente era tan dolorosa que los desarrolladores adoptarían cualquier cosa mucho más fácil. Instalarlo manualmente para los primeros doce usuarios dio a los fundadores una comprensión inigualable de cada fricción de integración. Esa visión dio forma al producto más que cualquier hoja de ruta.

Patrones comunes que puedes tomar prestados

A través de estos ejemplos — y de decenas más como ellos — se repiten algunos patrones. Observa que ninguno de ellos es una "pequeña versión del producto final". Son pruebas de la creencia más arriesgada sobre el cliente, entregadas en la forma más barata posible.

• Identifica la única suposición que acabaría con el negocio si fuera falsa; prueba solo esa.
• Prefiere un servicio manual frente al software cuando la pregunta es sobre la demanda, no sobre la tecnología.
• Cobra dinero real, o mide un compromiso real, en la primera prueba — no después del pulido.
• Usa videos, mockups o landing pages cuando el coste de construir supera el coste de equivocarse.
• Abraza la vergüenza de la versión temprana — el pulido oculta la señal que necesitas ver.

Diseñar tu propio MVP

Escribe en una sola frase la creencia más arriesgada de tu negocio. Luego pregunta: ¿qué es lo más barato, rápido y embarazoso que me diría si esa creencia es verdadera o falsa? Eso — sea lo que sea — es tu MVP. Si puedes entregar el resultado a mano, hazlo. Si un video bastara, crea el video. Si una landing page es suficiente, publica la landing page.

El MVP tiene éxito cuando aprendes algo que cambia tu plan, no cuando lanzas algo bonito. Trata el producto inicial como un instrumento para recopilar evidencia, no como un borrador de la versión final, y gastarás una fracción de lo que la mayoría de los fundadores desperdicia antes de alcanzar el ajuste producto-mercado.