velocidade a que uma startup cresce está diretamente relacionada com a velocidade com que aprende. O mesmo se aplica à equipa de growth.
Na equipa de growth queríamos utilizar uma estratégia que nos incentivasse a ser rápidos e trabalhar nos projetos certos. Uma das primeiras coisas que decidimos fazer na equipa foi criar um framework, que usamos numa lógica semanal, para definir quais as experiências que vamos fazer, permitindo-nos priorizar tarefas e, no final, analisá-las de acordo com o impacto.
As linhas que se seguem detalham a experiência do Pedro e da equipa de growth, contada na primeira pessoa, e incluem a forma como criámos este framework e usamos o Airtable.
O Pedro
Comecemos pelo Pedro. Adepto de exercício físico diário, o ginásio é um dos seus lugares extra-trabalho favoritos; adora estudar diversos tópicos, fazer network com outras pessoas da área e é um #foodie inveterado. Adora conhecer novos restaurantes e faz viagens exclusivamente gastronómicas. Vive no Porto mas nunca esquece Braga (a sua cidade Natal), e alimenta o desejo de, um dia, voltar à base.
O Pedro Costa começou a trabalhar na Coverflex em janeiro de 2021. Juntou-se à empresa para trabalhar na equipa de Marketing e Growth com o Luís Rocha (CMO) e a Maria Furtado (Content Manager), sobretudo na estratégia go-to-market da Coverflex. Durante os primeiros meses, o Pedro testou diversas estratégias, vários canais e diferentes abordagens ao mercado e, após três meses, começou a olhar para os resultados das estratégias que foram implementadas. Nessa altura, também começaram a surgir os primeiros clientes.
Porquê criar um framework de experimentação?
As fundações para desenvolvermos este framework estão diretamente relacionadas com o impacto que é esperado que a equipa de growth tenha para o crescimento da empresa.
Nos primeiros três meses, utilizámos um processo de experimentação muito mais arcaico onde o objetivo foi apenas testar quais os canais que poderiam funcionar e ver "low hanging results". No entanto, após percebermos quais os primeiros canais, decidimos aprofundar o nosso modelo e criar um processo de experimentação que nos trouxesse mais visibilidade, priorização, forecast, e que nos desse insights sobre quais os recursos necessários para aplicar as iniciativas.
Visibilidade: O framework deveria permitir a toda a equipa ter uma visão clara do que estamos a fazer para cada projeto e quais as iniciativas que estamos a desenvolver por surface (produto, segmento, canal...);
Priorização: O framework deveria permitir à própria equipa filtrar as iniciativas que geram mais revenue por dia de trabalho (mais sobre isto no próximo tópico);
Forecasting: O framework deveria permitir às pessoas perceber qual o impacto que cada ideia poderá ter após ser feito um sizing de cada experiência;
Recursos: O framework deveria permitir perceber quais as iniciativas que temos disponíveis bem como os recursos necessários.
Através destas fundações decidimos criar um framework que hoje utilizamos e que revemos semanalmente na nossa reunião de growth experimentation. De forma rápida, cada elemento da equipa pode ver quais as iniciativas em que trabalhou, a revenue esperada dessa iniciativa e, por fim, demonstrar quais os resultados que as iniciativas tiveram nas semanas anteriores.
1. Priorizar as ideias baseando-nos na revenue gerada por dia de trabalho
Na nossa equipa priorizamos ideias baseando-nos no impacto monetário que elas têm por dia de trabalho, ou seja, as ideias que primeiro implementamos são aquelas que vão trazer mais dinheiro no final do dia.
Para isso utilizamos um modelo que chamamos “growth velocity”, que analisa o potencial que a ideia tem, o esforço em dias que requer por parte dos vários departamentos (design, engenharia, conteúdo, produto e growth) e o tempo que nos demora a levar a cabo a iniciativa, e relacionamos estes fatores com a métrica do forecast interno que fazemos para cada produto.
Um exemplo prático desta growth velocity metric é imaginando que queremos testar um novo canal, definir a métrica que essa experiência vai ter (por exemplo, novos visitantes). Depois, para cada visitante, estabelecemos internamente um forecast para perceber a taxa de conversão de visitante para cliente (quantos visitantes precisamos para converter um cliente) e o valor que cada cliente agrega, em média, para cada produto em ARR. O resultado é a multiplicação deste valor pela confiança que temos nessa iniciativa concreta, dividida pelo número de dias necessários para desenvolver a ideia.
A fórmula seria a seguinte:
Growth velocity = Count of impact metric (p.e 7 new visitors) * Value of impact metric (p.e 1 visitor = 10€) * Success Confidence (p.e 0.9) / Time (p.e 1 days)
No final, resulta a revenue que vamos gerar, por dia, para cada uma das experiências. Dessa forma podemos rever cada uma das iniciativas e perceber aquelas que nos vão gerar mais dinheiro no menor número de dias possível.
Esta foi uma das formas que encontramos para alinhar, não só as prioridades dentro da equipa de Marketing, mas também este departamento particular com os objectivos da empresa, fazendo com que cada iniciativa possa trazer valor em ARR. Assim toda a empresa percebe o impacto que growth está a gerar.
2. Construir uma user based hypothesis
Cada uma das ideias tem de ter necessariamente uma user based hypothesis para poder ser aprovada. Após cada sprint, ao analisar quais as ideias que devemos lançar e, depois de olharmos para o Value of €€ per day of work, é isto que discutimos internamente.
Depois de algumas iterações da user based hypothesis, esta é a atual versão que utilizamos para discutir cada uma das experiências que temos:
Because we saw this {insert qualitative/quantitative data} ... I believe this will happen... and will increase/decrease {insert metric name} ... for this group {segment} ... because.... {insert user logic/emotion}
if this is true...we will need {insert number} amount of days to build it, and we need to wait {insert number} amount of days to do analysis, and then we will see an increase of {insert number} metric (abs. numbers)
O objetivo da hipótese é que nos permita perceber o que, de facto, acontecerá e porquê. No final de cada experiência olhamos novamente para a hipótese e tentamos perceber se esta estava correta ou não, porquê e quais são os próximos passos.
Na hipótese é também importante adicionarmos dados qualitativos e quantitativos. Esta é a forma de a tornar mais realista.
3. O que fazer se a hipótese estiver certa
Após definir a hipótese, centramo-nos em perceber o que podemos fazer se a hipótese estiver correta. Na maioria das vezes, tentamos perceber quais as próximas iniciativas que podem estar relacionadas com automatização de processos, expansão para outros canais (vertical) ou até otimização da forma como fazemos as coisas dentro do próprio canal (expansão horizontal).
O objetivo é percebermos, antes mesmo de lançar o teste, o que vamos fazer a seguir e pensar estrategicamente qual a escalabilidade destas iniciativas.
4. Leading & Lagging Metrics e reporting
Após percebermos exatamente o que fazer após a experiência, é hora de definir quais os leading e retention indicators para cada uma das experiências que realizamos.
Utilizando o exemplo acima referido - de aumentar o volume de novos visitantes - o leading indicator é, de facto, "novos visitantes". No entanto, tentamos utilizar uma métrica que nos permita perceber se estas visitas são ou não qualificadas: por exemplo, saber quantos destes novos visitantes se tornam visitantes da página para marcar uma demonstração. Isto permite-nos perceber a "qualidade" da leading indicators e se o tráfego que estamos a adquirir é, de facto, tráfego qualificado.
Depois de definirmos a experiência, decidimos como e onde vamos medir esta tarefa. Idealmente criamos um dashboard mas, na impossibilidade de o fazer ou se quisermos ser mais rápidos a testar, criamos pequenos relatórios em ferramentas como a Amplitude, G. Analytics, Hubspot, Data Studio, Convertize, entre outras.
Desta forma asseguramos que sabemos o que vamos medir e como a iniciativa se traduz em sucesso; ao mesmo tempo, qualquer pessoa pode acompanhar os resultados que cada experiência tem.
5. Velocidade de execução
Para nós é muito importante a velocidade com que conseguimos lançar cada iniciativa.
Inicialmente tentávamos fazer muitos projetos ao mesmo tempo e percebemos que isso era contraproducente. Neste momento, focamo-nos em duas ou três iniciativas por semana, por pessoa, e tentamos lançar cada iniciativa até duas semanas depois de ter sido iniciada.
O truque é definir bem a parte inicial, através de uma boa hipótese, ter um bom planeamento de sizing e a este processo garante uma execução muito mais rápida.
Outro dos elementos importantes na gestão destas iniciativas é o que nós chamamos de "portfolio of investment". Tentamos balancear bem entre as iniciativas que são mais arriscadas e que podem trazer grandes resultados daquelas que são menos arriscadas e que trazem resultados menores.
6. Analisar resultados
Após executarmos a tarefa, definimos no nosso Airtable uma data de início e uma data em que devemos analisar a tarefa (que é a mesma data que consta na nossa hipótese). Colocamos a tarefa como "To Be Analyzed" e, de forma semanal, vamos revendo as tarefas quando estas chegam ao período de serem analisadas.
Quando uma tarefa é lançada, existe uma notificação no nosso canal de Slack dedicado a "growth_launches", que inclui a informação de quem foi o responsável por lançar a tarefa, qual a métrica que vai afetar, o nome da iniciativa,a user based hypothesis e qual o valor que acreditamos que a iniciativa vai gerar por cada dia de trabalho.
Quando a tarefa chega à fase de análise, existe uma coluna no nosso Airtable com três questões:
1 - Why are the hypothesis/prediction wrong or right?
2 - Why did the experiment turned out the way it did? (for failure/success)
3 - What are the following experiments to continue testing & scale this hypothesis?
O objetivo é que cada pessoa volte a olhar para a tarefa, perceba se os resultados são idênticos ao forecast e hipótese que definimos, e perceba o porquê de ter ou não resultado. Baseando-nos nessas conclusões, é possível, nesta altura, perceber como podemos escalar a hipótese (em caso de sucesso).
Após cada experiência e análise da mesma, cada responsável por executar a tarefa é também responsável por definir a tarefa como “inconclusive”, "failure - valuable to tweak", failure - not valuable to tweak, "Success - continue exploring", "Success - scale".
Assim que a tarefa é analisada e, independentemente do resultado, noutro canal de Slack chamado "growth_learnings" existe uma nova notificação com as conclusões das iniciativas lançadas e com a informação sobre o responsável por executar a tarefa, qual a métrica que esta tarefa influenciou, qual a "user based hypotheses", o "Experiment result", a "expected revenue contribution", a"real revenue contribution" e o “experiment post mortem".
Desta forma, toda a equipa pode ter acesso imediato às iniciativas que foram analisadas e abrir grupos de discussão sobre o sucesso, aprendizagens e falhanço de cada experiência.
Completed experiments
Após analisar cada tarefa, existe uma tab no nosso Airtable que nos permite perceber quais as tarefas que lançamos e todos os resultados, hipóteses, expected revenue generated per day of work de todas as tarefas bem como muitos outros campos.
Desta forma, podemos visualizar mensalmente as tarefas que foram lançadas, quais os principais resultados, as maiores aprendizagens e ainda quais as oportunidades dentro de cada canal.
A revisão por trimestre (quarter)
O objetivo final é que, em cada trimestre, façamos uma retrospectiva das iniciativas que lançamos e reparemos se estamos a progredir.
Por progredir, o que queremos perceber é se:
- Em termos de output, quantas experiências nós lançamos no último quarter e se estamos a aumentar o volume de experiências.
- a accuracy das nossas hipóteses, ou seja, se elas ao longo do tempo estão a ser mais corretas em função dos resultados.. Isto porque com mais dados e com mais experiências é expectável que estejamos a aprender mais, podendo ajustar as nossas estratégias e táticas em função disso.
- Por último, perceber a média dos sucessos por falha ou experiência inconclusiva que lançámos, e fazer a comparação com o quarter anterior.
O que não incluímos nesta Growth Experimentation
Por este framework ser muito focado em experiências que sejam mensuráveis, decidimos não incluir algumas tarefas de notoriedade como, por exemplo, eventos ou publicações orgânicas nas redes sociais, entre outras tarefas. Para isso usamos o Clickup e é lá que gerimos essas iniciativas.
Outros dos aspetos que consideramos importante reforçar neste framework é que este não deve ser utilizado por empresas que ainda não tenham encontrado product market fit.
Ferramentas adicionais
Apesar de utilizarmos o Airtable para gerir as experiências, utilizamos outras ferramentas que são transversais, não só à equipa como a toda a empresa, e que nos ajudam a documentar este processo.
Usamos o Clickup para alinhar toda a equipa e empresa em relação aos OKRs, o Miro para esquematizar os processos que temos de aplicar ou desenvolver e, por fim, o Notion para documentar esses processos e que serve de histórico sobre diversas iniciativas.
.avif)
