50 lições aprendidas ao criar produtos de sucesso [artigo traduzido]

1. Equipes pequenas (com 6 pessoas ou menos) podem criar produtos excelentes, mas precisam receber autonomia total sobre definição de metas, priorização do roadmap, escolha de métricas, comunicação com usuários e deploy rápido de código.

2. O sucesso de um produto depende das pessoas que o constroem. O ponto-chave é manter um padrão alto de contratação, porque a capacidade dos talentos se acumula. Uma contratação ruim desacelera a equipe mais do que qualquer outro fator.

3. Confiança é essencial para criar ótimos produtos. A falta de confiança é um dos maiores gargalos de uma equipe, e geralmente é resultado de contratar alguém abaixo do nível esperado ou de não dar feedbacks de melhoria de forma adequada.

4. A confiança também se constrói com transparência. Trabalhe de forma aberta, faça discussões em espaços públicos e documente o que está sendo feito. Assim, todos compartilham o contexto necessário e é possível eliminar as disputas políticas que surgem em muitas empresas.

5. Apoie-se em confiança e feedback, não em processo. Esse é um dos nossos valores centrais. Criar e expandir algo que as pessoas realmente querem é um problema cheio de nuances, então confiamos no julgamento dos funcionários. Quando algo dá errado, damos feedback direto.

6. A liderança compartilha os objetivos da empresa, e a equipe de produto (engenheiros) decide o que construir para alcançá-los e define suas próprias metas. Os dois lados devem revisar o impacto real com métricas e feedback dos usuários.

7. O produto é subordinado ao perfil de cliente ideal (ideal customer profile, ICP). É para esse ICP que se constrói, e ele é o fator mais importante na decisão do que fazer. Um ICP preciso define não só o cliente-alvo, mas todos os aspectos do produto e da estratégia de entrada no mercado.

8. Para encontrar o ICP, comece com hipóteses e testes. Faça perguntas no cadastro, compare retenção, identifique power users e aplique pesquisas de NPS. Conforme informação e confiança aumentarem, vá adicionando mais detalhes.

9. Crie princípios de produto. Nós usamos princípios como “fornecer todas as ferramentas necessárias para medir sucesso, ser pioneiro e atuar como fonte de verdade para dados de clientes e de produto”. Isso cria uma linguagem comum para discutir ideias e tomar decisões.

10. Mapeie tudo o que os usuários podem querer. Isso é necessário ao priorizar o roadmap. Assim, você não deixa passar boas ideias que ainda estão além do horizonte.

11. Produto é mais do que um conjunto de funcionalidades. É a marca e a experiência que ele entrega às pessoas. O tamanho do investimento em cada recurso, as pessoas contratadas, as decisões de construção, as funcionalidades principais, a comunicação com clientes e a política de preços — tudo isso cria originalidade.

12. O site é a primeira impressão do produto. Um site sem graça e com cara de template sinaliza que o produto e a equipe por trás dele são fracos. Criar um site único, ajustado ao perfil de cliente ideal, evita isso e ajuda a impulsionar a aquisição de usuários.

13. Às vezes, o problema não é do produto, mas do mercado. Por exemplo, quando Tom Blomfield, fundador da Monzo e partner da YC, criou um serviço para dividir contas entre amigos da universidade, recebeu o conselho de parar de construir e focar em conquistar usuários. Depois de 4 semanas fazendo cold calling e conseguir apenas um usuário, ficou claro que era hora de pivotar.

14. Se for pivotar, faça isso de forma radical. Stewart Butterfield transformou duas empresas de games em Flickr e Slack. O cofundador do LinkedIn, Reid Hoffman, diz que fundadores de startups, para pivotar do fracasso para o sucesso, precisam fazer slash and burn com o restante do negócio. Se ainda parecer parecido, vá mais longe.

15. Como diz Jason Fried, da 37signals: “Você não pode validar uma ideia. Como ela não existe, você precisa de fato criá-la. O mercado vai validá-la.”

16. Planejamento é útil, mas não deve ser seguido rigidamente. Boa execução não é cumprir um plano específico, e sim repetir continuamente o trabalho mais importante. Avalie as pessoas não por “aderência ao plano”, mas pelo que entregam, pela frequência de deploy e pelo impacto.

