Lanzando un Producto Mínimo Viable

Durante los últimos 6 meses he participado en el lanzamiento de dos aplicaciones web en las que hemos tratado de seguir los consejos de la metodología de la Startup Liviana (Lean Startup). La primera es Class.io, una aplicación para mejorar la comunicación entre maestros y estudiantes. La segunda es KidsAbacus.com, una aplicación para padres y madres de familia en que pueden crear y administrar “contratos de comportamiento” con sus hijos.

Uno de los elementos más importantes de esta metodología es el Producto Mínimo Viable (PMV), o explicado en pocas palabras: un prototipo con funcionalidades mínimas que nos sirve para confirmar si existe un mercado interesado en nuestro producto. Desde que empecé a leer acerca de la Startup Liviana en 2009 (en el blog de Eric Ries) me sentí identificado con muchos de los consejos y decidí aplicarlos en la medida de lo posible en mis nuevos proyectos.

Me gustaría compartir con ustedes algunas de las lecciones aprendidas en estas experiencias, específicamente aquellas que ayudan a desarrollar y lanzar rápidamente prototipos al mundo real.

1. ¿Qué tan Mínimo debe ser un PMV?
En teoría, un PMV puede ser tan sencillo como un anuncio en Google Adwords o incluso un mensaje en twitter en que anuncias un producto que no existe aún. Todo depende de la etapa de desarrollo en que estemos. Las etapas pueden ir desde el concepto/idea hasta un producto ya establecido que está experimentando con nuevas funcionalidades (features). El objetivo principal de un PMV es medir el nivel de interés, aceptación y reacciones que este ocasiona en un mercado meta.

Por ejemplo, para un nuevo producto o servicio que aún no hemos desarrollado, el PMV podría ser simplemente un anuncio en Google Adwords que expresa el beneficio que el cliente obtendría. Lo que haríamos con este anuncio es simplemente enlazarlo a una página sencilla que describe “el producto”, aunque este no exista, y con esto podemos medir un nivel inicial de interés. Si vemos que un porcentaje considerable de personas están haciendo clic en el anuncio podríamos estimar que hay al menos un segmento de mercado interesado en el producto y proceder a una segunda iteración del producto.

2. ¿Qué son las iteraciones de un PMV?
Un Producto Mínimo Viable no es un fin sino un medio. Un medio para llegar eventualmente al producto final (a veces nunca hay final). Por lo tanto, cada versión mejorada del producto puede llamarse una “iteración” (sinónimo de repetición).

Es importante tener claro que durante el proceso de ejecución, el PMV pasará por múltiples iteraciones. En cada iteración tendremos un objetivo de aprendizaje diferente, mediremos lo que los usuarios dicen o hacen y aprenderemos de estos datos. Con ese aprendizaje procederemos rápidamente a desarrollar la siguiente iteración y  así nos mantenemos en un “círculo virtuoso” de aprendizaje, mejora y refinamiento del producto.

3. ¿A quién mostrar la primera iteración del prototipo?
En mi experiencia es bueno mostrar la primera iteración del producto a personas un poco más técnicas que podrían en algún momento formar parte de tu equipo. Esto sirve para que veas si hay otros interesados a unirse al equipo en áreas como diseño, programación, deployment/servidores, mercadeo, community management, etc.

La primera versión de tu producto por lo general será visualmente simple, sin mucho texto explicativo, sin detalles y con errores. Por eso es que quienes lo vean deben tener algo de conocimiento técnico para que entiendan la idea general, pero que no se sientan desalentados porque ‘esta feo’.

Una vez que tenemos una versión un poquito más refinada podemos comenzar a mostrarla a personas ‘normales’ que se fijarán más en el beneficio del producto y no tanto en lo técnico. Para esta versión importa más que sea claro el beneficio del producto y la facilidad de uso.

