NON-CODE, De la idea a recibir pagos en 7 semanas: ¿cómo lo hicieron?

<div><link href='https://fonts.googleapis.com/css?family=Montserrat' rel='stylesheet'></div>

<FONT FACE=" Montserrat " SIZE=3 >

En este artículo, contaremos sobre los inicios de Buffer y la aventura emprendida por Joel Gascoigne en el 2011. Tomando de referencia el testimonio que compartió sobre su experiencia en dicho entonces.

El caso de Buffer, representa un buen ejemplo de la importancia de empezar con la validación de un producto mínimo viable antes de construir un producto. Desde el lanzamiento, en un periodo de 2 meses y medio, obtuvieron más de 500 usuarios en sus primeras interacciones.

Hoy (2021), decenas de miles le generan ingresos vía planes de membresía mensual. Además han levantado USD 4 Millones de dólares.

Joel Gascoigne , founder de Buffer lanzó Buffer por el 2011, en sus primeras interacciones logró más de 500 usuarios. Hoy decenas de miles le generan ingresos vía sus planes mensuales. Luego de todo esto, en total han levantado USD 4 Millones de dólares de inversión.

Para desarrollar la idea no tuvo que programar (non-code)” pero sí validar y revalidar, usando el MVP, para luego recién construir poco a poco y paso a paso.

<FONT SIZE=4 COLOR="#3B8FFC">Para Joel todo empezó con un destello de idea. “Una pequeña idea</FONT>

Él quería crear una forma de poner en cola los tweets sin programar cada tweet individualmente, que fuera realmente útil con una experiencia agradable. Esta idea se le ocurrió después de usar otras aplicaciones de programación de Twitter, tenía como propósito no inundar a la gente con 5 tweets a la vez, mientras leían sus noticias de tecnología y startups por la mañana. No podía sacar la idea de su cabeza, entonces se lo sugirió a aplicaciones existentes que ejecutan este tipo de programación, pero no lo implementaron. Entonces dijo que era hora que construya por sí mismo.

<FONT SIZE=4 COLOR="#3B8FFC">Manteniendo la versión 1 al mínimo. No más mínimo que eso.</FONT>

Gascoigne defiende los principios de MVP que propone Eric Ries. Con su primera startup, aprendió y trató de implementarlos, pero la práctica es mucho más difícil que la teoría.

Cuando le tocó hacer un MVP de Buffer, comenzó a construir líneas de código, estaba programando Buffer antes de probar la viabilidad del negocio. Cuando se dio cuenta de que estaba construyendo antes de validar, se detuvo, respiró hondo y dijo: "hazlo de la manera correcta esta vez. Hora de probar si la gente quería este producto."

Ries responde en su libro el Método Lean Startup "¿Cuán mínimo debe ser su Producto Mínimo Viable?": Probablemente mucho más mínimo de lo que crees.

Joel había leído esa línea tantas veces. Incluso se lo había contado a otros y era hora de que lo pusiera en práctica por él mismo.

<FONT SIZE=4 COLOR="#3B8FFC">La prueba más pequeña</FONT>

El objetivo de este MVP era comprobar si las personas considerarían usar la aplicación. Así que tuiteó el enlace y preguntó a la gente qué pensaban de la idea. Obtuvo algunos útiles comentarios por correo y Twitter, “lo consideró validado". En palabras de Eric Ries, su primer "aprendizaje validado" sobre los clientes.

--> Ahora a obtener un aprendizaje “un poco más” validado.

<FONT SIZE=4 COLOR="#3B8FFC"> Aprendiendo más</FONT>

Así que validó que la gente probablemente quería el producto.

Lo siguiente “a validar” era si las personas pagarían por este producto. Simplemente agregaron una página entre las dos que mostraban los precios.

Colocaron una sección que vía un clic adicional seleccionara que tipo de plan pagarían, antes de que envíen su correo para recibir una notificación cuando inicien operaciones.

Dos aprendizajes validados:

Aprendieron de la validación que:

1. Si quieren un plan hacen click
2. Un click adicional en su correo, por lo que deberían estar interesados

<FONT SIZE=4 COLOR="#3B8FFC"> Este es el gráfico de lo que hicieron:</FONT>

El resultado de este experimento fue:

1. La gente seguía haciendo clic y enviando su correo electrónico
2. Un pequeño número de personas hacían clic en planes pagos.

--> Después de este resultado, comenzó a construir el MVP del producto real y funcional.

<FONT SIZE=4 COLOR="#3B8FFC"> El lanzamiento de Buffer
</FONT>

A inicios de Octubre prometió "¡Lo sacaré en una semana!", pero subestimó el tiempo que tomaría construir su primera versión funcional de Buffer. Construyó la primera versión por la noche y los fines de semana durante 7 semanas.

• Hubo características que sintió como muchos emprendedores que eran vitales como un proceso de registro guiado paso a paso, luego tuvo que omitir porque el fin de mes de noviembre llegó muy rápido.
• Cumplió su compromiso. Buffer inició el 30 de noviembre y recibió excelentes comentarios de la comunidad de Hacker News.

<FONT SIZE=4 COLOR="#3B8FFC"> Estar preparado para un viaje largo con muchas correcciones de rumbo</FONT>

Antes de Buffer ya había construido un producto y las cosas no fueron como lo planeó.

• Esto le preparó para ser paciente con la aceptación del servicio y estar dispuesto a hacer cambios hasta que llegue a algo realmente valioso para las personas.
• Le enseñó el valor del desarrollo del cliente: aprovechar los correos que recibe haciendo preguntas. (Con su producto anterior, no se comunicó con suficientes personas) Usaba mal esta frase: "¿Es esto un problema para usted?" para validar si el producto era algo que la gente pudiera querer (eso es no recomendable).
• Después de lanzar una versión de Buffer que le dio vergüenza, esperaba que tuviera poca aceptación y que tuviera que trabajar mucho para ajustar el producto con el fin de ganar usuarios activos y clientes de pago.

Ya sea que se alcance la meta antes o después de lo esperado, siempre hay momentos en los que se requiere paciencia, es una mentalidad general instaurada en Buffer.

<FONT SIZE=4 COLOR="#3B8FFC"> Aprovechando cuando las cosas van bien</FONT>

Pese a estar preparado para un largo viaje, siempre se requiere mentalidad paciente, tuvo suerte con Buffer, pues había tocado la fibra sensible de los usuarios y resolvía un problema que tiene mucha gente. También vió que la solución proporcionaba suficiente valor para construir un negocio viable; su primer cliente pagó 4 días posteriores al lanzamiento del producto “en bruto”.

Joel Gascoigne dice: “Después del primer cliente que pagó, di un paso atrás, lo reconocí como un hito importante y decidí que se necesitaba un ligero cambio de enfoque.”

• Como programador, es fácil desarrollar más funciones en ese momento.
• Sabía que era hora de centrarme en el marketing y mayor desarrollo del cliente.
• Era momento de mantener el equilibrio entre la programación, el marketing y el desarrollo del cliente con el producto que demostró que era "suficientemente bueno".

La lección es cuando la señal de que el producto es lo suficientemente bueno, ¡gritarlo!

<FONT SIZE=4 COLOR="#3B8FFC"> ¿Qué sigue?</FONT>

Siempre hay más retos. Desde el lanzamiento, contrató a otra persona para administrar la comunidad y el marketing, y desarrolló interfaces para los datos existentes y más.

Joel indicó que:

• Ganaron una gran cantidad de cobertura de prensa.
• Trabajaron en una estrecha colaboración con los usuarios a nivel personal.
• Implementaron más funciones y cambiado los planes de precios.
• Implementó un feed de actividad de administración y realizado análisis de cohortes.

<FONT SIZE=4 COLOR="#3B8FFC"> Finalmente invitamos a contar tus anécdotas:</FONT>

¡Coméntanos!

Links

• Fuente principal - Joel G
• TechCrunch - inversión recibida

</Font>