O que é Growth Engineering e como é o impacto na área de Engenharia das empresas

Photo by Carlos Muza on Unsplash

Antes de qualquer coisa, é necessário explicar o que é Growth Engineering e qual é a diferença para as demais áreas da Engenharia de Software (como plataforma ou áreas focadas na infraestrutura). Além disso, vou tomar a liberdade de referenciar pessoas que trabalham nesta área como Growth Engineers, dito isto, vamos ao que interessa!

O que é Growth Engineering

Como é o dia a dia em Growth Engineering

Qual é o Processo de Growth

Diferença entre Product Engineer x Growth Engineer

Como começar sua estratégia de Growth Engineering

A carreira de Growth Engineering

O que é Growth Engineering

Growth Engineers são aqueles profissionais que irão trabalhar em cima dos produtos (ou dos outros serviços da empresa) com o objetivo de melhorar as taxas de aquisição, retenção e monetização de cliente. E hoje, não é comum ter empresas que coloque pessoas engenheiras para iterar em cima desses pontos. Para que isso seja possível, os times de Growth Engineering seguem uma forma de pensar diferente dos times que estão focados na entrega do produto (Product Engineering):

Ao invés de se questionar algo como “quais são as funcionalidades ou produtos que precisamos construir para atender as necessidades dos clientes?”, os times de Growth Engineering fazem perguntas como “porque os usuários não estão conseguindo avançar de etapa?” ou “quais são as funcionalidades do produto que os usuários estão tendo dificuldade em usar/descobrir, e o que podemos fazer a respeito?’’.

Logo, temos o seguinte cenário:

Product Engineering trabalha para criar ou manter as funcionalidades principais do produto, cuidando para que ele acompanhe o crescimento da empresa e aumento de usuários usando as funcionalidades. Já a área de Growth Engineering trabalha para ter aprendizados incrementais, com o objetivo de melhorar as métricas do negócio (aquisição de clientes, retenção de clientes ou monetização de clientes), através do olhar profundo na experiência e métricas do produto.

Como é o dia a dia em Growth Engineering

Esse tópico em si tende a ser algo que muda de empresa para empresa, por diversos motivos: rituais, metodologia de trabalho, quantidade de pessoas, estrutura organizacional e até mesmo devido às ferramentas que são utilizadas. Dessa forma, vou tomar a liberdade de me prender mais ao que utilizamos aqui na RD Station, mas também utilizarei informações de outras empresas que tive o prazer de conhecer. Fique à vontade para comentar como funciona a sua empresa no final do artigo.

Ao mesmo tempo que Growth Engineering está dentro de Engenharia, essa área também tem “um pé” dentro da área de Growth, logo, é muito natural as pessoas Growth Engineers estarem inseridas (ou realizarem) rituais que são mais comuns em times puramente de Growth. Aqui na RD temos uma metodologia de trabalho que tomarei a liberdade de chamar “Processo de Growth” — o primeiro contato que eu tive com essa terminologia foi no artigo do Andrew Hammond, e como resume muito bem a forma que trabalhamos e nos organizamos, trouxemos para aqui também.

Qual é o processo de Growth

Como dito acima, o “Processo de Growth” é a forma que nos organizamos aqui para realizar o nosso trabalho. Ele envolve não só a Engenharia, mas também outros profissionais como Product Managers, Designers e Líderes que cuidam da estratégia da operação.

Photo by Andrew Hammon on Atlassian

Seguir esse processo nos ajuda em diversas formas, tais como:

• Analisar quais pontos da jornada do cliente temos as melhores oportunidades de melhora;
• Listar quais hipóteses terão os maiores impactos na métricas que estamos perseguindo;
• Criar experimentos que acreditamos que irão atingir os objetivos das hipóteses;
• Avaliar quais os experimentos que geraram os impactos nas métricas;
• Interpretar e iterar em cima dos resultados dos experimentos.

As pessoas Growth Engineers atuam em todas as etapas da jornada, indo muito além da criação de código, porém não são os principais responsáveis por todas as etapas (cuidam principalmente da parte de desenvolvimento dos experimentos).

Através do aprofundamento nas métricas do produto e do negócio (análises quantitativas) e nas ferramentas e entrevistas com clientes que mostram o comportamento de uso da solução (análises qualitativas) conseguimos gerar empatia com os clientes e ter aprendizado valiosos. Com essas informações, conseguimos priorizar o que iremos entregar primeiro, visando sempre primeiro colocar em produção aquilo que gera maior impacto nas métricas de negócio (e na experiência do cliente).

Com esses pontos acima, conseguimos cobrir as etapas de “Definir métricas da oportunidade” (Define Metric Opportunities) e “Pesquisar Oportunidades” (Research Opportunities). Mas duas etapas que nos orgulhamos muito aqui na RD Station — porque sem falsa modéstia, fazemos muito bem isso graças as pessoas Product Managers e Designers, são as etapas de “Ideação do experimento” (Experimentation Ideation) e “Preparação” (Preparation).Nesse momento do processo, fazemos a modelagem do experimento. Aqui é validado se realmente o que queremos testar irá “parar em pé” ou em outras palavras, se faz sentido colocar energia e esforço naquilo. Seguimos as seguintes etapas:

• Criamos um resumo breve sobre o experimento que evidencia a existência do problema ou da oportunidade;
• Fazemos um benchmarking para entender como o mercado resolve o mesmo problema ou explora aquela oportunidade;
• Formalizamos a hipótese de como será atacado o problema/oportunidade -> neste momento é evidenciado quais as métricas procuramos impactar, inclusive as desvantagens e problemas;
• Fazemos uma proposta de solução (MVP) — envolvendo aqui os designers para elaboração de protótipo — e definimos a segmentação de clientes que irão visualizar esse experimento.