4. Siempre que sea posible forma un equipo de trabajo
Aunque puedas desarrollar el prototipo trabajando sólo, siempre es recomendable que vayas formando un equipo de trabajo. Aunque sólo sea otra persona y formen un equipo de dos, he encontrado que es útil trabajar en equipo por algunas razones como:

  • Si trabajas sólo no tenés nada que te obligue a dedicar tiempo a trabajar en el producto. En cambio, cuando ya estás trabajando con una o dos personas, el hecho de tener que coordinar algunas horas de reunión para trabajar ya te obliga a apartar el tiempo necesario. Aunque nunca se reúnan físicamente, la división de responsabilidades también te da un sentido de obligación para cumplir tu parte o terminar lo que estas haciendo porque los otros te están esperando para seguir con su parte.
    .
  • Si trabajas sólo podes quedarte estancado en una decisión creativa por mucho tiempo. En cambio, cuando tenés otras personas con quienes pensar en las diferentes opciones, podés tomar una decisión de inmediato. Por ejemplo, algo tan sencillo como “se ve bien este botón a la izquierda o la derecha?”, si estás sólo esa pequeña decisión puede tomar varias horas. Si tenés alguien al lado algo así se soluciona en dos o tres minutos.
    .
  • Casi siempre podés avanzar más rápido cuando son varios. Digo “casi siempre” porque depende. A veces, si hay mucha gente trabajando en lo mismo más bien se atrasa el progreso. Siempre y cuando puedan dividirse el trabajo de forma efectiva, el trabajo en equipo hará que avancen más rápido. Una forma efectiva de dividir el trabajo es que cada miembro del equipo tenga responsabilidades en áreas funcionalmente separadas: programación, diseño de front-end, configuración de servidores, social-media, mercadeo, negocios/estrategia, etc.

5. Acelera el desarrollo con Hackathons (o al menos intentos de hackathons)
Para quienes no estén familiarizados con el término, un Hackathon es una marathon de programación+desarrollo+diseño en que un equipo de trabajo se encierra por una cantidad de horas dedicadas exclusivamente a completar una versión funcional de un producto. Podría ser por ejemplo un Hackathon de fin de semana en que todo el equipo se reúne y trabaja desde las 10AM hasta las 10PM todo el sábado y el domingo exclusivamente en completar la primera versión del producto. O si son más vampirezcos, pues de 10PM a 10AM  ;)

En Class.io utilizamos esta forma de trabajo para acelerar el desarrollo de las primeras versiones. Ya después cada miembro del equipo queda haciendo mejoras incrementales al producto a medida que se recibe retroalimentación de los usuarios. Pasado un mes o cierto tiempo en que las mejoras pendientes ya son muchas conviene hacer otro Hackathon para implementar rápidamente todas las mejoras.

6. Antes de lanzar un versión al público, crea expectativa y mide interés
Siguiendo los consejos de la Startup Liviana, hay que hacer un poco de “Desarrollo de Clientes” (Customer Development) en paralelo mientras hacemos el “Desarrollo del Producto”. Un primer paso en este proceso es identificar a las personas que estarían interesadas en utilizar nuestro producto.

En mi caso particular con KidsAbacus lo que hice fue simplemente sacar un twitt al aire (y un status update en facebook) en que preguntaba “quién tiene hijos entre 6 y 12 años de edad y quiere probar una nueva webapp que lanzaré en una semana y días…?”

Con ese simple mensaje obtuve más de 45 personas, entrerespuestas de twitter y de facebook que me pidieron que les avisara en cuanto lanzaramos la versión de pruebas. Todo esto ocurrió 10 días antes de tener listo el prototipo y sirvió para tener desde antes una lista de personas a quienes invitar a hacer pruebas.

24 horas después del lanzamiento ya habíamos recibido más de 400 visitas, más de 2,500 pageviews y lo más importante, más de 40 usuarios probando la aplicación.

7. Antes de lanzar un versión al público, instala scripts de tracking
Mientras estás desarrollando la primera versión es posible que mostrés la aplicación a personas cercanas (amigos y familia) usando el webserver de tu computadora de desarrollo. Cuando haces ese tipo de demos podés ver lo que hacen y dicen las personas al probar la aplicación.

