Refletindo sobre um ano de experimentos

Luca Albertalli Blocked Desbloquear Seguir Seguindo 5 de janeiro Foto de Franki Chamaki no Unsplash

Algumas semanas atrás eu saí do Shopkick. Há quase três anos que sou gerente de produtos, cobrindo muitos produtos diferentes. Tem sido uma montanha-russa, e como todo bom passeio, deixa você emocionado e pronto para a próxima aventura.

No meu caso, a próxima aventura está liderando a equipe da Plataforma de Experimentação para o Sony PlayStation. Então achei que era uma boa hora para repassar os aprendizados que tive no ano passado na Shopkick como Diretor de Insights e Produtos de Dados. Mais em detalhes Vou compartilhar algumas lições sobre como executar experiências com sucesso, lembrando que: “O sucesso não nos ensina nada; apenas falha ensina. [Adm. HG Rickover]. Nos meus planos, este é o primeiro de vários posts sobre ser um Product Manager orientado a dados.

O poder de uma única métrica

Quando comecei a coordenar as reuniões do experimento no Shopkick, encontrei-me olhando para uma longa lista de experimentos, todos com várias métricas. Eles estavam olhando para aumentar a retenção, melhorando a ativação, aumentando o número de atividades, aumentando o tempo gasto no aplicativo e assim por diante … Todos eles juntos. E adivinha? Sim, alguns deles foram bem-sucedidos em mover uma métrica, mas foram realmente bem-sucedidos como recursos? Na verdade não.

OK, qual é o problema com isso? Múltiplo:

  • O primeiro problema é que eles são objetivos potencialmente conflitantes: por exemplo, reter retenção e ativação. É relativamente fácil levar os usuários com mensagens do PNS para ativá-los. O risco dessa estratégia é que a maioria dos usuários removerá a permissão para enviar PNS ou começará a ignorá-los, levando a uma redução na retenção. Outro exemplo é o lucro versus receita: eu poderia otimizar a receita aumentando os gastos com marketing, aumentando assim o bolo ou maximizando o lucro, reduzindo os gastos com marketing. Mas na maioria das vezes eu ouvi executivos e PMs dizendo que queriam aumentar o lucro e a receita, e minha cabeça começou a bater forte contra a mesa.
  • O segundo problema é ainda pior. Quando você executa uma experiência de teste A / B, geralmente aceita o resultado quando o valor p é 5% ou inferior. O problema com isso reside no que é o valor p. Um valor p de 5% significa que você espera ver pelo menos um falso positivo a cada 20 experimentos. Se você tem dez métricas (e elas são independentes umas das outras), você tem 10 experimentos independentes, então você tem cerca de 40% de probabilidade de detectar um efeito mesmo que ele não exista.

Esse problema geralmente acontece quando a equipe de gerenciamento de projetos não tem uma visão real sobre como evoluir o produto e qual é o valor que ele tenta fornecer. Eles têm um conjunto de métricas de vaidade que desejam otimizar, objetivos vagos, mas nenhuma visão real do que em seus produtos oferece valores aos usuários. Selecionar uma boa métrica é difícil e merece uma discussão por si só, mas é absolutamente essencial.

Colete muitos dados e analise-os

Foto de Carlos Muza em Unsplash

Isso remete ao primeiro teste A / B que executei no Shopkick quando mudei da equipe da plataforma de dados para a equipe de presença. Estávamos experimentando um novo botão para permitir que os usuários fizessem o check-in. Execute o experimento com duas variações (bem, inicialmente era para ser uma mistura horrível de várias variáveis que eu felizmente cortei, mas estou divagando). Das duas variações, o perdedor esperado falhou espetacularmente, até pior do que a minha pior expectativa, mas a outra variação mostrou um aumento decente sobre o controle, algo que eu não esperava (sim, eu estava esperando o experimento falhar). Como de costume, comecei a me perguntar por quê. Com a ajuda do meu analista de dados, encontrei algumas hipóteses que testamos com sucesso apenas analisando os dados que já coletamos.

