Hipóteses e priorização diante de taxas reais de acerto

O backlog tem sessenta ideias, cada uma com nota ICE calculada numa planilha, e a lista está ordenada de forma convincente. O problema aparece ao confrontar essa ordenação com a taxa histórica de acerto: se dois em cada três testes não vencem, a planilha está ordenando um conjunto no qual a maioria dos itens não vai funcionar.

Ordenar melhor um conjunto majoritariamente perdedor rende pouco. O que muda o retorno do programa é o critério pelo qual você decide o que entra na fila.

Os números que praticantes de experimentação em escala relatam publicamente pousam numa faixa desconfortável.

Na Microsoft, a regra que Ronny Kohavi popularizou a partir do Bing aponta cerca de um terço de resultados positivos, um terço neutros e um terço negativos. O Booking.com opera perto de 10% de taxa de sucesso, com uplift médio de aproximadamente 1% de receita por teste vencedor.

Antes das leituras, a ressalva que muda como você usa esses números: eles são ordens de grandeza declaradas por quem operou os programas, não benchmarks medidos. O do Booking.com é rastreável apenas a uma fala de executivo em podcast da Harvard Business Review, de 2019, sem metodologia publicada, e os outros dois não foram rastreados a publicação primária. Cada empresa define vitória de um jeito próprio, e as definições são incompatíveis, então comparar 8% com um terço como se fossem a mesma régua é o tipo de erro que um diretor atento desmonta em uma pergunta.

Duas leituras nascem daí. Um programa saudável tem maioria de resultados que não viram lançamento, e um time cuja taxa de vitória passa de 50% provavelmente está espiando dados sem método, testando apenas mudanças triviais ou medindo errado. A segunda leitura é sobre a natureza do retorno: os 6% do Airbnb não vieram de um teste brilhante, vieram de vinte ganhos pequenos que sobreviveram às checagens de validade.

ICE e PIE continuam úteis, com uma ressalva estrutural: os dois produzem uma nota de aparência objetiva a partir de julgamentos que não são.

O ICE, formulado por Sean Ellis no contexto de growth, soma Impacto, Confiança e Facilidade. O PIE, criado por Chris Goward na WiderFunnel, troca as duas primeiras por Potencial e Importância, onde Importância mede volume de tráfego da página e não valor por visitante, o que privilegia superfícies grandes mesmo quando o problema mora numa etapa pequena e cara. Nenhum dos dois nasceu como instrumento estatístico, e é injusto cobrar deles precisão que os autores não prometeram: ambos foram propostos como linguagem comum para destravar discussão entre áreas.

A falha está no uso, quando a nota final passa a ser tratada como resultado de um cálculo. Duas correções baratas eliminam a maior parte do teatro. Exija que quem pontua Confiança anexe a evidência que sustenta a nota, e recalibre a escala de Impacto contra o histórico real da própria empresa em vez da expectativa do autor.

A mecânica de ICE, RICE e MoSCoW, com as fórmulas e o backlog pontuado, está em Gestão de Projetos GEO. Aqui o foco é o critério que esses frameworks não têm: o custo em amostra.

Falta nos dois frameworks o recurso que de fato é escasso. ICE e PIE pontuam facilidade de implementação, que mede tempo de desenvolvedor, e ignoram a amostra, que mede tempo de tráfego. São coisas diferentes e a segunda é a que trava a fila.

O mecanismo é o efeito mínimo detectável, o MDE. A amostra necessária cresce com o inverso do quadrado dele: detectar 1% relativo exige vinte e cinco vezes a amostra que detectaria 5%. Uma ideia barata de implementar, mas cujo efeito plausível é pequeno, consome semanas de tráfego que três ideias de efeito maior consumiriam juntas. Ela aparece no topo da planilha por ser fácil de construir, e é a mais cara do backlog.

A correção é acrescentar uma coluna de amostra estimada ao lado de Facilidade, calculada a partir do MDE que a hipótese declara na terceira parte. Duas notas altas de Facilidade deixam de ser equivalentes quando uma custa três dias de tráfego e a outra custa dois meses.

A consequência de gestão é direta: a fila de testes é um orçamento de tráfego, e não uma lista de desejos. Uma ideia de efeito mínimo pequeno consome semanas de tráfego que três ideias de efeito maior consumiriam juntas, e aprová-la por ser barata de construir é gastar o recurso escasso para poupar o abundante. Quem assina a fila do trimestre precisa das duas colunas lado a lado, porque só uma delas mede aquilo que o programa realmente não tem.

Uma hipótese testável tem cinco partes, e a ausência de qualquer uma produz um teste que não ensina nada.

A primeira é a observação de origem, com a fonte do dado e a janela de tempo. A segunda é a mudança proposta, específica o bastante para alguém implementar sem perguntar. A terceira é o efeito esperado, com direção e magnitude plausível. A quarta é a métrica de decisão, escolhida antes de o teste começar, junto dos guardrails. A quinta, quase sempre ausente, é o que faria você mudar de ideia: qual resultado convenceria você de que a crença por trás da hipótese estava errada.

A quinta parte é o que separa hipótese de justificativa. Sem ela, qualquer desfecho é reinterpretado como confirmação parcial, e o repositório vira uma coleção de ideias que nunca falharam de verdade.

Há um argumento contraintuitivo, com apoio formal, sobre como gastar o tráfego disponível. Trabalho recente mostra que, sob restrição de tráfego, testar mais ideias com amostra menor por teste e limiar de significância mais relaxado pode render mais valor acumulado do que rodar poucos testes com desenho impecável.

A intuição vem de portfólio: quando a taxa de acerto é baixa e a distribuição de efeitos tem cauda, a probabilidade de encontrar algo relevante cresce com o número de tentativas. O custo é aceitar mais falsos positivos individuais, pagos pelo volume de tentativas.

Essa lógica tem fronteira, e ultrapassá-la sai caro. Ela vale para mudanças reversíveis, de baixo risco, com replicação do vencedor antes de qualquer lançamento definitivo. Em alteração estrutural, contrato com fornecedor ou mudança que toque faturamento, o limiar apertado continua valendo, porque o custo do erro deixa de ser simétrico.

Um teste perdedor bem documentado vale quase tanto quanto um vencedor, e vale mais que um vencedor mal documentado. Ele elimina uma hipótese do espaço de busca e impede que a mesma ideia retorne ao backlog em seis meses com outro nome e outro dono.

O registro mínimo que sustenta isso cabe em uma página: hipótese com as cinco partes, desenho do teste, tamanho de amostra e duração, resultado com intervalo de confiança, quais checagens de validade passaram, decisão tomada e o motivo dela. Anexe as capturas de tela das duas variantes, porque daqui a dois anos ninguém vai lembrar como era a página.

O valor aparece na terceira ou quarta rodada de priorização, quando alguém propõe uma ideia e o repositório responde que ela já foi testada em contexto parecido, com tal resultado. A priorização deixa de ser exercício de opinião e passa a ser informada pela base histórica da própria empresa, que é a única prior calibrada existente para o seu produto.