Alguém olha para a página de planos e diz: esse formulário está grande demais, vamos testar com menos campos. A frase parece o começo de um experimento. Este episódio responde o que vem antes dela: como escrever uma hipótese testável a partir de um problema observado na página.
A diferença aparece quando o número chega. Teste com hipótese escrita produz aprendizado nos dois desfechos, porque você sabe o que apostou e por quê. Teste sem hipótese produz um número solto, que cada área interpreta como convém, e o time termina três semanas depois sem saber o que aprendeu.
A aula de experimentação organiza o ciclo em seis etapas: meta, diagnóstico, hipótese, experimento, decisão e memória. A hipótese ocupa a terceira posição de propósito, depois do diagnóstico, porque só existe hipótese honesta quando existe um dado observado antes dela.
E ela vem antes do experimento, porque é ela que define o desenho do teste: qual página, qual público, qual métrica decide. Quem pula essa etapa acaba desenhando o experimento pela ferramenta que tem à mão, e a ferramenta nunca sabe qual é a sua dúvida.
Palpite e hipótese se parecem quando estão escritos lado a lado no mesmo quadro. Como você separa os dois na prática?
Com três perguntas. Qual dado observado sustenta isso, e de quando ele é. O que precisaria acontecer para essa frase ser considerada falsa. Qual número decide. Palpite não responde nenhuma das três. A aula tem uma formulação que vale decorar: hipótese sem evidência é palpite com cronograma.
Palpite às vezes acerta, e ninguém precisa fingir o contrário. O problema é o preço: cada teste ocupa tráfego, ocupa fila e ocupa semanas do programa. Resolver dúvida barata com teste caro consome a capacidade que resolveria uma dúvida cara.
Daí a regra dura do backlog, que é a fila de testes candidatos: hipótese com a coluna de evidência vazia volta para o diagnóstico e fica fora das primeiras posições. Isso funciona como triagem, não como castigo. Diagnóstico se resolve mais barato, com gravação de sessão, entrevista e leitura de funil.
Primeiro pilar da hipótese: o problema observado. O que conta como observado?
Comportamento registrado em algum lugar, com data e origem anotadas. Gravação de sessão mostrando onde as pessoas param. Funil por etapa mostrando qual passagem caiu contra os dois períodos anteriores. Entrevista com quem abandonou. Contato ao suporte repetindo o mesmo tema. Algo que outra pessoa abre e confere sem depender do seu relato.
E o que não conta, mesmo vindo de alguém experiente?
Comparação com o concorrente, boa prática lida em artigo, e a frase que aparece em toda reunião: os leads estão vindo ruins. Isso é sintoma relatado, e sintoma abre o diagnóstico, jamais o fecha. Quem recebe essa frase tem a tarefa de transformá-la em número antes de transformá-la em teste.
Antes de fechar este pilar, tem um detalhe que costuma passar despercebido: a instrumentação da medição.
Antes de acreditar na taxa do painel, alguém precisa ter conferido o caminho do dado. Evento disparado no navegador mede intenção de envio; registro criado no destino mede o fato de negócio. Quando os dois divergem sem explicação, a evidência ainda não existe, e a hipótese apoiada nela também não.
Agora o formato. A aula reduz a hipótese a uma frase de três partes: se mudarmos X, então Y deve acontecer, porque Z.
X é a mudança, e precisa ser uma só. Se a variação troca o título, encurta o formulário e muda a cor do botão ao mesmo tempo, o resultado vem sem endereço. Você não descobre qual das três moveu o número, e o aprendizado morre junto com a leitura.
Y é o resultado esperado. Qual é o cuidado nessa parte da frase?
Y precisa ser um número já medido hoje, com direção declarada: sobe ou desce, e em qual métrica. Escrever que a experiência vai melhorar não fecha nada, porque melhora não tem leitura. E convém que Y termine perto do fim do funil, em vez de parar na métrica mais próxima da mudança.
Sobrou o porque Z, que é a parte que mais gente corta por pressa.
Z é o mecanismo: por que essa mudança deveria produzir esse efeito nessa pessoa. É o que separa a hipótese de um sorteio com nome bonito. E tem valor prático imediato: quando o teste perde, o Z é o que sobra para aprender. Você descobre que aquele mecanismo não operava como o time imaginava, e isso reordena as próximas hipóteses da fila.
A frase escrita ainda não fecha o pacote. Falta dizer quem decide o resultado.
A aula chama essa métrica única de OEC, do inglês overall evaluation criterion, o critério geral de avaliação: a métrica escolhida de antemão para dizer se o teste venceu. Uma só. Card com quatro métricas de sucesso cria liberdade de interpretação, e no dia do resultado alguém escolhe a que subiu.
E as outras métricas que o time acompanha ficam fora da conversa?
Ficam como contexto, e algumas viram guardrail, a métrica protegida que a vitória não pode custar: retenção, receita recorrente mensal, qualidade do lead aceito por vendas, velocidade de resposta da página. Variação que sobe a métrica principal e viola um guardrail declarado conta como derrota.
Isso soa duro para quem passou duas semanas defendendo a variação.
É duro, e é por isso que fica escrito antes. Guardrail com limiar declarado tira a decisão do terreno da opinião no dia do número. Guardrail sem limiar vira decoração: quando o resultado chega, cada um lembra de um patamar diferente e decide quem fala mais alto na sala.
Um exemplo completo, com a ressalva que a própria aula faz: todos os números aqui são supostos, escritos para deixar a conta visível. Suponha uma plataforma de assinatura mensal. A reunião de segunda abre com custo por lead bom, página convertendo bem e contratos parados há dois meses.
O time quer testar o título da página. Quem conduz o ciclo abre o funil primeiro. Suponha visita para lead estável em quatro por cento, e a aceitação do lead pelo comercial caindo de trinta e oito para trinta e um por cento em dois meses. O vazamento mora depois da página que todo mundo queria mexer.
Achou a etapa. Falta a evidência do comportamento.
Ela vem da gravação de quarenta sessões de abandono. Suponha seis de cada dez pessoas parando no campo de faturamento mensal, num formulário de nove campos. Agora existe data, origem e número. Repare que a evidência não manda fazer nada; ela delimita onde a dúvida mora. A mudança continua sendo uma aposta.
Com a evidência na mão, a frase da hipótese fica escrita como?
Assim: se o campo de faturamento sair do formulário e virar a primeira pergunta do agente de qualificação, então a taxa de visita para lead sobe, porque o esforço de preencher cai no momento de maior impaciência. A métrica que decide, porém, é outra: contratos por mil visitas. E o guardrail vem com limiar, aceitação do lead nunca abaixo de vinte e oito por cento.
Três semanas de exposição depois, o teste terminou como?
Com a taxa de lead subindo de quatro para cinco vírgula dois por cento, e a sala comemorando por dez minutos. Aí veio o recálculo direto do sistema: aceitação em vinte e três por cento, e contratos por mil visitas em dois vírgula quatro contra dois vírgula cinco. Guardrail violado, liberação barrada, formulário de volta aos nove campos. E o ciclo entregou algo melhor que a vitória: o gargalo mora na capacidade de qualificação, e não nos campos do formulário.
O erro mais comum aqui tem um disfarce excelente, porque parece produtividade. O backlog anda rápido, o programa mostra muitos testes concluídos no trimestre, e o funil termina o ano com as mesmas taxas. Boa parte dos resultados volta inconclusiva.
A causa está na coluna que ordenou a fila. Esforço é o campo mais fácil de preencher, então a fila vira a lista do que dá menos trabalho subir. Os testes caem em etapas de alcance pequeno, sobre hipóteses que ninguém ancora em dado observado, e cada resultado morre no dia em que é lido.
E a saída, para quem se reconheceu nessa descrição, cabe nesta semana?
Cabe. Reordene a fila pelos cinco critérios da aula: evidência primeiro, depois alcance, esforço, risco de guardrail e tempo de reversão. Devolva ao diagnóstico toda hipótese com a evidência vazia e recuse a entrada dela até existir um dado com data e origem. A fila encurta, e encurtar é o objetivo.
Tem um efeito colateral bom nisso. Quando a evidência vira obrigatória, o time descobre que parte das ideias nem precisava de teste: eram erros claros de usabilidade, que se corrigem direto, com o guardrail acompanhado nas semanas seguintes.
Antes de mandar a hipótese para a fila, quatro perguntas filtram bem. A primeira: se a resposta vier ao contrário do esperado, alguma decisão real muda? Quando nada muda nos dois desfechos, o teste é entretenimento caro, e você acabou de descobrir isso de graça.
A segunda é desconfortável: você aceitaria o resultado contrário? Quem já decidiu subir a mudança de qualquer jeito não precisa de teste, precisa de plano de reversão e de um guardrail acompanhado.
A terceira: o mecanismo Z é verificável fora da sua cabeça. Se o Z for que as pessoas gostam mais assim, ainda não há mecanismo escrito. A quarta: quanto custa voltar atrás. Mudança reversível em minutos tolera aposta mais ousada; mudança que mexe em preço ou contrato pede aprovação de outro nível.
E quando a hipótese passa nas quatro perguntas, o que acontece com ela?
Entra na fila com o card preenchido e vira o experimento do ciclo. Vencedora ou perdedora, o resultado é arquivado no repositório do programa, para que o próximo time não proponha a mesma variação com outro nome daqui a seis meses.
Fechando com o que fazer amanhã de manhã. Pegue a próxima ideia de teste da sua lista e escreva as três partes: a mudança, o resultado esperado com a métrica e o mecanismo. Depois escreva a métrica única que decide e um guardrail com limiar.
Se você travar no porque Z, achou o ponto: o que falta ali é diagnóstico, e não redação. Volte para a gravação de sessão, para o funil por etapa ou para três conversas com quem abandonou, e escreva de novo com o dado na mão. Costuma levar meia hora e economiza três semanas.
No próximo episódio a gente pega a pergunta que vem logo depois da frase escrita: quanto tráfego e quanto tempo esse teste precisa para entregar uma resposta em que dá para confiar.