Três coisas que descobrimos sobre experimentação dentro de um produto

Publicado por Luigi Cenatti Gianni no dia gestão

AB Testing

Nós criamos em janeiro deste ano o primeiro time de Produto focado exclusivamente no onboarding do RD Station (se você está curioso sobre o porquê, a resposta tem a ver com retenção). Junto com essa mudança, começamos a testar a aplicabilidade de um processo de experimentação (muito similar a growth hacking) para melhorar o RD Station.

Entendemos growth como um processo iterativo de melhoria, baseado em ciclos rápidos de experimentação. O foco do processo é aprender: sobre o cliente, o onboarding, estratégias que funcionam e não funcionam, e assim por diante. Consequentemente, quanto mais rápido o ciclo, maior o aprendizado e o impacto que você tem sobre métricas de Produto.

Este post destaca três dos principais aprendizados que tivemos em nossa aventura de experimentação dentro do RD Station.

1) Faça coisas que não escalam

Para os olhares do usuário, um experimento nunca deve parecer um experimento.

Porém, lembre-se que o objetivo de um experimento é aprender, não colocar no ar uma solução perfeita para o usuário ou robusta tecnicamente. Por isso, do things that don’t scale. Reduza ao máximo o tempo necessário para colocar um experimento no ar - mesmo que isso signifique assumir débitos técnicos.

No caso do onboarding do RD Station, nossa solução dependia fundamentalmente de uma hipótese simples: se colocarmos uma checklist com algumas atividades na tela inicial do produto, novos clientes vão seguir essa lista de tarefas. Obviamente, não queríamos esperar a solução final do onboarding entrar no ar para descobrirmos que ela falhou devido a algum detalhe tão simples. Pelo contrário: colocamos no ar rapidamente um experimento para testar se essa hipótese era verdadeira ou não!

Outro exemplo foi o caso de notificações in-app. Sabíamos por benchmarking de outras empresas que notificações dentro do produto eram uma forma poderosa de guiar o usuário a realizar ações que nós julgávamos importantes. Porém, não tínhamos certeza se isso funcionaria para usuários do RD Station.

Ao invés de desenhar um fluxo complexo de notificações, com base em árvores de decisão e comportamentos do usuário, fizemos o oposto: criamos manualmente uma série de segmentações (por exemplo, clientes que fizeram ações X e Y nos últimos 5 dias) e enviamos para elas mensagens sem nenhuma automação por trás dos panos. Dessa forma, validamos rapidamente (e com custo nulo de desenvolvimento) se deveríamos investir ou não neste caminho de solução.

Apenas depois de validar que uma modificação realmente tem o potencial de impacto que você imaginava, você deve se preocupar em colocar no ar uma solução robusta - e escalável.

Suponha que, ao rodar o experimento da checklist, você descobre que menos de 5% dos clientes novos clicam em pelo menos um dos itens da lista. Ainda faz sentido desenhar todo o onboarding do produto em torno dessa feature?

Em suma, o processo de growth é diferente de um processo normal de desenvolvimento de Produto, porém demoramos para perceber isso. Em alguns casos, investimos tempo de desenvolvimento para rodar um experimento, quando poderíamos ter obtido o mesmo resultado com uma solução manual. Dessa forma, teríamos aprendido com muito mais antecedência - e muito menos esforço.

2) Evite experimentos épicos

Quanto maior o escopo do experimento, menor a certeza que você terá sobre os aprendizados. Por exemplo, ao rodar um experimento que envolve vinte modificações em uma tela do produto, mesmo que a métrica que você está acompanhando seja sensivelmente impactada, como você saberá quais das vinte modificações realmente foram importantes? Então o que você aprendeu afinal?

Teste inconclusivos

Como sempre, existe um trade-off (compromisso) envolvido. Em alguns casos, métricas de produto são pouco sensíveis a modificações pequenas. Minimizando o escopo de um experimento, você corre o risco de nunca impactar uma métrica (no exemplo anterior, talvez as vinte modificações juntas fossem necessárias para impactar o indicador). Ao mesmo tempo, experimentos pequenos tendem a ir para o ar muito mais rapidamente!