Essa sugestão não está em contraste com meu ponto anterior, já que a métrica principal ainda era uma. Porém, com métricas adicionais, várias dimensões e uma grande quantidade de dados, consegui entender por que minha experiência foi bem-sucedida, que foram os fatores determinantes e que impulsionaram minha próxima iteração. Agora, precisamos de algumas palavras de cautela aqui. De fato, as métricas secundárias que estavam se movendo poderiam ter sido apenas motores espúrios, lembre-se do exemplo de 10 experimentos acima? Mas o resultado foi bem alinhado com alguma intuição que desenvolvemos analisando outros pontos de dados (tivemos mais um problema de percepção devido à lentidão do que um problema de funcionalidade real), e as submétricas se alinhavam com os resultados experimentais. Isso não significa que começamos um projeto de vários meses para corrigir o problema. Em vez disso, realizamos outra experiência para confirmar a nova hipótese e, em seguida, uma nova e uma nova, trabalhando de forma incremental para criar uma experiência incrível.

Questões de agilidade

Foto de Marc Sendra martorell em Unsplash

Um efeito colateral do procedimento, como expliquei acima, é que você será péssimo em manter e executar um roteiro. Eu estive em uma situação quando eu estava de pára-quedas em uma nova equipe com 6 semanas para melhorar um recurso que não estava funcionando. Eu comecei a trabalhar como expliquei acima. Vários experimentos, foco nos resultados e na análise dos dados para criar novos recursos de forma incremental. Uma parte decente do que implementamos falhou. Apesar disso, nas próximas seis semanas nós tivemos que revisar nossos OKRs três vezes porque nós estávamos continuamente batendo neles (eles foram definidos com base na experiência anterior). Esse é o poder de ser conduzido por experimentos. A desvantagem? Executamos apenas um item no roteiro e, no final das seis semanas, meu roteiro era principalmente um backlog não ordenado de ideias que eu estava priorizando bem a tempo para o planejamento do sprint. Nosso gerente de projetos me odiava seriamente. Além disso, a liderança ficou desconfortável com essa abordagem, então após a crise de seis semanas, eles começaram a retirar recursos de minha equipe não porque não éramos eficientes ou o que estávamos trabalhando não era importante, só porque eu não era capaz de delinear um roteiro de longo prazo para justificar os recursos retidos.

O principal aprendizado dessa experiência foi que, para apoiar uma cultura de experimentação, você precisa de uma cultura voltada para ser ágil, de olhar para o planejamento a longo prazo em termos de resultados, não de recursos. E essa abordagem deve ser clara em todos os níveis, desde a liderança até cada equipe.

No nível de liderança, é necessária muita habilidade para abandonar o controle, confiando em seus gerentes de projeto e no líder de engenharia para fazer a escolha certa para você. Em troca, a liderança deve fornecer apoio e treinamento aos PMs e estabelecer objetivos claros que precisam ser alcançados. Nos níveis de equipe, o PM e o Eng lideram a tarefa de explicar claramente à equipe os objetivos, os resultados do experimento e por que há grandes mudanças nas direções a cada vez; Esta é a parte mais complicada e exigirá uma postagem no blog por ele mesmo. Finalmente, a equipe de gerenciamento de projetos deve passar de uma estrutura mais rigidamente organizada para uma organização mais fluida, ajudando o PM a resolver as dependências e coordenar o trabalho com outras equipes.

Cientista ou empresário, qual deles?

Foto de Adeolu Eletu em Unsplash

