Template de Roadmap de Experimentação (grátis)
Template de roadmap de experimentação pronto para copiar: colunas, score PIE e ICE, e a checagem de amostra que quase todo backlog esquece.
📚 Este artigo faz parte do guia Como Construir uma Cultura de Experimentação (2026).
Um roadmap de experimentação é a fila priorizada e datada dos testes que o time vai rodar, com hipótese, métrica primária, amostra necessária e duração estimada em cada linha. Ele não é um backlog de ideias: um backlog acumula, um roadmap compromete. Este artigo entrega o template pronto para copiar, explica como pontuar cada item com PIE ou ICE, e cobre a coluna que quase nenhum framework de priorização inclui e que decide se o item é executável de verdade: a viabilidade estatística. Tem priorizador e calculadora ao vivo, e um exemplo trabalhado em que o item de maior potencial do backlog cai do quarto para o último lugar da fila quando a duração entra na conta. Este é um dos artigos do guia de como construir uma cultura de experimentação.
O que um roadmap de experimentação é (e o que não é)
A confusão mais cara nessa área é tratar backlog e roadmap como sinônimos. São dois artefatos com funções diferentes:
- Backlog de ideias: tudo que apareceu (pedido de stakeholder, achado de sessão gravada, palpite do time de vendas). Não tem ordem, não tem compromisso, e crescer é normal.
- Roadmap de experimentação: a fatia do backlog que já foi pontuada, dimensionada e ordenada. Cada item tem hipótese escrita, métrica primária definida, amostra calculada e uma janela de execução. Aqui, crescer sem limite é sintoma de problema.
A diferença prática aparece na reunião de planejamento. Com backlog, a conversa é “o que a gente acha que funciona”. Com roadmap, é “o próximo item da fila entra segunda e roda 3 semanas”. A primeira conversa se repete todo mês, a segunda acaba em cinco minutos.
O template de roadmap de experimentação: as colunas que importam
Copie a tabela abaixo para a sua planilha ou base de conhecimento. Cada coluna existe para responder a uma pergunta que costuma aparecer no meio da execução, quando já é tarde:
| Coluna | O que preencher | Por que existe |
|---|---|---|
| ID | Código curto e único (EXP-014) | Referenciar o teste em painel, commit e relatório sem ambiguidade |
| Página ou fluxo | Onde a mudança acontece | Agrupar itens que competem pelo mesmo tráfego (dois testes na mesma página se atrapalham) |
| Hipótese | Porque observei X, acredito que Y vai causar Z, medido por W | Evita o teste sem previsão, que não ensina nada quando dá empate |
| Métrica primária | Uma só, escolhida antes de rodar | Impede a troca de métrica depois de ver o resultado |
| Guardrails | Métricas que não podem piorar | Protege receita, churn e reclamação enquanto a primária melhora |
| Taxa base atual | A conversão de hoje naquela métrica | Entra direto no cálculo de amostra |
| MDE alvo | Efeito mínimo que vale detectar | Define o tamanho do teste; sem ele não existe prazo |
| Amostra por variação | Saída da calculadora | Torna a viabilidade um número, não uma opinião |
| Duração estimada | Amostra total dividida pelo tráfego diário | Transforma a fila em calendário |
| Score (PIE ou ICE) | Média das três notas | Ordena a fila com critério explícito |
| Status | Ideia, priorizado, rodando, concluído, arquivado | Mostra o trabalho em andamento e limita o WIP |
| Resultado e decisão | Vencedor, empate ou perdedor, e o que foi feito | Vira o repositório de aprendizado do time |
Duas colunas costumam gerar discussão e vale defender as duas. Guardrails existe porque quase todo experimento consegue melhorar uma métrica isolada às custas de outra: um popup mais agressivo aumenta captura de e-mail e piora reclamação. Resultado e decisão existe porque um roadmap sem memória vira uma esteira que repete testes já feitos assim que a rotatividade do time apaga o que se aprendeu com eles.
Como pontuar: PIE e ICE
Os dois frameworks mais usados pontuam cada item de 1 a 10 em três dimensões e, na formulação original de cada um, tiram a média simples das três notas:
| Framework | Dimensões | Origem | Quando encaixa melhor |
|---|---|---|---|
| ICE | Impacto, Confiança, Facilidade | Creditado a Sean Ellis, no contexto de growth | Times que priorizam iniciativas variadas, não só CRO de página |
| PIE | Potencial, Importância, Facilidade | Criado por Chris Goward, na WiderFunnel, para projetos de CRO | Times de CRO que precisam considerar quanto tráfego passa por cada página |
Um aviso antes de escolher: circulam por aí duas contas diferentes para os mesmos frameworks, uma que tira a média das três notas e outra que multiplica as três. A média é a formulação descrita nas fontes originais de cada um, é a que este artigo usa e é a que o priorizador abaixo calcula. Se você adotar a versão que multiplica, a escala muda (de 1 a 1.000 em vez de 1 a 10) e a ordem final pode mudar junto, então escolha uma conta e mantenha ela no roadmap inteiro.
A diferença real está na segunda letra. No ICE, Confiança pergunta “qual a chance de essa hipótese estar certa?”, ou seja, quanta evidência sustenta a hipótese (Growth Method, ICE Framework). No PIE, Importância pergunta quanto vale o tráfego daquela página. O próprio Chris Goward define as páginas mais importantes como as de maior volume e de tráfego mais caro de comprar (Goward, Practical Ecommerce). Um redesign brilhante de uma página que recebe 200 visitas por mês tem Potencial alto e Importância baixa, e é justamente esse tipo de item que o PIE empurra para baixo na fila e o ICE não.
Nenhum dos dois é preciso, e é importante dizer isso em voz alta: são notas subjetivas que servem para tornar a discordância explícita, não para produzir um número verdadeiro. Kohavi e Thomke, na Harvard Business Review, sustentam justamente que nem especialistas da área acertam com regularidade quais mudanças vão vencer, e que é por isso que vale testar ideias que a priorização por opinião descartaria. O ganho real do score, então, não é a ordem final: é a conversa que ele força quando duas pessoas dão 3 e 9 para a mesma dimensão do mesmo item.
Pontue o seu backlog agora, escolhendo o framework no seletor, e exporte o ranking:
| # | Experimento | Potencial | Importância | Facilidade | Score | Remover experimento |
|---|---|---|---|---|---|---|
| - | - | |||||
| - | - | |||||
| - | - |
Nada aqui sai do seu navegador: a lista não é enviada a lugar nenhum e o CSV é gerado localmente. O score é a média das três notas, e a régua serve para comparar ideias entre si, não para adivinhar quem vai vencer o teste.
A coluna que falta em quase todo framework: viabilidade estatística
PIE e ICE respondem “isso vale a pena?”. Nenhum dos dois responde “isso é executável?”. E essa segunda pergunta reprova muito item bem pontuado.
Um teste só termina quando acumula amostra suficiente para detectar o efeito que você busca. Essa amostra depende da taxa base, do efeito mínimo detectável (MDE) e do rigor estatístico escolhido. Com a amostra em mãos e o tráfego da página, a duração vira uma divisão simples. O guia de como fazer um teste A/B passo a passo cobre o cálculo em detalhe; aqui interessa o efeito dele sobre a fila.
Veja três itens plausíveis de um mesmo backlog, todos com 18.000 visitantes por semana no fluxo testado:
| Item | Taxa base | MDE alvo | Amostra por variação | Duração |
|---|---|---|---|---|
| Novo layout da página de produto | 3,2% | +12% relativo | 34.885 | 28 dias |
| Mesmo layout, ambição maior | 3,2% | +20% relativo | 13.015 | 11 dias |
| Novo fluxo de cadastro (conversão em compra) | 1,1% | +15% relativo | 67.375 | 53 dias |
Amostra por variação por aproximação normal de duas proporções (95% de confiança, 80% de poder, bilateral); duração para 2 variações e 18.000 visitantes por semana.
O terceiro item é o exemplo do problema: quase dois meses de execução ocupando o fluxo inteiro. Ele pode até ser o item de maior potencial do backlog, e ainda assim aprová-lo significa gastar todo o trimestre em um único teste. A saída não é ignorar a estatística, é reformular o item: buscar um efeito maior (o que muda a natureza da mudança proposta), mover a métrica primária um nível acima no funil (medir início de cadastro em vez de compra), ou aplicar a mudança num fluxo com mais tráfego.
Calcule a amostra e a duração de cada linha do seu roadmap:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Exemplo trabalhado: a fila muda quando a duração entra
Um time de e-commerce pontuou seis itens com PIE. Ordenados só pelo score, a fila sairia assim (nota média de Potencial, Importância e Facilidade):
| Item | P | I | F | Score PIE | Duração estimada |
|---|---|---|---|---|---|
| Novo fluxo de cadastro | 9 | 8 | 4 | 7,0 | 53 dias |
| Prova social na página de produto | 7 | 8 | 8 | 7,7 | 11 dias |
| Frete grátis destacado no carrinho | 8 | 7 | 7 | 7,3 | 14 dias |
| Redesign da página de categoria | 8 | 6 | 3 | 5,7 | 28 dias |
| Novo texto do botão de checkout | 4 | 9 | 10 | 7,7 | 9 dias |
| Vídeo na home | 6 | 4 | 5 | 5,0 | 35 dias |
Pelo score puro, a ordem seria: prova social e texto do botão empatados em 7,7, depois frete grátis (7,3), depois o novo fluxo de cadastro (7,0). Agora entre a coluna de duração e a fila de execução real muda de forma:
- Trimestre pelo score, sem olhar duração: prova social (11 dias), texto do botão (9 dias), frete grátis (14 dias), cadastro (53 dias). Total: 87 dias, e o trimestre acaba com 4 testes concluídos, dos quais o último ocupou mais da metade do calendário.
- Trimestre por score dividido pela duração: texto do botão (9 dias), prova social (11), frete grátis (14), redesign de categoria (28). Total: 62 dias, quatro testes concluídos, e ainda sobram cerca de 4 semanas de calendário para um quinto teste ou para uma repetição de confirmação.
O item de maior potencial (cadastro) não foi descartado, foi adiado e reformulado: com a métrica primária mudada de compra para início de cadastro, a taxa base sobe, a amostra cai e ele volta à fila do trimestre seguinte com duração viável. Essa é a decisão que a coluna de duração torna possível e que o score sozinho esconde.
Cadência: quantos itens e com que frequência revisar
Um roadmap útil é do tamanho da capacidade real do time, e essa capacidade é limitada pelo tráfego antes de ser limitada por pessoas. Se o seu fluxo banca dois testes por mês, uma fila de 40 itens priorizados não é planejamento, é ficção: quando o item 20 chegar, o contexto que justificou a nota dele terá mudado. O artigo quantos testes A/B você deveria rodar por mês mostra como calcular essa capacidade a partir do tráfego, e é ela que deve definir o tamanho da fila.
Uma cadência que funciona bem na prática:
- Revisão mensal: reordena a fila com o que os testes concluídos ensinaram, aposenta itens que perderam contexto e traz itens novos do backlog bruto.
- Revisão a cada teste concluído: um resultado muda a confiança estimada dos itens vizinhos. Se a hipótese de prova social perdeu na página de produto, o item equivalente na página de categoria merece nota menor antes de entrar na fila.
- Limite de trabalho em andamento: um teste por vez em cada tela ou fluxo. Programas grandes rodam dezenas de experimentos simultâneos sem problema, porque eles tocam partes diferentes do produto; a ressalva vale para dois testes que mexem nos mesmos elementos. Nesse caso você escolhe entre rodar os dois em exclusão mútua, e aí cada um recebe metade do tráfego e demora o dobro, ou deixar o mesmo visitante cair nos dois, e aí as duas mudanças podem se somar de um jeito que nenhuma das leituras isoladas prevê (o exemplo clássico é cada teste empurrar o botão de compra um pouco para baixo, e o visitante que pegou os dois nunca ver o botão). Kohavi, Tang e Xu tratam o desenho de programas com muitos experimentos concorrentes em Trustworthy Online Controlled Experiments.
Erros comuns num roadmap de experimentação
| Erro | Sinal de alerta | Correção |
|---|---|---|
| Fila muito maior que a capacidade | 40 itens priorizados, 2 testes por mês | Dimensione a fila pela capacidade de tráfego, deixe o resto no backlog bruto |
| Item sem hipótese escrita | “Testar o botão vermelho” | Escreva dado, mudança, efeito esperado e métrica antes de pontuar |
| Ignorar duração na priorização | Um item de 8 semanas entrou como “quick win” | Adicione a coluna de duração e ordene por score dividido por duração |
| Score inflado por quem propôs | Todo item do time de produto tem Potencial 9 | Pontue em dupla ou em comitê, e registre a divergência |
| Sem guardrail definido | Conversão subiu, ninguém checou reembolso ou churn | Defina 1 ou 2 guardrails por item antes de rodar |
| Roadmap sem coluna de resultado | Ninguém lembra por que o item foi arquivado | Registre resultado e decisão em cada linha concluída |
| Dois testes no mesmo fluxo | Duas mudanças simultâneas no checkout | Um teste por fluxo, sempre |
Faça isso automático na Donnu
Um roadmap de experimentação só se sustenta quando cada linha dele tem números reais por trás: amostra calculada, duração estimada e um veredito honesto no fim. Essa é exatamente a parte que a Donnu automatiza: você define a hipótese e a métrica primária, a Donnu dimensiona o teste contra o seu tráfego real, avisa quanto tempo ele vai levar antes de você aprovar a linha, e devolve o resultado com o intervalo de confiança em vez de um selo verde. O roadmap deixa de ser uma planilha de intenções e vira uma fila com prazo confiável.
Comece um teste grátis de 14 dias e dimensione o próximo item da sua fila antes de aprová-lo. Para o resto do processo, veja como construir uma cultura de experimentação e como escrever uma hipótese de teste A/B.
Referências
- Growth Method. PIE Framework: prioritise marketing tests by Potential, Importance and Ease. Descreve o framework criado por Chris Goward na WiderFunnel. growthmethod.com/pie-framework.
- Growth Method. ICE Framework: the original prioritisation framework for marketers. Descreve o framework criado por Sean Ellis. growthmethod.com/ice-framework.
- Kohavi, R. e Thomke, S. The Surprising Power of Online Experiments. Harvard Business Review, 2017. hbr.org/2017/09/the-surprising-power-of-online-experiments.
- Kohavi, R. ExP Platform: accelerating innovation through trustworthy experimentation. Material de referência sobre programas de experimentação em escala. exp-platform.com.
Leia também:
Perguntas frequentes
- O que é um roadmap de experimentação?
- É a fila priorizada dos experimentos que o time vai rodar, com hipótese, métrica primária, tamanho de amostra estimado, duração e status de cada item. Diferente de um backlog de ideias, o roadmap já respondeu a pergunta "isso cabe no nosso tráfego e em quanto tempo", então cada linha dele é um teste que pode entrar em execução sem nova discussão.
- Qual a diferença entre PIE e ICE para priorizar experimentos?
- Os dois pontuam cada ideia de 1 a 10 em três dimensões e, na formulação original, tiram a média das três notas (parte das implementações que circulam por aí multiplica em vez de tirar a média, o que muda a escala e pode mudar a ordem final). O ICE (Impacto, Confiança, Facilidade) é creditado a Sean Ellis, no contexto de growth, e serve para qualquer tipo de iniciativa de crescimento. O PIE (Potencial, Importância, Facilidade), criado por Chris Goward na WiderFunnel para projetos de otimização de conversão, troca Confiança por Importância, que mede quanto tráfego e receita passam pela página em questão. Na prática, o PIE evita que o roadmap invista em melhorias promissoras numa página que quase ninguém visita.
- O que quase todo roadmap de experimentação esquece?
- A viabilidade estatística. Um item pode ter score alto em qualquer framework e mesmo assim ser impossível de rodar, porque o tráfego da página não fecha a amostra necessária dentro de um prazo aceitável. Antes de aprovar um item, calcule a amostra por variação e a duração estimada; se der mais de 6 a 8 semanas, o item precisa ser reformulado (efeito maior, métrica mais acima do funil ou página com mais tráfego), não apenas agendado.
- Quantos itens um roadmap de experimentação deve ter?
- O suficiente para cobrir de dois a três meses de capacidade real de execução, não mais. Um roadmap com 60 ideias e capacidade de 2 testes por mês é uma lista de desejos que envelhece: as prioridades mudam antes de a fila andar. Dimensione a fila pela capacidade que o seu tráfego banca e mantenha o resto como backlog bruto, sem data.
- Com que frequência revisar o roadmap?
- Uma revisão mensal costuma ser suficiente para reordenar a fila com o que os testes concluídos ensinaram, mais uma revisão rápida sempre que um teste termina. Resultados mudam a confiança e o potencial estimados dos itens vizinhos, então reordenar depois de cada conclusão evita que o time execute uma fila que já ficou obsoleta.