Apesar de ser um exemplo recorrente, experimentos que testam pequenas modificaçõe (como, por exemplo, o impacto de alterar a cor de um botão na taxa de clique) frequentemente chegam a resultados inconclusivos.

O segundo ponto do trade-off é o overhead para colocar um experimento no ar. Ao quebrar um experimento grande de vinte modificações em vinte experimentos pequenos, será necessário vinte deploys, vinte code reviews, etc. A partir de certo ponto, isso se torna ineficiente.

Duas heurísticas que aprendemos na prática para determinar se o escopo do experimento está adequado:

  • Se você está com dificuldade de definir apenas uma hipótese quantitativa, seu experimento ainda está grande demais (você está testando mais de uma hipótese ao mesmo tempo!). Simplifique ele!

  • Se você está demorando mais de uma semana para colocar o experimento no ar, independente de quantos desenvolvedores e designers estão alocados, seu experimento ainda está grande demais (deve existir uma forma mais simples de testar a sua hipótese!). Simplifique ele!

Na dúvida, comece com experimentos pequenos e torne-os mais sofisticados ao longo do tempo. Até porque, em geral, existem diversas oportunidades de otimização que podem ser facilmente descobertas com experimentos muito simples!

Além disso, experimentos pequenos são muito mais fáceis de gerir e analisar, o que facilitará a sua vida enquanto você aprende a gerir um processo de growth. Falando nisso…

3) Foque no processo, não nos resultados

Os resultados dos primeiros experimentos são insignificativos, se comparados com os resultados que um (bom) processo de growth pode trazer a médio e longo prazo para o seu produto.

Processo

Por isso, evite tomar decisões imediatistas para acelerar experimentos, como não manter um grupo de controle, finalizar o teste antes de atingir a amostra mínima ou - o erro mais comum - iniciar um experimento sem uma hipótese quantitativa formalmente definida. Foque em criar um processo e cultura no qual bons experimentos são planejados e executados. A longo prazo, isso é muito mais importante do que a melhora de 30% na taxa de conversão que você obteve em sua primeira tentativa.

Claro, resultados importam. Eles são importantes para manter a motivação da equipe, além de mostrar para o restante da área o valor de apostar em um processo de experimentação. Mas investir em um processo funcional é muito mais importante.

Apesar de a mídia focar em apenas alguns poucos hacks famosos de empresas como Facebook e Airbnb, que “explicam” seus resultados monstruosos, no mundo real não existem balas de prata. O crescimento destas empresas foi na verdade resultado de um conjunto de experimentos bem e mal-sucedidos - além, de claro, produtos que entregam valor real para seus clientes.

Todos naturalmente começam sua jornada com growth em busca do experimento que resolverá todos os seus problemas. No nosso caso, procurávamos o experimento que resolveria o onboarding do RD Station. Infelizmente, ainda não o encontramos. Por outro lado, após alguns experimentos que deram certo e vários que deram errado (e geraram diversos aprendizados!), conseguimos impactar uma série de indicadores importantes da nossa base de clientes.

E nós atribuímos isso ao nosso processo de growth; não a algum experimento específico que deu certo.

Para onde estamos indo

Isso mostra como nosso processo não é perfeito: continuamos aprendendo sobre como otimizar nosso método de experimentação. Ao mesmo tempo, começamos a “espalhar” nossas táticas de experimentação para outros times dentro da nosso área de Produto, com objetivo de melhorar o engajamento com as demais features do RD Station.

Naturalmente, com isso, surgem outros desafios. Por exemplo, como coordenar os esforços de growth de times diferentes, com objetivos diferentes, dentro do mesmo produto. Mas isso é um assunto para o próximo post!

Até a próxima!

Luigi Cenatti Gianni

Luigi Cenatti Gianni

Product Manager

Comentários