Uma das discussões mais interessantes que tive ao liderar as práticas de experimentação no Shopkick foi com uma colega da equipe de marketing sobre um de seus experimentos. Ela testava diferentes programas de incentivos para aumentar a ativação do usuário e tentava medir a elasticidade dos incentivos: apenas novos usuários, divididos em 50/50, afetam a ativação como métricas do experimento, métricas adicionais de engajamento, tempo para ativar métricas, etc. O problema que ela enfrenta foi o orçamento incremental necessário para executar o experimento. Ela tinha relativamente pouco orçamento para investir, então decidiu usar um bônus relativamente pequeno, um que ela suspeitava não ter sido tão eficaz.

A discussão foi entre mim, sugerindo que, uma vez que o incentivo testado estava abaixo do ideal, ela não deveria ter feito o experimento e poupado o orçamento para outros testes e ela alegando que a pergunta era essencial para ser feita e nós não sabíamos, talvez o pequeno incentivo foi de qualquer maneira suficiente para causar um movimento substancial. Ao fazer isso, ela expôs a questão fundamental ao executar um experimento controlado como gerente de produto. As Experiências Controladas são o padrão-ouro de qualquer cientista, e ser um PM de um aplicativo de sucesso significa que podemos realizar experimentos com muito mais pessoas do que a maioria dos experimentos controlados publicados em artigos científicos.

Na maioria das organizações, costumo ver duas abordagens contrastantes: quando a experimentação não é totalmente compreendida, vejo uma abordagem semelhante a um homem de negócios: “Dê-me alguns dados para apoiar minha intuição e decido quais são as coisas certas a fazer.” O benefício da experimentação é totalmente parte da cultura, eu começo a ver uma abordagem mais cientificista: "Nós devemos saber, nós saberemos."

Nenhum dos dois extremos é saudável. É fácil ser um HiPPO (Maior Opinião de Pessoa Paga), especialmente quando confrontado com a complexidade de executar um experimento. Adivinha? Há sempre alguém que pagou mais do que você, além disso, você quer manter seu emprego, então é melhor justificar sua opinião com fatos confiáveis. Ao mesmo tempo, é fácil experimentar tudo. Já vi experimentos que provaram que o envio de notificações push aumenta o app, não é brincadeira… Já vi trabalhos mostrando que se você mudar a cor de um botão para ficar vermelho, ele funciona melhor… Não admira: a versão de controle é cinza botão em um tema cinza, o experimento é vermelho sobre o mesmo tema. Não preciso de uma experiência para lhe dizer que o botão vermelho recebe mais cliques. O que preciso é uma experiência para entender quantos cliques mais qualificados recebo, quantos desses cliques convertem em uma compra.

Então, qual foi o objetivo do exemplo que dei? Bem, foi definitivamente um teste interessante para ser executado, tivemos dados anteriores sobre um programa de incentivo semelhante, e esse experimento adicional nos teria dado uma visão sobre a elasticidade do programa. O problema eram os resultados esperados: para obter o orçamento para executar os incentivos, precisávamos de um alto impacto (e o experimento foi projetado para detectar tal efeito), mas era improvável, dado o conhecimento que temos, obter esse tipo de impacto. O experimento foi ótimo a partir de um POV científico, mas a partir de uma perspectiva de negócios, o conhecimento que adquirimos do experimento não foi justificado (este é um tópico complexo, e eu o abordarei mais detalhadamente no futuro).

Eu tenho outro excelente exemplo dessa dicotomia. No Shopkick tivemos, no primeiro fluxo de uso, uma página que pedia ao usuário recém-cadastrado que convidasse seus amigos. Esse fluxo é bastante normal, já existe há algum tempo e passamos muito tempo ao longo dos anos otimizando-o. Parece bastante incontroverso, não? Eu acho que essa é uma das várias histórias de sucesso do growth hacking que são compartilhadas por aí… Então, qual é o problema? Bem, nossos designers de UX estavam ficando desconfortáveis com essa página. Foi intrusivo, e foi encorajador spamming seus amigos antes mesmo de saber o que era Shopkick. Do ponto de vista da UX, tinha que ir… Do ponto de vista do PM? Bem, uma rápida olhada nos dados mostrou que menos de 1% das pessoas estavam caindo naquela página. E recebemos mais de 50% do usuário convidado dessa página. Considerando que os usuários convidados têm uma probabilidade muito maior de serem retidos, parece óbvio manter a página e dizer ao designer para desligar, certo?

