Lições e práticas aprendidas ao impulsionar o crescimento do Logto com desenvolvedores.
Logto é um produto de código aberto focado em desenvolvedores. Eis a nossa cronologia de entrada no mercado:
Vindo de um histórico de crescimento liderado por produtos para ferramentas de produtividade, as equipas e eu experimentámos diferentes estratégias de entrada no mercado para o Logto. Após dois anos, refleti sobre esses esforços e sobre os passos que demos. Quero partilhar parte dessa jornada e explicar porque é que algumas coisas não funcionaram na altura. Estes não são "erros", mas lições valiosas da nossa experiência. Espero que estas ideias ajudem outras pessoas a trabalhar em projetos ou startups semelhantes.
Quando se lança um produto pela primeira vez, especialmente com uma mentalidade de crescimento de produto ou alguma experiência, é fácil pensar em todo o tipo de ideias empolgantes: fluxos de incorporação chamativos, uma excelente demonstração no site, maneiras interessantes de destacar valor para os utilizadores e levá-los rapidamente ao momento "ah-ha". Para fazer o nosso produto parecer polido e pronto para comercialização, implementei duas estratégias de ativação:
Estas estratégias foram muito bem-sucedidas na minha experiência anterior. Assim, quando o Logto lançou a sua versão hospedada na nuvem, apliquei-as imediatamente. No entanto, enfrentei algumas confusões e desafios:
Para produtos para desenvolvedores, é difícil resolver um problema em pouco tempo, mesmo que possa ser verdadeiramente autoatendimento. Mesmo para um único desenvolvedor, o processo envolve várias etapas: integrar com a pilha de tecnologia certa, criar uma prova de conceito, testar num ambiente de desenvolvimento e depois passar para a produção. Em qualquer ponto desta jornada, os utilizadores podem desistir. O "trabalho a ser feito" não é uma tarefa simples de um só passo. As necessidades dos desenvolvedores são frequentemente complexas, exigindo uma variedade de funcionalidades ou cenários técnicos que precisam de um design cuidadoso aproveitando as nossas capacidades existentes. Resolver tais problemas leva tempo e não pode ser apressado.
Olhando para trás, é claro porque esta abordagem não teve sucesso. Quando lançámos pela primeira vez, as nossas inscrições diárias e o tráfego orgânico eram bastante baixos. A maior parte do nosso tráfego vinha da comunidade de código aberto, que naturalmente não trazia grandes clientes. Não é surpresa que não víamos grandes clientes a marcar chamadas nesta fase. O baixo tráfego e a origem dos nossos utilizadores tornaram irrealista esperar reservas significativas de chamadas no início.
Escolha o modelo que se adapta ao seu produto, com base no tempo necessário para a ativação do utilizador. Não deixe que as normas do setor o limitem.
Ao construir um produto SaaS, uma das principais questões de entrada no mercado (GTM) é se deve escolher freemium ou teste gratuito. A sabedoria comum sugere:
Inicialmente, escolhemos um modelo freemium para um lançamento rápido, colocando uma barreira de pagamento firme entre os planos gratuitos e pagos. No entanto, os desenvolvedores não podiam aceder a funcionalidades avançadas como SSO ou Organização no nível gratuito.
Embora haja muito debate online sobre qual modelo é melhor, é crucial dar um passo atrás e considerar o cronograma de ativação do seu produto. Para o Logto, observámos que, no mundo real, a fase de teste pode durar até 6 meses. Isto não se deve à complexidade do Logto, mas sim à agenda de trabalho dos engenheiros, planeamento de projetos, fluxos de trabalho da equipa e outros fatores que não tínhamos antecipado.
Dado este longo período de ativação, é importante fornecer aos desenvolvedores acesso total a todas as funcionalidades para testes. É por isso que utilizamos completamente o tenant de desenvolvimento para desbloquear todas as capacidades do produto. Isto é prática comum para ferramentas de desenvolvedores, mas vale a pena destacar, pois explica por que as estratégias freemium tradicionais ou de teste gratuito podem não funcionar para nós.
A escolha deve alinhar-se com a natureza do seu produto e o 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 utilizadores rapidamente através do seu funil de conversão.
Executar um GTM com uma estratégia de baixo para cima envolve frequentemente SEO, marketing de produto e marketing de conteúdo. Todos sabemos que é importante começar cedo, por isso começámos a criar conteúdo logo após o lançamento da versão de código aberto. Mas quando primeiro decidimos escrever artigos, tive uma grande pergunta: O que devo escrever?
Como designer de produto, o meu instinto era escrever sobre porque projetámos certas funcionalidades, explicando o processo de pensamento e a filosofia por trás delas.
"Neste artigo, vamos analisar a história da Experiência de Login, incluindo a sua conceção, decisões de design e compromissos de produto. Você também obterá uma melhor compreensão de como construir uma experiência de login ou inscrição bem-sucedida e sem atritos." - Nossa publicação no blog há 2 anos As considerações de design para uma experiência de login sem atritos (Primeiro Capítulo)
Eu estava ansioso para partilhar os meus pensamentos sobre as nossas funcionalidades e design porque coloquei muito esforço neles. Mas olhando para trás, percebo que isto é o que se chamaria de conteúdo "egocêntrico". É comum em empresas bem estabelecidas com uma forte cultura EPD (Engenharia, Produto, Design).
Se está a fazer crescimento liderado por produtos (PLG), especialmente quando o seu produto ainda não chegou ao estágio em que "as pessoas estão a falar de você", é necessário garantir que o seu conteúdo tenha valor claro e um objetivo para o seu público. Evite ser demasiado focado em si mesmo.
Por exemplo, em vez de se concentrar em porque uma funcionalidade foi projetada, crie artigos educacionais que expliquem termos específicos, ou tutoriais que mostrem como integrar uma tecnologia ou ferramenta interessante para resolver um problema técnico comum.
À medida que aprende mais sobre o seu produto e clientes, naturalmente desenvolverá opiniões fortes sobre o que realmente importa para o seu público. Manter uma abordagem “focada no cliente” ajudará a melhorar a qualidade do conteúdo. Com o tempo, será capaz de escrever conteúdo que ressoe com o seu público. Caso contrário, o 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 principalmente impulsionam eficiência e produtividade. Muitas estratégias focam-se em números, mostrando economias financeiras para destacar benefícios. Embora isso possa funcionar bem para empresas maduras com uma ampla base de clientes, pode ser desmotivador para os desenvolvedores.
Há dois anos, concentrei-me fortemente na construção de propostas de valor e na elaboração de uma narrativa de grande alcance para o nosso produto. No entanto, essa abordagem nem sempre se conectou com o público de desenvolvedores.
Olhe para a página web que tínhamos há 2 anos—"Moldando o futuro"… Uau!
Quando se trata de satisfazer desenvolvedores e resolver os seus problemas, é preciso ser muito prático e fundamentado. Os desenvolvedores não são convencidos por benefícios elevados; eles preocupam-se com a disponibilidade e flexibilidade das funcionalidades - especificamente, quão facilmente o seu produto pode ser integrado na sua pilha de tecnologia existente. Se não puder, não tente vendê-lo.
Agora, a nossa estratégia de conteúdo está muito mais focada. Destacamos as funcionalidades específicas que oferecemos, permitindo que os utilizadores compreendam rapidamente o que oferecemos desde a primeira tela, sem depender de palavras de ordem ou mensagens de alto nível.
Quando lançámos pela primeira vez a nossa versão comercial hospedada, sempre houve uma discussão acalorada dentro da equipa: Será que o código aberto prejudicaria a nossa versão hospedada, uma vez que é gratuita, e o nosso público-alvo são desenvolvedores? Também debatemos se devíamos limitar algumas das nossas funcionalidades avançadas na versão de código aberto.
Até agora, mantivemos as funcionalidades principais em ambas as versões de código aberto e hospedadas quase iguais. O crescimento da nossa comunidade de código aberto construiu uma confiança significativa com clientes empresariais, e mais empresas maiores estão a aderir. Curiosamente, algumas destas empresas começaram como desenvolvedores na nossa comunidade. Isso deu-nos muita confiança. Enquanto continuarmos a construir ótimos produtos, fornecer excelentes serviços e ajudar os desenvolvedores a resolver os seus problemas, seja através de crescimento auto-serviço ou vendas diretas a empresas, o sucesso virá naturalmente.
No final, trata-se de resolver problemas de desenvolvedores, seja através de produto ou serviço. Mantenha-se paciente e focado, e tudo se encaixará naturalmente.
Obrigado por ler, e sinta-se à vontade para partilhar as suas experiências e pensamentos se estiver a trabalhar em algo semelhante!