El problema cuando lanzás la aplicación públicamente a internet es que ya no podes verles la cara ni recibir sus comentarios de inmediato. Para esto es útil que antes de abrir la aplicación al público instales algunos scripts para poder analizar su comportamiento (navegación) y capturar sus sugerencias.

Algunas herramientas que he usado para esto y que me han servido bastante son:

  • Google Analytics: Las estadísticas de tráfico que proporciona nos ayudan a conocer datos como: países desde donde nos visitan, versión de navegador que usan, palabras de búsqueda por las que nos encuentran, tiempo promedio de visitas, número de páginas que ven los visitantes, páginas más leídas en nuestro website o app, y otros datos que podemos configurar como metas de conversión.
    .
  • GetSatisfaction: esta herramienta sirve para que los usuarios puedan enviar sus ideas, sugerencias, comentarios y reportes de errores que encuentran en la aplicación. En KidsAbacus nuestros usuarios han sido bastante activos enviando su retroalimentación.
    .
  • MixPanel: una excelente herramienta para medir acciones específicas en sitios y aplicaciones web. Con GoogleAnalytics podría lograrse algo similar usando “Metas”, pero MixPanel proporciona reportes en tiempo real y es mucho más personalizable en cuanto a capturar datos y acciones propias de tu aplicación.

8. Aprende del feedback y vuelve a iterar
Una vez que comienzas a recibir feedback de tu aplicación, debes tomarlo positivamente y aprender del mismo. Tus usuarios están tratando de ayudar cuando te mandan comentarios de cosas que podrías mejorar, así que no hay que sentirse ofendido si nos dicen que algo no está bien… hay que tomar los comentarios y analizar, aprender y corregir.

También hay que considerar que la mayoría de los usuarios que se registren en la aplicación no saben que estás haciendo un “Producto Mínimo Viable” y todo eso. Ellos ven un sitio web que ofrece algo y esperan que funcione bien. Si encuentran algo que no entiendan o no funcione te lo van a reportar diciendo “falta esto”, “debería de hacer esto”, “hay un error en esto”. La mayoría de las veces tu respuesta inmediata sería: “Si… yo se… pero es que no está terminado, es un producto mínimo viable” . Esa respuesta debes dejarla en tu cabeza y tomar los comentarios del usuarios como validación y confirmación de que la idea tiene futuro y lo que sugieren tus usuarios es algo que necesitan.

Si nadie usa la herramienta y nadie te manda comentarios, es posible que a nadie le importe lo que estás haciendo y no haya un mercado interesado en el producto.

9. Hay que iterar rápidamente
Ya que el Producto Mínimo Viable es sólo un medio y no un fin, es necesario iterar rápidamente. En cuanto recibamos retroalimentación hay que tomar todos los comentarios, evaluar prioridades y retomar el desarrollo para lanzar rápidamente las mejoras.

En las etapas tempranas del desarrollo de un producto es necesario iterar rápida y frecuentemente para no perder el interés de los usuarios y que sientan (y sepan) que sus comentarios son tomados en cuenta.

En conclusión
La metodología de Startup Liviana está agarrando más auge cada vez y veo que muchas empresas la están poniendo en práctica. En mi experiencia ayuda bastante a sacar productos rápidamente al aire para verificar si estos tienen o no un futuro y podamos decidir si les dedicamos más recursos.

En el pasado, principalmente trabajando para clientes en proyectos de desarrollo web, había trabajado apegado a la teoría de desarrollo que enseñan en la universidad, en la que antes de comenzar el desarrollo hay un análisis y diseño del sistema, luego el documento de especificaciones, después el desarrollo, luego pruebas, y al final lanzamiento. Todo ese proceso toma (dependiendo del alcance) entre 6 meses y 1 año, pero es hasta el final que nos damos cuenta de lo que los clientes piensan acerca de nuestro producto final.

Con la nueva mentalidad de Producto Mínimo Viable, podemos lanzar un producto mucho más rápido (5 semanas por ejemplo) y luego entrar en el círculo virtuoso de retroalimentación y mejoras.

Para aprender más acerca de la metodología de Startup Liviana simplemente Google: Lean Startup