Erros e acertos na experimentação em produtos digitais
Estes dias me dei conta de que já fazem 10 anos desde que comecei a estruturar e executar de maneira mais estruturada processos de experimentação em times de produto e design. Naquela época, quando operava a Neue Labs, fazíamos isso para os nossos clientes e para as startups incubadas com o objetivo de aprender e tomar decisões importantes rapidamente, sem longos ciclos de desenvolvimento — algo que normalmente mata novos negócios digitais. Em outro momento, quando atuei na liderança de produto para negócios já mais desenvolvidos, a experimentação tinha um papel de otimizar o tempo de times de desenvolvimento e dar mais segurança para o time de produto, tecnologia e demais stakeholders sobre o que deveria de fato ser desenvolvido e entregue para clientes e usuários.
A ideia deste texto foi de compilar alguns dos inúmeros erros que cometi ao longo desses anos — dentro de diferentes contextos — e compartilhar os aprendizados que tirei de cada um deles, numa tentativa de criar um pequeno guia que possa ser útil pra quem está neste desafio. Dividi o assunto em duas partes: na primeira (esta aqui) falo dos erros, na segunda entro nos acertos e aprendizados.
Sobre o que estou falando mesmo?
É sempre bom refrescar a memória sobre o que quero dizer quando falo de experimentação: basicamente estou falando sobre a aplicação do método científico para validação de hipóteses. Este vídeo absolutamente incrível de uma aula do físico Richard Feynman explica (em inglês).
A importância da experimentação em produtos digitais
Todo desenvolvimento de produto (ou feature ou serviço digital) é um processo cheio de riscos e incertezas. Como CPO, boa parte do meu trabalho é garantir que os times (não apenas de produto, mas os times que acabam derivando o trabalho a partir do direcionamento de produto, como tecnologia, design, growth, etc.) estão trabalhando nas coisas que tem o maior potencial possível de geração de valor para o negócio. E diante dessa responsabilidade, trabalhar baseando decisões em fé ou otimismo é algo completamente ilógico.
Experimentar significa atuar reconhecendo e incorporando as incertezas — que são inerentes às nossa ideias e projetos — ao nosso processo de trabalho. Significa trabalhar tentando ficar mais próximo da criação de valor real para o negócio. Significa eliminar riscos de uma implementação, algumas vezes sem uma linha de código.
Significa, principalmente, entender que um produto é um sistema dinâmico e complexo — e não um conjunto de features que times vão empilhando ao longo de cada trimestre.
Big mistake, huge!
As situações que pra mim foram mais significativas e que me trouxeram mais aprendizado foram estas quatro:
experimentar tudo
experimentar demais
experimentar sem saber pra onde se está indo
ter cautela demais (ou pouca cautela)
A seguir conto mais sobre eles.
1. Experimentar tudo
Tudo é experimentável. Por exemplo: um estudo feito em um restaurante comparou as gorjetas deixadas por clientes que recebiam a conta pastas pretas contra douradas. Os que recebiam a pasta dourada deixavam em média gorjetas 15% maiores.
Porém, não é por isso que tudo deveria passar pelo método científico. O que passa pela esteira de experimentação deve ser definido a partir de uma avaliação de risco e incerteza. Se há algum risco relevante sobre a hipótese que precise de mitigação, o recomendado é testar. E se a hipótese em questão tem evidências fracas sobre seu potencial, experimentos vão ajudar a trazer mais informações para aumentar a confiança do time.
Muitas das vezes as hipóteses que temos são de baixo risco, ou porque são ajustes mais incrementais ou porque seus riscos atrelados são conhecidos ou foram mitigados em rodadas anteriores de validação. Nesses casos, elas deveriam ir direto para a esteira de delivery/rollout.
Importante: bons times de produto conseguem equilibrar as esteiras de experimentação e rollout pra que exista uma cadência de valor sendo entregue para o cliente ou usuário. Vou escrever sobre isso em breve.
2. Experimentar demais
Em algum momento se espalhou no mercado a ideia de que todo time de produto deveria rodar dezenas de testes por semana, ou então não tinha um bom processo de experimentação — eu mesmo fui uma das pessoas que tentou ir nessa linha.
O que aprendi durante essas tentativas foi que realizar muitos testes simultâneos — quando você não tem um time de tecnologia com 1500 pessoas — pode gerar alguns efeitos colaterais indesejados. Como a diminuição da capacidade de análise do time, o que acaba fazendo com que as elas mais superficiais do que o necessário, prejudicando a tomada de decisão.
Outro efeito é a criação de uma complexidade desnecessária a partir da sobreposição entre múltiplos testes. O que acaba acontecendo é a necessidade de criação de uma fila de experimentos — algo com o qual não concordo. Cada time deveria estar trabalhando no experimento que pode trazer mais impacto naquele momento — e não algumas semanas pra frente.
Em times maiores é possível rodar vários testes em paralelo, mas não quer dizer que você o deva fazer só porque pode. Às vezes manter um time, mesmo que grande, focado em um aprendizado por vez, pode ajudar a garantir uma profundidade maior nas análises e melhores decisões — que no final é o propósito desse processo.
3. Experimentar sem saber pra onde se está indo
Uma das tarefas mais difíceis na gestão de um sistema de experimentação é garantir que cada time esteja mostrando progresso significativo, (validando ou invalidando hipóteses e apostas), em direção a um objetivo.
É bem fácil se perder no monte de dúvidas que precisam serem respondidas e acabar priorizando as que o time ou stakeholders mais gostariam de ter respostas. E acabar deixando as perguntas ou testes mais importantes para mostrar progresso de maneira rápida e/ou substancial em segundo plano.
Uma boa esteira de experimentação tem relação direta com o objetivo final — seja provar um incremento em uma métrica, validar a implementação de uma feature ou validar uma ideia de negócio. E após cada experimento é possível enxergar não apenas o seu resultado específico, mas o seu impacto (ou a ausência dele) no objetivo em questão. O objetivo serve como ponto de referência para entender se existe progresso positivo ou não.
Sem isso, duas coisas muito ruins podem acontecer: o time "orbitar" ao redor de uma hipótese ou aposta, sem conseguir mostrar progresso em relação ao objetivo, ou então não saber a hora de declarar algo invalidado e entrar num loop sem tomada de decisão, já que não há referencial.
No próximo texto eu falo sobre a possibilidade de definir metas (sim, metas) numéricas ou qualitativas de progresso para uma esteira de experimentos.
4. Cautela demais (ou pouca cautela)
No geral, times que fazem parte de negócios que estão começando costumam ser menos cautelosos do que empresas mais consolidadas, tanto na escolha das hipóteses a serem testadas quanto na abordagem do teste. Já passei pelos dois casos e acho que ainda prefiro na maioria das vezes ficar um pouco mais do lado da pouca cautela.
Explico: pra mim um ambiente aberto para a experimentação, em que tudo pode ser questionado (desde que com argumentos bem embasados) e onde não se tem medo de errar, é muito valioso — e difícil de se conseguir. A verdade é que não se faz um omelete sem quebrar alguns ovos. Provavelmente o processo de validação de uma aposta que tem alto potencial vai exigir bem mais do que alguns testes a/b.
Alguns erros que já cometi foram buscar todos os alinhamento "necessários" antes de testar algo. É importante saber que nem todo mundo ou todas as áreas entendem a lógica de experimentação e isso pode atrasar — ou até travar — o processo.
Para empresas maiores, um erro comum é rodar testes de novos produtos ou serviços utilizando a sua marca (e não algo mais genérico ou brandless). Isso normalmente enviesa os resultados — pois o fator marca entra na conta junto com a proposta de valor. Além de tender também a travar o processo, pois normalmente o teste vai precisar obedecer guidelines de marca, compliance, etc.
Não se pode perder de vista o porquê da esteira de experimentação existir e as premissas para que ela realmente funcione. Se você não consegue aprender e progredir a uma velocidade maior do que se utilizasse a esteira de delivery, o processo perde completamente o sentido.
Faixa bônus: cópia da cópia da
Um processo pode funcionar maravilhosamente bem para uma empresa mas ser desastroso para outra. Por mais que estejamos falando sobre processo científico, que tem as mesmas etapas e sobre o qual existe muito conhecimento acumulado, as variáveis que interferem tanto nos processos quanto nos próprios testes, mudam drasticamente de empresa para empresa. Não adianta copiar.
Algumas das variáveis que resultam num processo às vezes completamente diferente entre dois lugares são, por exemplo:
cultura e maturidade do time
tamanho do time
contexto de mercado (competição, regulação, etc.)
dinâmicas de growth e performance (uma empresa que opera sistematicamente promoções precisa de mais cuidado na hora de isolar amostras, por exemplo)
tipo de produto (b2b vs. b2c, tamanho do tráfego disponível para amostragem, se app ou desktop, etc.).
Caramba, sensacional, Paulo! Já quero o próximo artigo hahaha
ps: faltou o "anos" no título após o "10" ;)