Lições e práticas aprendidas ao impulsionar o crescimento do Logto com desenvolvedores.
Logto é um produto open-source focado em desenvolvedores. Aqui está nossa linha do tempo de go-to-market:
Vindo de uma experiência em crescimento impulsionado por produtos para ferramentas de produtividade, a equipe e eu experimentamos diferentes estratégias de go-to-market para o Logto. Após dois anos, refleti sobre esses esforços e as etapas que tomamos. Quero compartilhar parte dessa jornada e explicar por que algumas coisas não funcionaram na época. Esses não são "erros", mas lições valiosas da nossa experiência. Espero que esses insights ajudem outras pessoas a trabalhar em projetos ou startups similares.
Quando você lança seu produto pela primeira vez, especialmente com uma mentalidade de crescimento de produto ou alguma experiência, é fácil pensar em todos os tipos de ideias empolgantes: fluxos de onboarding sofisticados, uma ótima demonstração no site, maneiras legais de destacar valor para os usuários e levá-los rapidamente ao momento “ah-ha”. Para fazer nosso produto parecer bem acabado e pronto para comercialização, implementei duas estratégias de ativação:
Essas estratégias foram muito bem-sucedidas na minha experiência passada. Então, quando o Logto lançou sua versão hospedada na nuvem, as apliquei imediatamente. No entanto, encontrei alguma confusão e desafios:
Para produtos de desenvolvedores, é difícil resolver um problema em pouco tempo, mesmo que possa ser totalmente autoatendido. Mesmo para um único desenvolvedor, o processo envolve várias etapas: integrar com a pilha tecnológica correta, criar uma prova de conceito, testar em um ambiente de desenvolvimento e depois ir para produção. Em qualquer ponto dessa jornada, os usuários podem desistir. A "tarefa a ser realizada" não é uma tarefa simples de uma etapa. As necessidades dos desenvolvedores são frequentemente complexas, exigindo uma gama de recursos ou cenários técnicos que precisam de design cuidadoso aproveitando nossas capacidades existentes. Resolver tais problemas leva tempo e não pode ser apressado.
Olhando para trás, é claro por que essa abordagem não teve sucesso. Quando lançamos pela primeira vez, nossos cadastros diários e tráfego orgânico eram bastante baixos. A maior parte do nosso tráfego vinha da comunidade open-source, que naturalmente não trazia grandes clientes. Não é surpresa que não vimos grandes clientes agendando chamadas durante essa fase. O baixo tráfego e a origem de nossos usuários tornaram irrealista esperar um número significativo de agendamentos de chamadas no início.
Escolha o modelo que se encaixa no seu produto, com base no tempo necessário para a ativação do usuário. Não deixe que normas do setor te restrinjam.
Ao construir um produto SaaS, uma das questões-chave de go-to-market (GTM) é escolher entre freemium ou um teste gratuito. A sabedoria comum sugere:
Inicialmente escolhemos um modelo freemium para um lançamento rápido, colocando uma barreira de pagamento entre os planos gratuitos e pagos. No entanto, os desenvolvedores não podiam acessar recursos avançados como SSO ou Organização no nível gratuito.
Embora haja muitos debates online sobre qual modelo é melhor, é crucial dar um passo atrás e considerar o cronograma de ativação do seu produto. Para o Logto, observamos que, no mundo real, a fase de teste pode durar até 6 meses. Isso não se deve à complexidade do Logto, mas sim à programação de trabalho do engenheiro, planejamento de projetos, fluxos de trabalho da equipe e outros fatores que não previmos.
Dado esse longo período de ativação, é importante fornecer aos desenvolvedores acesso total a todos os recursos para teste. É por isso que utilizamos totalmente o tenant de desenvolvimento para desbloquear as capacidades completas do produto. Esta é uma prática comum para ferramentas de desenvolvedores, mas vale a pena notar, pois explica por que estratégias tradicionais de freemium ou teste gratuito podem não funcionar para nós.
A escolha deve se alinhar com a natureza do seu produto e seu cronograma de adoção. Compreenda as características únicas do seu produto e escolha um modelo que se encaixe — não um que empurre os usuários muito rapidamente pelo seu funil de conversão.
Executar um GTM com uma estratégia bottom-up muitas vezes envolve SEO, marketing de produto e marketing de conteúdo. Todos sabemos que é importante começar cedo, então começamos a criar conteúdo logo após lançar a versão open-source. Mas quando decidimos escrever artigos pela primeira vez, eu tive uma grande pergunta: Sobre o que devo escrever?
Como designer de produto, minha intuição era escrever sobre por que projetamos determinados recursos, explicando o processo de pensamento e a filosofia por trás deles.
"Neste artigo, vamos abordar a história da Experiência de Login, incluindo sua concepção, decisões de design e compromissos de produto. Você também ganhará uma melhor compreensão de como construir uma experiência de login ou cadastro bem-sucedida e sem atrito." - Nosso post no blog de 2 anos atrás As considerações de design para uma experiência de login sem atrito (Primeiro Capítulo)
Eu estava ansioso para compartilhar meus pensamentos sobre nossos recursos e design porque investi muito esforço neles. Mas olhando para trás, percebo que isso é o que você chamaria de conteúdo "egocêntrico". Isso é comum em empresas bem estabelecidas com uma cultura forte de EPD (Engenharia, Produto, Design).
Se você está fazendo crescimento liderado por produto (PLG), especialmente quando seu produto ainda não atingiu o estágio em que "as pessoas estão falando sobre você," é necessário garantir que seu conteúdo tenha valor claro e um objetivo para seu público. Evite ser muito focado em si mesmo.
Por exemplo, em vez de focar em por que um recurso foi projetado, crie artigos educacionais que expliquem termos específicos ou tutoriais que mostrem como integrar uma tecnologia ou ferramenta bacana para resolver um problema técnico comum.
À medida que você aprende mais sobre seu produto e clientes, naturalmente desenvolverá opiniões fortes sobre o que realmente importa para seu público. Manter uma abordagem "centrada no cliente" ajudará a melhorar a qualidade do conteúdo. Com o tempo, você será capaz de escrever conteúdo que ressoe com seu público. Caso contrário, seu conteúdo corre o risco de parecer egocêntrico.
O marketing tradicional muitas vezes enfatiza “melhores práticas” ou “soluções” ao vender para empresas ou indivíduos, com base na ideia de que produtos SaaS impulsionam principalmente eficiência e produtividade. Muitas estratégias focam em números, mostrando economias financeiras para destacar benefícios. Enquanto isso pode funcionar bem para empresas maduras com uma ampla base de clientes, pode ser desanimador para desenvolvedores.
Dois anos atrás, foquei fortemente em construir proposições de valor e criar uma narrativa de grande escala para nosso produto. No entanto, essa abordagem nem sempre conectou com o público de desenvolvedores.
Olhe para a página inicial que tínhamos 2 anos atrás—“Moldando o futuro”… Uau!
Quando se trata de satisfazer desenvolvedores e resolver seus problemas, você precisa ser muito prático e fundamentado. Desenvolvedores não se deixam levar por benefícios elevados; eles se preocupam com a disponibilidade e flexibilidade de recursos — especificamente, quão facilmente seu produto pode se integrar à sua pilha tecnológica existente. Se não puder, não tente vendê-lo.
Agora, nossa estratégia de conteúdo é muito mais focada. Destacamos os recursos específicos que fornecemos, permitindo que os usuários entendam rapidamente o que oferecemos desde a primeira tela, sem depender de palavras da moda ou mensagens de alto nível.
Quando lançamos nossa versão comercial hospedada pela primeira vez, sempre houve uma discussão acalorada dentro da equipe: o open-source prejudicaria nossa versão hospedada, já que é gratuito, e nosso público-alvo são desenvolvedores? Também debatemos se deveríamos limitar alguns de nossos recursos avançados na versão open-source.
Até agora, mantivemos os recursos principais de ambas as versões open-source e hospedada quase os mesmos. O crescimento da nossa comunidade open-source tem construído confiança significativa com leads empresariais, e mais grandes empresas estão se juntando. Curiosamente, algumas dessas empresas começaram como desenvolvedores em nossa comunidade. Isso nos deu muita confiança. Contanto que continuemos a construir ótimos produtos, fornecer excelentes serviços e ajudar os desenvolvedores a resolver seus problemas, seja por meio de crescimento autoatendido ou vendas diretas para empresas, o sucesso virá naturalmente.
No final, trata-se de resolver problemas de desenvolvedores, seja por produto ou serviço. Mantenha-se paciente e focado, e tudo se encaixará naturalmente.
Obrigado por ler, e sinta-se à vontade para compartilhar suas experiências e pensamentos se você está trabalhando em algo semelhante!