Priorização de backlog com IA: onde o RICE automático erra a mão

RICE — Reach, Impact, Confidence, Effort — é o framework de priorização mais usado em produto porque transforma "eu acho que isso é importante" em um número comparável. Cola a lista de itens do backlog num chat de IA, pede para pontuar cada um em RICE, e em segundos vem uma planilha inteira preenchida. Parece ter economizado a reunião mais chata do mês.

Testei esse pedido com um backlog real de dez itens, descrição de uma linha cada, sem contexto adicional. O resultado saiu rápido, organizado, com números plausíveis em cada célula — e quase inútil, porque os números não vinham de lugar nenhum.

O problema não é velocidade, é origem do número

RICE funciona porque cada letra representa um dado que, na teoria, vem de algum lugar real: Reach vem de analytics (quantos usuários um recurso afeta por período), Impact vem de pesquisa ou intuição calibrada da equipe, Confidence vem da qualidade da evidência por trás do Impact, Effort vem de estimativa de engenharia.

Quando você pede para a IA pontuar sem dar esses dados, ela não tem de onde tirar Reach ou Confidence — só tem a descrição de uma linha do item. O que ela faz, então, é inferir a partir de padrões de linguagem: itens que soam "grandes" (palavras como "todos os usuários", "crítico", "urgente") recebem número alto; itens que soam pequenos recebem número baixo. É julgamento por vocabulário, não por dado.

O sintoma que denuncia o problema

Rode o teste você mesmo: peça para pontuar dez itens de backlog reais sem contexto, e olhe a distribuição dos números de Confidence. Em praticamente todo teste que fiz, os valores se agrupam num intervalo estreito — a maioria entre 70% e 90% — porque o modelo não tem base para diferenciar de verdade um item com evidência forte de um item puramente especulativo. Se a Confidence não varia, ela não está medindo nada; está preenchendo campo obrigatório.

Esse é o sinal mais confiável de que o framework virou teatro: quando toda linha da planilha tem uma confiança parecida, ninguém mediu confiança de verdade — só rodou uma fórmula em cima de números que já eram inventados.

O que a IA faz bem nesse processo

Separar a parte mecânica da parte de julgamento muda o resultado.

Estruturar a planilha e a fórmula. Pedir para montar a estrutura RICE, com a fórmula (Reach × Impact × Confidence ÷ Effort) e as colunas certas, é trabalho que a IA faz bem e economiza tempo de verdade — é configuração, não estimativa.

Gerar as perguntas que faltam. Em vez de pedir a pontuação direto, peça: "para cada item, quais perguntas eu preciso responder para estimar Reach com confiança?". Isso transforma a IA em facilitadora de reunião — ela aponta a lacuna de dado, e o time preenche com número real.

Explicar o raciocínio por trás de uma estimativa dada por humano. Depois que alguém do time estima Impact em "3 — moderado, afeta usuários avançados", pedir para a IA questionar essa estimativa ("por que não é alto, já que afeta retenção de conta enterprise?") frequentemente puxa um raciocínio que não tinha sido dito em voz alta.

A IA é boa em transformar estimativa humana em documento organizado. Não é boa em ser a fonte da estimativa — porque estimativa de impacto de produto depende de contexto que só quem está no time tem: histórico de churn, ticket de suporte, conversa com cliente da semana passada.

Um critério para separar as duas partes

• Deixe a IA fazer: montar planilha, calcular a fórmula, listar perguntas em aberto, resumir a discussão da reunião de priorização.
• Não deixe a IA fazer sozinha: atribuir o número de Reach, Impact ou Confidence sem que alguém do time tenha de fato pensado nesse número — mesmo que ela produza algo plausível.

O risco de pular essa distinção não é só ter um backlog mal priorizado. É pior: é ter uma planilha com números que parecem rigorosos — a fórmula foi aplicada, afinal — enquanto a decisão real continua sendo por instinto, só que agora com uma camada de falsa objetividade em cima. Isso torna a decisão mais difícil de questionar depois, porque "os números dizem" vira desculpa para não repensar.

Para o lado de estimar prazo com o mesmo cuidado com número solto, vale ler Estimativa de prazo: por que erramos sempre.