Há uma situação que aparece com bastante frequência.
Uma organização decide que determinado produto é estratégico. Define objetivos, aloca orçamento, monta uma equipe e começa a executar.
Então chegam os dados.
E eles mostram algo diferente.
Talvez outro produto tenha uma conversão melhor. Talvez os clientes não valorizem uma funcionalidade como esperávamos. Talvez uma mudança que parecia obviamente positiva acabe piorando o resultado.
Nesse momento, algo interessante acontece: em vez de rever a decisão, começamos a procurar outra métrica.
Mudamos o período. Olhamos para outro segmento. Encontramos uma explicação.
Até encontrar um número que confirme aquilo que já havíamos decidido.
A empresa tem dados. Tem dashboards. Provavelmente tem uma equipe de Data.
Mas isso não significa que seja data-driven.
Existe uma enorme diferença entre usar dados para tomar uma decisão e usar dados para justificar uma decisão que já tomamos.
Para mim, ser data-driven tem muito menos a ver com a quantidade de dados que temos e muito mais com o método que utilizamos para decidir.
E, acima de tudo, com nossa capacidade de descobrir rapidamente quando estamos errados.
O valor dos dados não está em estar sempre certo
Durante muito tempo, associamos uma organização data-driven a determinadas capacidades: data warehouses, dashboards, KPIs, analistas, cientistas de dados e relatórios distribuídos por toda a empresa.
Tudo isso pode ser extremamente valioso.
Mas é infraestrutura.
Uma empresa pode ter tudo isso e continuar tomando decisões exatamente da mesma forma que antes.
Para mim, a lógica deveria se parecer muito mais com o método científico:
Hipótese → Teste → Medição → Decisão → Aprendizado
Temos uma ideia sobre o que pode acontecer. Procuramos uma forma de testá-la. Definimos qual resultado esperamos e qual evidência nos faria mudar de opinião. Executamos, medimos e aprendemos.
Há um dado que considero particularmente revelador.
Em um trabalho sobre experimentação em larga escala, Ron Kohavi e outros pesquisadores relataram que apenas cerca de um terço das ideias testadas na Microsoft melhoravam as métricas que pretendiam melhorar.
É um número bastante incômodo.
Porque, se até organizações com enorme capacidade tecnológica e de experimentação erram com frequência ao antecipar quais ideias vão funcionar, talvez o objetivo não devesse ser nos tornarmos extraordinariamente bons em prever.
Talvez devêssemos nos tornar extraordinariamente bons em descobrir rapidamente quando nossa previsão estava errada.
Uma das maiores vantagens de trabalhar com dados não é aumentar nossa capacidade de estar certos. É reduzir o custo de estar errados.
Uma opinião pode se transformar em uma hipótese
Isso aparece o tempo todo em decisões de produto.
Suponhamos que acreditamos que reduzir a taxa de juros de determinado produto aumentará a conversão o suficiente para compensar a redução da margem.
Alguém pode estar convencido de que vai funcionar. Outra pessoa, com o mesmo nível de experiência, pode pensar exatamente o contrário.
Podemos discutir durante semanas.
Ou podemos transformar a discussão em algo que possa ser testado:
Se reduzirmos a taxa de X para Y, esperamos que a conversão aumente Z, mantendo determinados níveis de rentabilidade e risco.
A diferença pode parecer pequena, mas muda completamente a conversa.
Já não estamos discutindo quem está certo.
Estamos desenhando uma forma de descobrir.
Isso também muda a maneira como penso sobre a intuição.
Uma pessoa que trabalha há quinze anos em um negócio provavelmente acumulou uma enorme quantidade de conhecimento que nenhum dashboard consegue capturar completamente. Reconhece padrões, entende exceções e pode detectar mudanças antes que elas apareçam claramente em uma métrica.
Eu nunca descartaria essa intuição.
Eu a usaria para gerar hipóteses.
Se alguém me diz: “Pela minha experiência, acredito que, se fizermos X, Y vai acontecer”, minha resposta não deveria ser necessariamente “os dados dizem outra coisa”.
Deveria ser:
Como podemos testar isso?
A experiência gera hipóteses. A evidência nos ajuda a avaliá-las. E o resultado melhora nossa experiência para a próxima decisão.
Uma métrica deveria ter uma decisão por trás
Outra situação que encontro com frequência começa assim:
“Precisamos medir isso.”
Antes de construir a métrica, gosto de fazer três perguntas:
Que ação você vai executar com base nela?
Com o que você vai compará-la?
O que significa estar indo bem ou mal?
Suponhamos que construímos um dashboard que mostra:
Conversão: 18%.
Isso é bom?
Não sabemos.
Talvez ontem fosse 12%. Talvez nossa meta seja 25%. Talvez um segmento converta 30% e outro 4%. Talvez a conversão tenha aumentado porque estamos aceitando clientes com um risco significativamente maior.
Ou talvez esteja em 18% há seis meses e ninguém pretenda tomar uma decisão diferente, independentemente de amanhã cair para 15% ou subir para 21%.
Nesse caso, surge uma pergunta incômoda:
Por que estamos olhando para essa métrica?
Uma métrica sem uma decisão associada corre o risco de se transformar simplesmente em informação.
E acumular informação não é o mesmo que construir conhecimento.
Melhorar uma métrica pode piorar o negócio
Esse ponto é particularmente importante porque os experimentos raramente têm apenas uma consequência.
Suponhamos que reduzimos uma taxa e a conversão melhora.
Ganhamos?
Ainda não sabemos.
Podemos ter aumentado a conversão ao custo de reduzir demais a margem. Ou podemos ter incorporado clientes com um nível de risco muito maior.
Por isso, além de uma métrica principal, precisamos definir o que não estamos dispostos a deteriorar enquanto tentamos melhorá-la.
Em experimentação, elas costumam ser chamadas de guardrail metrics. Prefiro pensar nelas simplesmente como métricas de proteção.
Se nosso objetivo é aumentar a conversão, por exemplo, rentabilidade e risco podem funcionar como métricas de proteção.
A regra é simples:
Se o experimento melhora a métrica principal, mas prejudica uma métrica de proteção relevante, o experimento não venceu.
Isso se torna especialmente importante quando os resultados aparecem em momentos diferentes.
Em crédito, por exemplo, podemos observar mudanças na conversão praticamente de imediato. Mas algumas consequências relacionadas ao comportamento de uma carteira podem levar meses para aparecer.
Uma decisão pode parecer extraordinária durante as primeiras semanas e muito menos atraente alguns meses depois.
Medir rápido não significa necessariamente aprender rápido se estamos medindo apenas a parte do resultado que aparece primeiro.
Nem tudo pode — ou deve — ser experimentado
Também precisamos reconhecer os limites desse método.
Nem toda decisão pode ser transformada em um teste A/B.
Existem organizações ou produtos com volumes tão baixos que esperar significância estatística pode ser pouco realista. Nesses casos, precisamos utilizar outras ferramentas: comparações temporais, evidências qualitativas, análises históricas ou simplesmente a melhor informação disponível.
Também existem decisões difíceis de reverter.
Uma decisão de arquitetura, uma contratação importante ou determinadas decisões regulatórias nem sempre permitem um pequeno experimento antes de avançar.
Nesses casos, a pergunta muda.
Não é:
“Como fazemos um teste A/B?”
É:
“Que evidência podemos obter antes de tomar uma decisão cujo custo de reversão é alto?”
E existem ciclos de feedback longos.
Podemos modificar algo hoje e observar rapidamente uma melhora em uma métrica, enquanto o custo aparece três ou seis meses depois.
Por isso, não acredito que ser data-driven signifique experimentar absolutamente tudo.
Isso também pode se transformar em burocracia.
Significa escolher o instrumento correto para a decisão que temos diante de nós.
Quanto mais reversível for uma decisão, mais barato deveria ser testar e aprender.
Quanto menos reversível for, mais importante se torna entender nossas premissas antes de avançar.
O problema não é apenas cultural. Também está nos incentivos
Há algo importante que precisamos reconhecer.
Dizer que uma organização deve estar “disposta a mudar de opinião” soa bem.
Mas nem sempre é tão simples.
Imagine que alguém propôs uma iniciativa, conseguiu orçamento, convenceu a liderança, montou uma equipe e passou seis meses executando.
Agora os dados mostram que a hipótese estava errada.
Aceitar esse resultado não significa apenas dizer: “Eu estava errado.”
Pode significar cancelar um projeto, realocar pessoas, explicar por que determinado orçamento foi gasto e talvez colocar em risco o financiamento da próxima iniciativa.
Existem incentivos reais para continuar.
Por isso, não basta pedir objetividade.
Precisamos desenhar mecanismos que tornem a objetividade mais provável.
Um mecanismo bastante simples é registrar antes da execução qual é a hipótese, qual é a métrica principal, quais métricas queremos proteger e qual resultado nos faria parar ou mudar de direção.
Também ajuda definir datas explícitas de revisão. Continuar uma iniciativa não deveria ser sempre a opção automática enquanto cancelá-la exige uma decisão extraordinária.
E provavelmente existe algo ainda mais importante:
Uma organização deveria ser capaz de reconhecer como um bom resultado ter interrompido cedo uma iniciativa depois que as evidências mostraram que ela não funcionava.
Se cancelar for sempre interpretado como fracasso, as equipes aprenderão rapidamente a encontrar argumentos para continuar.
Podemos ter toda a infraestrutura de dados do mundo e continuar tendo esse problema.
Aprender também exige memória
Suponhamos que testamos uma hipótese e ela não funciona.
Gastamos pouco, medimos corretamente e aprendemos que, sob determinadas condições, nossa ideia estava errada.
Isso pode ser um resultado extremamente valioso.
O desperdício aparece quando, seis meses depois, outra equipe propõe exatamente a mesma coisa porque ninguém sabe que ela já foi testada.
Por isso, acredito que uma organização orientada por dados deveria preservar mais do que tabelas e dashboards.
Ela deveria ser capaz de responder:
Que hipótese testamos?
O que esperávamos que acontecesse?
O que realmente aconteceu?
O que decidimos?
E o que aprendemos?
Além disso, um teste bem-sucedido não deveria se transformar automaticamente em uma verdade permanente.
Os clientes mudam. O mix muda. A concorrência muda. O produto muda.
Algo que funcionou há um ano pode não produzir o mesmo resultado hoje.
Experimentar também significa voltar a observar se o efeito permaneceu quando o contexto mudou.
Vistos dessa forma, os dados deixam de ser apenas um ativo analítico.
Eles também se transformam em memória organizacional.
Cinco perguntas antes de construir outro dashboard
Eu resumiria tudo isso em cinco perguntas:
O que acreditamos que vai acontecer?
Qual é a forma mais barata de descobrir que estamos errados?
Que resultado nos faria mudar de decisão, e nós o definimos antes de olhar para os dados?
O que não estamos dispostos a prejudicar enquanto tentamos melhorar isso?
Onde ficará registrado o que aprendemos?
Não precisamos de uma plataforma sofisticada de experimentação para começar a trabalhar dessa forma.
Precisamos desenvolver o hábito de transformar opiniões em hipóteses, hipóteses em evidências e evidências em aprendizado.
Então, o que realmente significa ser data-driven?
Não acredito que signifique ter mais dashboards.
Nem ter um data lake, um warehouse ou um lakehouse.
Nem contratar mais cientistas de dados.
Nem medir absolutamente tudo.
Todas essas coisas podem ser necessárias.
Mas são ferramentas.
No artigo anterior, argumentei que uma boa decisão tecnológica começa com uma pergunta:
Que problema estamos tentando resolver?
Os dados acrescentam uma segunda pergunta:
Como vamos saber se realmente o resolvemos?
Nesse momento, os dados deixam de ser algo que observamos depois de tomar uma decisão.
Passam a fazer parte do mecanismo por meio do qual decidimos.
Por isso, se eu tivesse que definir uma organização data-driven de forma simples, diria:
Não é uma organização que tem uma resposta para tudo. É uma organização que construiu um método para descobrir rapidamente quando está errada.
O objetivo não deveria ser estar certo o tempo todo.
Deveria ser aprender rápido o suficiente para tomar uma decisão melhor na próxima vez.
Fonte
Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y. & Pohlmann, N. (2013). Online Controlled Experiments at Large Scale. Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining.