Lecciones y prácticas aprendidas al impulsar el crecimiento de Logto con desarrolladores.
Logto es un producto de código abierto enfocado en desarrolladores. Aquí está nuestra cronología para salir al mercado:
Proveniente de un entorno de crecimiento liderado por el producto para herramientas de productividad, los equipos y yo probamos diferentes estrategias para salir al mercado con Logto. Después de dos años, reflexioné sobre esos esfuerzos y los pasos que tomamos. Quiero compartir parte de ese viaje y explicar por qué algunas cosas no funcionaron en ese momento. No son "errores", sino lecciones valiosas de nuestra experiencia. Espero que estos conocimientos ayuden a otros que trabajan en proyectos o startups similares.
Cuando lanzas tu producto por primera vez, especialmente con una mentalidad de crecimiento del producto o con algo de experiencia, es fácil pensar en todo tipo de ideas emocionantes: flujos de incorporación impresionantes, una gran demostración en el sitio web, formas geniales de resaltar el valor para los usuarios y llevarlos rápidamente al momento "ah-ha". Para que nuestro producto se vea bien terminado y listo para la comercialización, implementé dos estrategias de activación:
Estas estrategias habían sido muy exitosas en mi experiencia pasada. Así que cuando Logto lanzó su versión alojada en la nube, las apliqué inmediatamente. Sin embargo, me encontré con cierta confusión y desafíos:
Para los productos para desarrolladores, es difícil resolver un problema en poco tiempo, incluso si puede ser realmente autoservicio. Incluso para un solo desarrollador, el proceso involucra varias etapas: integrarse con la pila tecnológica adecuada, crear una prueba de concepto, probar en un entorno de desarrollo y luego pasar a producción. En cualquier punto de este viaje, los usuarios pueden abandonar. El "trabajo a realizar" no es una tarea simple de un solo paso. Las necesidades de los desarrolladores suelen ser complejas, requiriendo una variedad de características o escenarios técnicos que necesitan un diseño cuidadoso aprovechando nuestras capacidades existentes. Resolver estos problemas lleva tiempo y no puede apresurarse.
Al mirar atrás, está claro por qué este enfoque no tuvo éxito. Cuando lanzamos por primera vez, nuestros registros diarios y el tráfico orgánico eran bastante bajos. La mayor parte de nuestro tráfico provenía de la comunidad de código abierto, que naturalmente no traía clientes más grandes. No es sorprendente que no viéramos clientes más grandes reservando llamadas durante esta etapa. El bajo tráfico y la fuente de nuestros usuarios hicieron poco realista esperar un número significativo de reservas de llamadas desde el principio.
Elige el modelo que se ajuste a tu producto, basado en el tiempo necesario para la activación del usuario. No dejes que las normas de la industria te limiten.
Al construir un producto SaaS, una de las preguntas clave para salir al mercado (GTM) es si elegir freemium o una prueba gratuita. La sabiduría común sugiere:
Inicialmente elegimos un modelo freemium para un lanzamiento rápido, estableciendo un muro de pago entre los planes gratuitos y de pago. Sin embargo, los desarrolladores no podían acceder a características avanzadas como SSO o Organización en el nivel gratuito.
Aunque hay mucho debate en línea sobre cuál modelo es mejor, es crucial dar un paso atrás y considerar la línea de tiempo de activación de tu producto. Para Logto, hemos observado que en el mundo real, la fase de prueba puede durar hasta 6 meses. Esto no se debe a la complejidad de Logto, sino más bien al horario de trabajo del ingeniero, la planificación de proyectos, flujos de trabajo del equipo y otros factores que no habíamos anticipado.
Dada esta larga fase de activación, es importante proporcionar a los desarrolladores acceso completo a todas las características para las pruebas. Por eso aprovechamos completamente el inquilino de desarrollo para desbloquear las capacidades completas del producto. Esta es una práctica común para herramientas de desarrollador, pero vale la pena mencionar ya que explica por qué las estrategias tradicionales de freemium o prueba gratuita pueden no funcionar para nosotros.
La elección debe alinearse con la naturaleza de tu producto y su línea de tiempo de adopción. Entiende las características únicas de tu producto y elige un modelo que se ajuste, no uno que empuje a los usuarios demasiado rápido a través de tu embudo de conversión.
Ejecutar un GTM con una estrategia de abajo hacia arriba a menudo implica SEO, marketing de productos y marketing de contenido. Todos sabemos que es importante comenzar temprano, así que comenzamos a crear contenido justo después de lanzar la versión de código abierto. Pero cuando decidimos escribir artículos por primera vez, tuve una gran pregunta: ¿Qué debo escribir?
Como diseñador de productos, mi instinto fue escribir sobre por qué diseñamos ciertas características, explicando el proceso de pensamiento y la filosofía detrás de ellas.
"En este artículo, repasaremos la historia de la Experiencia de Inicio de Sesión, incluyendo su concepción, decisiones de diseño y compromisos de producto. También obtendrás una mejor comprensión de cómo construir una experiencia de inicio de sesión o registro exitosa y sin fricciones." - Nuestra publicación de blog de hace 2 años Consideraciones de diseño para una experiencia de inicio de sesión fluida (Primer Capítulo)
Tenía muchas ganas de compartir mis pensamientos sobre nuestras características y diseño porque puse mucho esfuerzo en ellas. Pero al mirar atrás, me doy cuenta de que esto es lo que llamarías contenido "absorbido en sí mismo". Es común en empresas bien establecidas con una sólida cultura de EPD (Ingeniería, Producto, Diseño).
Si estás haciendo crecimiento liderado por el producto (PLG), especialmente cuando tu producto aún no ha alcanzado la etapa donde "la gente está hablando de ti", es necesario asegurarte de que tu contenido tenga un valor y un objetivo claros para tu audiencia. Evita ser demasiado enfocado en uno mismo.
Por ejemplo, en lugar de enfocarte en por qué se diseñó una característica, crea artículos educativos que expliquen términos específicos, o tutoriales que muestren cómo integrar una tecnología o herramienta interesante para resolver un problema técnico común.
A medida que aprendas más sobre tu producto y clientes, naturalmente desarrollarás fuertes opiniones sobre lo que realmente importa a tu audiencia. Mantener un enfoque "centrado en el cliente" te ayudará a mejorar la calidad del contenido. Con el tiempo, podrás escribir contenido que resuene con tu audiencia. De lo contrario, tu contenido corre el riesgo de parecer egocéntrico.
El marketing tradicional a menudo enfatiza las "mejores prácticas" o "soluciones" al vender a empresas o individuos, basado en la idea de que los productos SaaS impulsan principalmente la eficiencia y la productividad. Muchas estrategias se centran en números, mostrando ahorros financieros para resaltar beneficios. Mientras esto puede funcionar bien para compañías maduras con una amplia base de clientes, puede resultar poco atractivo para los desarrolladores.
Hace dos años, me centré mucho en construir proposiciones de valor y crear una narrativa de gran imagen para nuestro producto. Sin embargo, este enfoque no siempre conectaba con la audiencia de desarrolladores.
Mira la página web que teníamos hace 2 años—"Dando forma al futuro"… ¡Vaya!
Cuando se trata de satisfacer a los desarrolladores y resolver sus problemas, necesitas ser muy práctico y con los pies en la tierra. Los desarrolladores no se dejan influir por los beneficios elevados; les importa la disponibilidad y flexibilidad de las características, específicamente, cuán fácilmente tu producto puede integrarse en su pila tecnológica existente. Si no puede, no intentes venderlo.
Ahora, nuestra estrategia de contenido está mucho más enfocada. Resaltamos las características específicas que ofrecemos, permitiendo a los usuarios comprender rápidamente lo que ofrecemos desde la primera pantalla, sin recurrir a palabras de moda o mensajes de alto nivel.
Cuando lanzamos por primera vez nuestra versión comercial alojada, siempre hubo una discusión acalorada dentro del equipo: ¿Dañaría el código abierto nuestra versión alojada ya que es gratuito, y nuestro público objetivo son los desarrolladores? También debatimos si debíamos limitar algunas de nuestras características avanzadas en la versión de código abierto.
Hasta ahora, hemos mantenido las características principales de ambas versiones, tanto la de código abierto como la alojada, casi iguales. El crecimiento de nuestra comunidad de código abierto ha generado una confianza significativa con los líderes empresariales, y más empresas grandes se están uniendo. Curiosamente, algunas de estas empresas empezaron como desarrolladores en nuestra comunidad. Esto nos ha dado mucha confianza. Mientras continuemos construyendo grandes productos, proporcionando excelentes servicios y ayudando a los desarrolladores a resolver sus problemas, ya sea a través de un crecimiento autoservicio o ventas directas a empresas, el éxito llegará de manera natural.
Al final, se trata de resolver problemas de desarrolladores, ya sea a través de producto o servicio. Mantente paciente y enfocado, y todo caerá en su lugar de manera natural.
Gracias por leer, y si estás trabajando en algo similar, siéntase libre de compartir tus experiencias y pensamientos.