Com tudo isso em mãos, avançamos para a etapa de “Desenvolvimento da solução” (Development). Aqui priorizamos as seguintes ações:

• Quebramos o experimento em pequenas atividades;
• Desenvolvemos a solução do problema (ou da oportunidade) — seja código que irá lidar com frontend ou backend;
• Evidenciamos quais são os segmentos de clientes que irão ver o experimento;
• Instrumentamos dentro do experimento diversos “eventos” que nos mostram o comportamento do usuário.

E concluído o processo de “Desenvolvimento da solução” (Development), são tiradas as conclusões a respeito do experimento. Com essas informações nas mãos, re-priorizamos o backlog, criamos novos experimentos e definimos se o experimento “deu certo ou deu errado”. Caso tenha dado certo (ou atingido as hipóteses), mantemos o experimento em produção e seguimos com o cleanup (ou limpeza), fazendo os ajustes necessários de código.

Diferença entre Product Engineer x Growth Engineer

Diferentemente das atividades de Product Engineering, que tem o objetivo de desenvolver funcionalidades incrementais no produto, tudo (ou quase tudo) que uma pessoa Growth Engineer desenvolver terá o objetivo de validar uma hipótese, que alcançará relevância estatística em algumas horas ou dias, por isso o código não necessariamente vai ficar para sempre em produção. Dessa forma, como tudo que iremos fazer passará por esses período de teste, então, não podemos gastar muitos recursos neste momento pois a tendência é que 75% dos experimentos não irão atingir o objetivo esperado

Como começar sua estratégia de Growth Engineering

• Faça poucos ou nenhum testes automatizados: priorize apenas caso o experimento atinja o seu objetivo;
• Escreva código de fácil deleção: como há grandes chances do experimento não atingir o seu objetivo, deverá ser deletado por completo de produção;
• Limite a exposição do código do experimento: quanto mais entranhado em partes críticas do sistema, mais chances dele gerar incidentes críticos;
• Revise código compartilhado: os times de Growth Engineering, em alguns modelos de estrutura, tendem a não ter domínios próprios (ou seja, alteram o código de outros times). Por isso, vale ter revisão de pessoas com mais expertise, assim a pessoa engenheira deve entender que pode aumentar cycle time dessa atividade;
• Evite reabertura de experimento: esse é o incidente mais grave para o time de Growth Engineers — se um experimento está em produção, mas não está apresentando o comportamento desenhado na modelagem, o time deve corrigir imediatamente;
• Suba para produção antes de estar pronto: colocar em produção os experimentos de uma forma que só os times de Engenharia e Produto vejam, antecipa a identificação de qualquer “anomalia”;
• Se possível, resolva apenas com soluções no-code/low-code: quanto mais barato validarmos um experimento, melhor, então code apenas o que for realmente necessário pois, como dissemos acima, tudo ainda é incerto até ser validado;
• Mantenha seu código sempre limpo (Cleanup): voltar para o código do experimento que foi feito deve sempre ser uma tarefa priorizada, pois caso ele dê certo, será preciso que aquele código fique nos padrões de qualidade da Engenharia (testado, otimizado e afins), caso contrário, a longo prazo ficará impossível de fazer manutenção. E caso o experimento não dê certo, simplesmente deve ser excluído todo aquele código.
• Não crie experimentos interdependentes: ter duas (ou mais) pessoas trabalhando no mesmo experimento, faz com que ele vá para produção antes, e quanto antes os usuários testarem, mais rápido teremos as respostas em relação a hipóteses, e mais rápido teremos outros experimentos no ar.

E concluído o processo de “Desenvolvimento da solução” (Development), são tiradas as conclusões a respeito do experimento. Com essas informações nas mãos, re-priorizamos o backlog, criamos novos experimentos e definimos se o experimento “deu certo ou deu errado”. Caso tenha dado certo (ou atingido as hipóteses), mantemos a produção e seguimos com o cleanup (ou limpeza), fazendo os ajustes necessários de código.

A carreira de Growth Engineering

Com tudo isso que escrevi acima é fácil ver que eu só tenho elogios sobre essa carreira. Ela é peça fundamental para qualquer empresa que tenha time de engenharia. Pois aplica metodologias que visam acelerar o aprendizado e o impacto no usuário final, além de ter como indicadores principais as próprias métricas do negócio (aquisição, retenção e monetização de clientes). O que faz, a própria unidade de engenharia, ser alavanca importante no impacto da estratégia da empresa.

O jogo do crescimento de empresas mudou muito nos últimos anos, pois:

• A distribuição está mais competitiva e cara: consolidação de plataformas e mais pessoas competindo dentro delas;
• O ciclo de vida dos canais de aquisição e as táticas aceleram: tudo tem um tempo de vida curto, o que significa que precisamos adaptar mais rapidamente.

É necessária cada vez mais pessoas pensando em como mitigar/resolver essas problemáticas, e não tem nada melhor do que ter pessoas que criam diretamente o que impacta os clientes, pensando ou criando essas soluções. Por isso, enxergo a carreira de Growth Engineer em grande ascendência.

Será bem comum ter Growth Engineers trabalhando em parceria com os times de Product Engineering, realizando dezenas, centenas ou milhares de Testes A/Bs (experimentos) tendo muitas interações com diversos times da empresa, mexendo em codebase que não são donos, e sendo parceiros diretos de Product Managers, Designers, Engenheiros e até mesmo Diretores/Founders das empresas.

Caso você queira aprofundar mais sobre Growth Engineering, dá um ping aqui neste outro artigo aqui em que listamos as principais boas práticas nessa área. E se você quer trabalhar numa empresa onde essa área tem crescido cada vez mais, estamos com vagas abertas!