17. Adiar algo por “só mais uma semana” quase sempre é uma má ideia. Quando essa atitude se acumula por meses, o resultado é uma grande perda de momentum. Quanto mais cedo algo chega às mãos dos usuários, mais rápido você aprende seu valor e o melhora.

18. Reduza o trabalho em andamento. Um PR deve ser concluído em um dia, o dia deve começar respondendo a pedidos de review de outras pessoas, e deve ser possível fazer merge a qualquer momento, lançar atrás de feature flags e testar em produção. Tudo isso reduz a carga de contexto do trabalho.

19. Deploy rápido é central na nossa filosofia de desenvolvimento de produto, mas envolve trade-offs. Compras de tecnologia, reuniões de planejamento, cerimônias ágeis e revisões de métricas ficam em segundo plano. O trabalho assíncrono torna isso ainda mais viável.

20. Adote novas tecnologias no produto apenas diante de problemas urgentes, como custos excessivos, problemas de escalabilidade ou demandas de clientes. A tecnologia para resolver isso geralmente pode ser encontrada perguntando à própria equipe ou a outras equipes como já resolveram questões parecidas.

21. Deadlines artificiais não tornam a equipe mais rápida. Pelo contrário, criam um ciclo destrutivo de dívida técnica acumulada e burnout. Remova os processos que tornam o time lento e dê a equipes pequenas autonomia para fazer deploy rápido.

22. Outra forma de acelerar deploy é eliminar o design padrão como etapa obrigatória. Depois de colocar um design system para funcionar, deixe os engenheiros construírem. Quando necessário, refine o que já foi lançado com design reviews.

23. Feature flags permitem que engenheiros de produto publiquem mudanças rapidamente, testem em produção e recebam feedback real de usuários. Também reduzem o risco ao funcionar como kill switch quando algo não sai como esperado.

24. Na PostHog, a melhor comunicação é um pull request. Diferente de mensagens ou issues, ele transforma feedback imediatamente em impacto. Isso combina com uma cultura orientada à ação e cria um loop de feedback mais curto.

25. Deixe a responsabilidade clara. Isso torna muito mais nítido e rápido decidir o que construir. Equipes que evitam responsabilidade desperdiçam tempo com planejamento, brainstorming, reuniões e gerenciamento de projetos em vez de fazer deploy.

26. Engenheiros têm capacidade para decidir o que construir. Eles entendem restrições técnicas, reconhecem padrões em funcionalidades e sabem como resolver problemas. O que pode existir é um gargalo de informação sobre as necessidades dos usuários.

27. Em vez de controlar os engenheiros, o product manager deve fornecer contexto para a equipe de produto por meio de análises de produto, pesquisa com usuários e pesquisa de concorrentes.

28. A maioria das pessoas não é Steve Jobs. Não têm, desde o início, uma visão pronta para simplesmente “sair construindo”, nem desenham um grande quadro completo. Em vez disso, lançam, colocam nas mãos dos usuários e iteram com base em feedback. Quanto maior essa velocidade, melhor o produto fica.

29. Contrate e confie em product engineers. Eles combinam as habilidades full-stack necessárias para construir produtos com obsessão pelo cliente. Devem conversar com usuários, fazer entrevistas, recrutar pessoas para testar novas funcionalidades, coletar feedback, lidar com suporte e responder a incidentes.

30. Leia The Mom Test. Ele ensina a conversar sobre os problemas de usuários em potencial. O ponto central são dois tipos de entrevistas com usuários: descoberta do problema e validação da solução. A primeira orienta decisões futuras de produto; a segunda ajuda a melhorar o que está sendo construído agora.

31. Para tirar o máximo das entrevistas com usuários, entenda antes quem são os usuários (ICP), como usam o produto e o que você pretende construir em seguida. Assim, as entrevistas ajudam a esclarecer o foco dos próximos passos, em vez de gerar confusão.

32. Entre as possíveis coisas a construir, as solicitações de suporte são as mais “reais”. Há um usuário específico enfrentando um problema concreto, então resolvê-lo melhora o produto imediatamente. Outras mudanças não são tão intuitivas assim.

33. Quando engenheiros cuidam de suporte, isso incentiva a responsabilidade por todo o ciclo de vida do produto, da ideação à implementação e à manutenção contínua. Cada etapa passa a se conectar, acumulando dores reais dos clientes e contexto do código por trás dos problemas.

