Cómo construir la versión 0.1 de tu producto, rápido

Several distinct problems manifest themselves as delays in launching: working too slowly; not truly understanding the problem; fear of having to deal with users; fear of being judged; working on too many different things; excessive perfectionism. Fortunately you can combat all of them by the simple expedient of forcing yourself to launch something fairly quickly.

—Paul Graham, The 18 Mistakes that Kill Startups

Cada año nos llegan miles de postulaciones a Platanus Ventures. Al programa aplican fundadores con ideas de variadas industrias. A veces, con solo una idea, y otras con un negocio rentable que lleva creciendo meses.

Uno de los factores que usamos para decidir cuáles seleccionar, es la capacidad de los fundadores de construir y probar cosas muy rápido. Hemos tenido que descartar varias startups que llevan mucho tiempo construyendo la primera versión del producto, sin saber si están resolviendo un problema o no.

Construir un producto digital no es fácil, y menos aún hacerlo rápido. Los computines tendemos a preocuparnos más por la tecnología que por resolver el problema: construir la solución, hacer todo automatizado y listo para escalar a millones de usuarios, la interfaz más bonita, animaciones y un montón de funcionalidades.

Lo malo con esto es que es muy difícil que la idea de producto inicial sea lo que los usuarios quieren o necesitan. Dedicarle tiempo a estas cosas al principio nos va a desviar de lo importante: encontrar la solución que mejor resuelva el problema. Según Paul Graham, uno de los errores más comunes que cometen las startups es lanzar muy lento. Otro error común, es lanzar muy pronto. Puede sonar contradictorio, pero lo que sucede es que en general hay un sweet spot entre estos extremos, que es donde hay que apuntar cuando estamos construyendo la primera versión de un producto. Llamemos a este sweet spot versión 0.1.

VERSIÓN 0.1

La primera versión no debería tomarte meses construir–salvo que tengas una startup que lanza cohetes al espacio–, sino un par de semanas. Incluso, he visto fundadores convertir una idea en un producto en un solo fin de semana.

Para llevarlo a un ejemplo, supongamos que quieres solucionar la dificultad que tienen las personas para encontrar actividades de ocio y entretenimiento que les gusten en su ciudad.

Un posible MVP para resolver este problema podría ser una aplicación web que permita a los usuarios buscar y descubrir actividades de ocio cerca de su ubicación, filtrando por categorías de interés y precio.

Las funcionalidades de este MVP podrían ser: una base de datos con lugares donde hacer actividades, un sistema de búsquedas, más información de cada actividad y un sistema de reserva y compra de entradas.

Hay un problema: construir algo con todas esas funcionalidades va a tomar tiempo. Y podría ser tiempo botado a la basura si es que te das cuenta que no es un problema, o que no es la solución correcta.

Para testear la idea no necesitas que los usuarios puedan buscar todas las actividades posibles: puedes hacerlo tú por ellos. Tampoco necesitan registrarse y pagar a través de la aplicación. Si sacas esas funcionalidades de la ecuación, lo que en realidad necesitas es algo bastante parecido a un google form, donde el usuario ponga qué cosas le gusta hacer, cuánto quiere pagar y quizás, a qué horas tiene tiempo. Pero a nadie le gusta contestar formularios de google, y en este caso podría parecer poco profesional.

Algo intermedio, y casi igual de rápido, es hacer una landing donde el usuario pueda entender la propuesta de valor y lo que haces, junto a un campo de texto donde pueda dejar su número de teléfono y la información necesaria para que puedas mandarle las actividades que mejor se ajusten a sus preferencias.

MVP usuario - chicle - core

Hay un curso de Jaime Bunzli para el curso de startups que explica esto muy bien, hasta le pone un nombre que me gusta más que MVP: el modelo UCC (usuario - chicle - core). Explicado muy brevemente, el core es el algoritmo o funcionalidad mínima que resuelve el problema; y el chicle es lo que haces para que el usuario interactúe con él.

En el caso anterior, el core vendría siendo las herramientas que uses y la forma en que obtienes la información, y el chicle serías tú conversando por Whatsapp con el usuario para mandarle las actividades y gestionar las reservas por él.

Pueden suceder dos cosas. La primera, es que no te llegue ningún mensaje, aún habiendo publicado la landing en todos los grupos de Whatsapp, Reddit, hecho un post en LinkedIn y haberlo mandado a familiares y amigos. Es el peor de los casos, porque significa que en realidad las personas no tienen ese problema, pero aún así no es tan terrible—perdimos un fin de semana construyendo algo que nadie quería. Toca cambiar de idea 🤷‍♂️

La otra posibilidad, es que te empiecen a llegar muchos mensajes diarios. No vas a dar abasto si sigues con la solución manual, pero va a ser un happy problem. Acá es donde tienes que mejorar el chicle: tratar de automatizar y mejorar la experiencia del usuario y el backoffice. Para cuando de verdad necesites construir algo más elaborado, vas a tener más datos para modelar mejor la solución y vas a entender mejor el problema. El camino para construir esa solución 10x o 100x mejor que lo existente va a ser mucho más claro.

Cuando vayas a construir la primera versión de un producto, para cada funcionalidad que quieras que tenga, es útil preguntarse: ¿qué tan necesario es esto?, ¿puedo hacerlo yo manualmente al comienzo? Si la respuesta es que no es extremadamente necesario para el core, mejor dejarlo para más tarde y lanzar antes.