Não tão depressa. Não me importo com os usuários convidados, preocupo-me com os usuários retidos em geral e o total de kicks ganhos. Um exame mais detalhado dos dados mostrou que os convites dessa página tiveram uma taxa de conversão muito pior do que os outros convites, o que significa que eles eram leads menos qualificados. Além disso, as pessoas que pularam a etapa de convite acabaram convidando mais tarde: por isso, é possível remover essa página não reduzir o total de convidados retidos, mas apenas aumentar o tempo de ciclo de convite (geralmente conhecido como "Malha viral"). Soa sobre a hora de executar uma experiência? Exatamente, experimente como objetivo o número total de usuários retidos na semana 4. O teste quase confirmou a hipótese. Na verdade, não respondi pelo aumento de tempo para convidar, então quando analisamos os dados experimentais, vimos uma queda nos usuários retidos em geral, mas observando os resultados de coorte, para coortes mais antigas a diferença não foi estatisticamente significativa mesmo em 80%. Então eu tive quatro escolhas:

  • observe as métricas principais e declare que a experiência falhou;
  • reexecute a experiência considerando um tempo maior para convidar;
  • espere para ver se todas as coortes se comportaram da mesma maneira;
  • ou o que fizemos depois de discutir os resultados: removemos a página, monitoramos as coortes envolvidas no experimento e mudamos para um novo conjunto de hipóteses para melhorar o número de convites nesse cenário renovado.

Por que decidimos sobre essa abordagem? No final, nos preocupamos em tomar a melhor decisão possível para nossos usuários, o que os dados nos mostraram foi convincente o suficiente para remover o convite no primeiro fluxo de uso e nos movermos para otimizar outras partes do fluxo para compensar o eventual pequeno problema. queda nos usuários adquiridos (lembre-se, sempre há um problema de sensibilidade). Além disso, de uma perspectiva científica, os resultados estavam de acordo com a teoria que desenvolvemos olhando para os dados, poderíamos ter experimentado mais para ter maior certeza, mas consideramos a evidência boa o suficiente para passar para a próxima etapa do experimento.

Você está errado

Foto de Andrej Lišakov no Unsplash

Através deste post, admiti alguns erros que cometi; e fiz muitos mais deles. Eu aposto contra alguns recursos que, em vez disso, provaram ser bem sucedidos. Eu aposto em alguns recursos (múltiplos, na verdade) que eram falhas. Além disso, eu celebrei excelentes resultados apenas para perceber que eles eram tão bons apenas porque a métrica era ruim.

Admitir quando você está errado é difícil, mas extremamente importante e cada erro que você comete é uma oportunidade para aprender alguma coisa. O verdadeiro fracasso não é cometer um erro, mas deixar de aprender com isso.
Por que estou dizendo isso? Porque quando você é um PM orientado a dados e experiente, sua vida estará cheia de erros. Se você não está feliz em estar errado, procure outro emprego, não há lugar para você . As estatísticas mostram que apenas entre 20 e 30% do experimento proposto realmente mostram um impacto significativo e positivo, todos os outros experimentos são insignificantes ou causam danos. Isso é um problema? Na verdade, a menos que você tenha investido muito dinheiro e esforço na criação do recurso com falha. E então, se não funcionou, provavelmente é melhor saber disso pela próxima vez, em vez de ficar inconsciente.

Infelizmente, essa visão às vezes é difícil de aceitar para muitos PMs e muitos líderes empresariais. Isso não reduz a importância de admitir estar errado; Na verdade, é o caso de jovens Líderes de Produto aprenderem a lição e crescerem para serem melhores Líderes Empresariais.