34. Quando engenheiros atendem suporte, o loop entre problema do usuário e correção publicada fica mais curto. Equipe de suporte, product managers e processos de planejamento deixam de atrapalhar. Como bônus, os usuários adoram isso.

35. Usar o próprio produto (dogfooding) ajuda a acelerar deploy, barrar problemas antes que cheguem aos usuários, entender o produto em profundidade e criar empatia com o usuário. Mas isso não substitui conversas com usuários, feedback real nem acompanhamento de métricas de uso.

36. Resolver as próprias necessidades com o próprio produto, como quando nossa equipe criou um popup de entrevista para si mesma, é uma boa forma de validar casos de uso. Se você deveria usar seu próprio produto e não usa, isso é sinal de que algo está errado — então conserte.

37. Grandes criadores de produto estão sempre prototipando e experimentando. Precisam se sentir à vontade para construir MVPs e provas de conceito, lançar trabalho inacabado, absorver feedback e pivotar quando falham. Também precisam de habilidades para construir do zero, da infraestrutura ao design.

38. Um A/B test bem-sucedido exige uma boa hipótese que explique o que está sendo testado e por quê. Inclua o contexto do teste, o que mudou, as métricas e o resultado esperado.

39. Ao fazer experimentos de produto, saiba que eles podem falhar e ser removidos. Configure tudo com feature flags para facilitar a remoção e publique uma versão “boa o suficiente”, em vez de uma versão perfeita, totalmente escalável e de fácil manutenção. Se der certo, você melhora depois.

40. Experimentos de produto podem ser bem mais “burros” do que você imagina. Em vez de construir a funcionalidade inteira, tente um teste de fake door: adicionar uma opção ou botão que não leva a nada e ver se as pessoas clicam.

41. O fracasso em experimentos de produto não é o fim do mundo. No Google, 80% a 90% dos experimentos “falham”. Pode parecer desperdício de tempo, mas em grande escala, 10% de sucesso compensam todos os fracassos — como no A/B test de manchetes do Bing, que aumentou a receita em 12% (mais de US$ 100 milhões).

42. Ao focar em crescimento, pense e priorize como um growth engineer. Identifique a área-alvo, escolha uma métrica representativa, formule uma hipótese de melhoria e implemente o menor experimento possível para testá-la.

43. Quase nunca é cedo demais para introduzir analytics. Isso vale inclusive para produtos antes do lançamento, mas lançar “porque ainda é cedo” sem analytics é uma falsa economia. Depois do lançamento, a prioridade muda de fazer deploy o mais rápido possível para fazer deploy, o mais rápido possível, da coisa certa.

44. Ao começar com analytics, comece pequeno. Escolha um produto ou funcionalidade específica, acompanhe o uso com autocapture, visualize em gráficos de tendências e retenção e tente lançar recursos que melhorem isso. O “complexo industrial da modern data stack” faz tudo parecer mais complicado do que realmente é.

45. Se você não souber com qual métrica começar, recomendo activation. Ela fica acima de outras métricas na cadeia, pode ser impactada diretamente pelos engenheiros e é útil para toda a organização.

46. Além de activation, retention é outra métrica-chave para entender o impacto do que está sendo construído. Acompanhar mudanças semanais ajuda a avaliar se as alterações estão contribuindo para manter usuários.

47. Ao medir product-market fit, verifique se o engajamento dos usuários cresce exponencialmente mais do que o crescimento de usuários e se a curva de retenção se estabiliza (acima de 0%). Depois, veja se a retenção entre usuários ICP é forte e se os clientes pagantes pertencem ao ICP.

48. Revisões de crescimento servem para verificar se o que a equipe construiu está impactando métricas importantes, como receita, analytics de produto e feedback dos usuários. Na PostHog, essa é uma responsabilidade importante do product manager.

49. Ao construir vários produtos, trate cada um como uma mini startup. Cada um deve ter suas próprias decisões de produto, preço, receita, custos e alinhamento com equipes que lidam com clientes.

50. Dedique-se a produtos que você ache interessantes. Como escreveu James, cofundador da PostHog, no guia sobre product-market fit: “Se não for interessante, pivote. É só isso. Você consegue resultados maiores quando se dedica a algo que parece seu.”