Qué es un MVP. Minimum Viable Product.

Estoy asombrado por la falta de recursos para startups en español. Hace ya un tiempo que sigo la metodología de Lean Startup propuesta por Eric Ries y de Customer Development por Steve Blank. He aprendido cosas increíbles y me parece que es momento de compartirlas.

Este será el primero de una serie (espero) donde voy a tratar de transmitir lo que he aprendido. Por favor tené en cuenta que todo esto son mis opiniones y puedo cometer errores. En tal caso, tus comentarios son bienvenidos.

Ahora sí, ¿qué es un MVP?. Voy a empezar con la definición que da Eric:

Un Minimum Viable Product (Producto Viable Mínimo) es la versión de un producto nuevo que permite a un equipo recolectar la máxima cantidad de conocimiento validado sobre clientes con el menor esfuerzo posible.

Es decir, debemos construir una versión del producto mínima, con la menor cantidad de funcionalidades posibles, que nos permitan empezar a adquirir conocimiento de clientes. La idea detrás es no construir cosas que nuestros clientes no deseen y que al final terminan tirándose. Además, construir un MVP significa que uno quiere aprender algo, quiere obtener algo de ese conocimiento validado. Si uno construye una versión chica de un producto pero no busca obtener ningún conocimiento, entonces no es un MVP.

La versión mínima puede significar: pocas features (funcionalidades), features incompletas o falta de testing (el MVP siempre está buggeado).

MVP: Versión mínima del producto, que permita obtener el mayor conocimiento posible.

Clientes vs Nuestros Clientes

Notá que en la definición puse "clientes" y no "nuestros clientes". La leve diferencia es que muchas veces el MVP también nos ayuda a conocer quiénes son nuestros clientes. Llevando el MVP a diferentes segmentos podemos descubrir quiénes son nuestros clientes para después enfocarnos en qué quieren. Como menciona siempre Steve Blank, cuando armamos un MVP estamos en "search mode" (modo búsqueda) así que ni siquiera podemos saber con certeza quiénes son nuestros clientes.

Cuando construimos un MVP estamos en "Search Mode". Todas son hipótesis sin comprobar. Incluso quién es nuestro cliente.

Recolectar información

Uno comienza un MVP tratando de obtener algún tipo de información. Cuando comenzamos con nuestra startup tenemos múltiples hipótesis que probar. No podemos darnos el lujo de pensar que sabemos qué quieren nuestros clientes (o como mencioné arriba, incluso quiénes son esos clientes), cómo lo quieren, cuándo o a qué precio. Entonces es necesario entrar en el "Build-Measure-Learn loop" o "Ciclo de Construir - Medir - Aprender". La idea es armar cada funcionalidad de nuestro producto con la intención de testear alguna de nuestras hipótesis iniciales. Cada avance de nuestro producto nos permitirá medir, sacar conclusiones, obtener conocimiento validado y volver a construir. Es un ciclo que nunca termina.

Build-Measure-Learn loop

Cuánto es un MPV, cuánto mucho, cuánto poco

Una de las partes más difíciles de armar un MVP es darse cuenta cuál es el mínimo a construir. Por experiencia, siempre se termina construyendo más de lo que se necesita. Es más, podría afirmar que nunca pude crear un MVP (sí, soy un trucho), siempre me excedí en funcionalidades o en testeo. Esta parte es simplemente una cuestión de experiencia que de a poco se va refinando. Lo importante es siempre mantener las hipótesis que queremos validar, para mantener el foco. Como regla general, lo que nosotros consideramos un MVP, siempre tiene el doble o el triple más de funcionalidad de lo que debería ser realmente. Parece desalentador, pero a la larga se va aprendiendo.

El 99% de las veces al MVP le sobran cosas.

Los miedos del MVP

Cualquier persona que escucha o lee sobre MVP siempre tiene el mismo cuestionamiento. Algo así como: "Si hago un MVP con pocas cosas o con bugs mis clientes van a tener una imagen mala hacia mi empresa o producto que no voy a poder cambiar". El miedo es que un cliente enojado llame profesando todo tipo de maldiciones contra nuestro producto, empresa o persona. Además que se lo comunique a otros potenciales clientes y se genere una mala imagen. La realidad es que esto no podría ser más erróneo. Este es el análisis. Hay dos opciones:

  • Que no te llame nadie
  • Que te llamen y te puteen por tu producto incompleto o buggeado

¿Cuál es la mejor opción? ¿Qué es lo mejor que puede pasar? Aunque no lo creas la mejor opción es la segunda. Si tus clientes están tan enojados con tu producto que se llegan a quejar, eso significa que:

  • Los encontraste (o te encontraron). O encontraste un segmento al menos.
  • Les pudiste contar sobre tu producto. Estableciste un canal de comunicación. Ya tenés información sobre ese canal y sobre ese segmento
  • Lograste que lo usen (sino no te putearían). Se interesaron por el producto, lo usaron, validaste la necesidad.

Y lo más importante:

  • Lograste que se interesen tanto por las cosas que le falta al producto o los bugs que tiene que terminan quejándose. Es decir que realmente les importa eso.
  • Ya sabés por qué te putean y podés arreglar/agregar eso en específico.

Lo mejor que te puede pasar con un MVP es que te llamen para putearte por un producto incompleto o buggeado.

El otro caso, si no te llaman, si no obtenes feedback, es claramente desastroso. En algo fallaste, y es muy difícil saber en qué:

  • Segmento de clientes
  • Comunicación
  • Mensaje
  • Canal de distribución

Incluso puede llegar a no existir la necesidad a la que estas atacando! Sería realmente nefasto.