Técnicas de priorização de backlog quando tudo é urgente

Todo backlog chega num ponto em que os itens do topo começam a ter justificativas impossíveis de comparar. Cliente pediu. Vendas prometeu. Concorrente lançou. Suporte está reclamando. Engenharia diz que vai quebrar. Fundador acha estratégico. Todos podem estar certos. Esse é justamente o problema.

Quando cada demanda entra por uma lógica diferente, marcar tudo como “alta prioridade” não significa que tudo é igualmente importante. Significa que o time ainda não criou uma forma comum de comparar coisas diferentes. É aí que técnicas como RICE ajudam. Não porque a fórmula sabe o que sua empresa deveria construir, mas porque ela obriga argumentos vagos a virarem premissas que podem ser discutidas.

Quando tudo é urgente, normalmente falta uma regra comum

Imagine quatro demandas. Uma veio do suporte porque clientes estão reclamando. Outra veio de vendas porque existe um contrato grande em negociação. Uma terceira veio da engenharia porque determinada parte do sistema está acumulando dívida técnica. A quarta apareceu porque um concorrente lançou algo parecido. Agora tente responder:

Qual delas é mais importante?

“Cliente pediu” não é comparável diretamente com “arquitetura está ficando perigosa”. “Pode fechar uma venda” não é comparável diretamente com “afeta 40% da base”. Sem um critério compartilhado, a prioridade tende a ser definida por outras forças: quem fala mais alto, quem está mais próximo da liderança, qual reunião aconteceu por último, qual cliente reclamou hoje, qual oportunidade parece mais concreta. O backlog começa a refletir pressão organizacional, não necessariamente prioridade de produto.

Antes de pontuar, separe o que não deveria estar na competição

Esse é um passo que muita planilha de priorização pula. Nem tudo deveria disputar posição pelo mesmo score. Existem itens que entram por restrição. Por exemplo:

• exigência regulatória com prazo;

• vulnerabilidade de segurança crítica;

• incidente em produção;

• obrigação contratual já assumida;

• infraestrutura próxima de um limite perigoso;

• correção necessária para impedir perda relevante de dados ou dinheiro.

Se uma mudança regulatória precisa estar pronta até 1º de novembro, ela não deveria perder para um redesign de onboarding porque o onboarding alcançou um RICE maior. A pergunta sobre a regulação não é:

isso gera mais impacto por pessoa-mês?

É:

o que acontece se não estivermos adequados até a data?

Antes de priorizar o backlog inteiro numa fórmula, eu dividiria em dois grupos. Obrigações e restrições: aquilo que precisa acontecer independentemente do ranking tradicional. Iniciativas disputando capacidade: problemas e oportunidades em que realmente existe escolha. Essa separação evita pedir para uma fórmula responder uma pergunta que não foi feita para responder.

RICE transforma quatro julgamentos em um score

Um dos frameworks mais conhecidos para essa comparação é o RICE, publicado pela equipe da Intercom. A sigla vem de Reach, Impact, Confidence e Effort, e a fórmula é:

(Reach × Impact × Confidence) ÷ Effort

O resultado tenta representar impacto esperado em relação ao esforço necessário. Não é uma verdade matemática sobre o produto. É uma forma estruturada de comparar iniciativas usando as mesmas quatro perguntas.

Reach: quantas pessoas ou eventos realmente entram nisso?

Reach tenta impedir que uma demanda pareça enorme apenas porque o caso individual é importante. A pergunta é: quantas pessoas ou eventos serão afetados dentro de um período definido? Pode ser clientes por trimestre, usuários por mês, transações por semana, organizações por semestre. O período precisa ser o mesmo entre os itens comparados.

Imagine:

melhorar recuperação de senha.

Talvez 4.000 usuários passem por aquele contexto no trimestre. Agora:

criar relatório solicitado por um cliente enterprise.

Talvez 40 pessoas utilizem. Isso não significa que o primeiro automaticamente deve ganhar. Mas agora existe uma diferença que antes estava escondida atrás de “o cliente pediu”.

Sempre que possível, Reach deveria vir de comportamento real: analytics, volume transacional, quantidade de contas, chamados, uso de determinada funcionalidade. Quando não existe dado, tudo bem estimar. Só não trate estimativa como medição.

Impact: quanto muda para cada pessoa atingida?

Reach sozinho favoreceria qualquer coisa que apareça para muita gente. Por isso entra Impact. A escala original apresentada pela Intercom é:

• 3: impacto massivo;

• 2: impacto alto;

• 1: impacto médio;

• 0,5: impacto baixo;

• 0,25: impacto mínimo.

Aqui começa uma parte muito mais subjetiva. O que significa “massivo”? Depende do objetivo que você está tentando mover: conversão, ativação, retenção, receita, redução de suporte, tempo operacional, adoção. O importante é não preencher Impact com a pergunta genérica “isso parece importante?”. Defina antes: impacto em quê? Por exemplo:

Quanto esperamos que essa iniciativa afete a ativação de quem passa por esse fluxo?

Agora a escala pelo menos aponta para um resultado comum.

Confidence: quanto disso sabemos e quanto estamos supondo?

Talvez esse seja o campo mais interessante do RICE. Um projeto pode parecer incrível porque todas as estimativas foram feitas no cenário mais otimista. Confidence introduz uma penalidade para essa incerteza. Na escala proposta pela Intercom:

• 100%: confiança alta;

• 80%: confiança média;

• 50%: confiança baixa;

• abaixo disso, a própria fonte trata como uma aposta altamente incerta.

Imagine:

clientes estão abandonando porque falta login por biometria.

Qual a evidência? Analytics? Pesquisa? Chamados? Experimento? Ou alguém ouviu dois clientes mencionarem isso? A ideia pode continuar boa. Mas a confiança deveria refletir o quanto realmente sabemos.

É aqui que o framework começa a produzir uma conversa melhor. Em vez de:

eu acho que vai funcionar.

a discussão vira:

por que estamos atribuindo 80% de confiança?

Agora é possível desafiar a premissa.

Confidence baixa não significa automaticamente “não construir”

Esse ponto merece cuidado. Um item com Confidence de 50% pode continuar sendo a decisão certa. Talvez o custo de descobrir seja justamente construir um experimento pequeno. Talvez a oportunidade tenha enorme upside. Talvez não exista maneira barata de obter evidência antes.

O score baixo não deveria funcionar como proibição. Ele pode indicar: precisamos aprender antes de comprometer muito esforço. Isso muda o tamanho da aposta. Em vez de construir a solução inteira, talvez o próximo item seja validar a hipótese com cinco clientes, prototipar, testar demanda, fazer spike técnico ou liberar para 5% da base. Baixa confiança não precisa parar o produto. Precisa mudar a forma como o produto aposta.

Effort: quanto realmente custa?

O último fator é esforço. Na formulação original, a Intercom utiliza pessoa-mês. Não apenas engenharia: o esforço total pode incluir Product Design, Product Management, engenharia, QA, dados, migração e implementação.

Essa parte também é estimativa. E possui um problema familiar: quanto menos investigado o item, menos confiável é o esforço. Uma feature em Now pode ter arquitetura discutida e escopo relativamente conhecido. Uma ideia de seis meses à frente pode receber “deve levar duas semanas” baseada em quase nada. Isso conecta diretamente priorização ao roadmap. Incerteza de prioridade e incerteza de esforço geralmente crescem juntas.

Um exemplo mostra por que o score ajuda

Imagine duas iniciativas fictícias.

Item A: melhorar recuperação de acesso

Reach: 4.000 usuários no trimestre. Impact: 1, impacto médio no objetivo escolhido. Confidence: 100%, porque analytics e suporte mostram claramente a frequência do problema. Effort: 0,5 pessoa-mês. O score seria:

(4.000 × 1 × 1) ÷ 0,5 = 8.000

Item B: novo relatório para um cliente enterprise

Reach: 40 usuários no trimestre. Impact: 3, porque é extremamente relevante para esse grupo. Confidence: 80%, porque ainda existe dúvida se o relatório pedido é realmente a melhor solução. Effort: 2 pessoa-mês. Score:

(40 × 3 × 0,8) ÷ 2 = 48

O primeiro vence de forma esmagadora pelo RICE. Isso significa que obrigatoriamente deveria ser construído primeiro? Não. Talvez o Item B seja necessário para renovar um contrato responsável por 20% da receita. Se for, existe um fator estratégico ou comercial importante que não está representado adequadamente na conta.

Esse é o valor do resultado. Não dizer:

8.000 é maior que 48, reunião encerrada.

Mas perguntar:

estamos dispostos a contrariar o ranking por causa deste contrato?

Se sim, ótimo. Agora a exceção está explícita. A decisão deixou de se esconder dentro de um número.

O score parece muito mais preciso do que realmente é

Esse é o principal perigo do RICE. 8.000 parece uma medição. Não é. Ele nasceu de uma estimativa de Reach, uma classificação de Impact, uma estimativa de Confidence e uma estimativa de Effort. Duas pessoas de boa fé podem produzir resultados diferentes. Impact 1 ou 2 muda bastante o score. Effort 1 ou 2 também.

Se alguém estiver emocionalmente comprometido com uma iniciativa, é perfeitamente possível escolher valores defensáveis que favoreçam o resultado desejado. Não precisa existir manipulação consciente. É assim que estimativa funciona. Por isso eu trataria RICE como estrutura para discussão, e não algoritmo que escolhe roadmap.

O valor está mais nos quatro campos do que no número final

Antes de existir score, alguém precisa responder: quantas pessoas isso alcança, o que muda para elas, que evidência sustenta essa expectativa e quanto custa. Só essas quatro perguntas já melhoram bastante uma discussão de backlog.

Imagine alguém dizendo:

precisamos urgentemente dessa funcionalidade.

Você responde:

Quantos clientes são afetados?

Silêncio.

Qual comportamento esperamos mudar?

Silêncio.

Que evidência temos?

Um cliente pediu.

Talvez a feature continue prioritária. Mas agora sabemos o tipo de evidência que sustenta a urgência. Isso é muito mais útil que simplesmente trocar “prioridade alta” por “P0”.

Impacto × esforço continua sendo útil

Nem toda decisão precisa virar RICE. A matriz de impacto × esforço é muito mais simples. Você coloca iniciativas em quatro áreas: alto impacto / baixo esforço, alto impacto / alto esforço, baixo impacto / baixo esforço, baixo impacto / alto esforço.

Ela perde informação que o RICE explicita: não representa Reach separadamente, não representa Confidence separadamente. Mas isso não significa que seja sempre “pior”. Se existem quatro pequenos itens relativamente comparáveis e o time precisa decidir o que cabe na próxima semana, uma matriz pode ser suficiente. Criar um modelo detalhado tem custo.

Uma regra mais útil seria: use o nível de formalidade proporcional ao custo da decisão. Quatro ajustes pequenos? Conversa e matriz podem bastar. Quinze iniciativas disputando um trimestre inteiro? RICE pode ajudar. Decisão de investimento de milhões? RICE sozinho provavelmente é pouco.

Frameworks funcionam melhor quando os itens são comparáveis

Existe outro problema escondido. Imagine comparar numa única planilha: mudar texto de um botão, refazer onboarding, migrar infraestrutura de pagamentos, lançar um novo produto, corrigir dívida técnica, entrar em outro país. Todos podem receber Reach, Impact, Confidence e Effort. Isso não significa que deveriam estar na mesma competição. Quando o nível de decisão muda demais, o score perde significado.

É parecido com tentar comparar:

comprar uma cadeira nova

e

mudar de escritório

usando apenas preço e conforto. As duas decisões não estão no mesmo nível estratégico. Antes de aplicar o framework, organize o backlog por tipo de decisão.

Segurança, fraude e compliance não cabem bem num único Impact

Esse problema aparece especialmente em fintech. Imagine remover uma etapa de verificação. Pode melhorar conversão, tempo de conclusão e abandono. Ao mesmo tempo, pode piorar fraude, risco e compliance. Qual é o Impact? 2? 3? 0,5? Um único número tenta colapsar efeitos que se movem em direções diferentes.

Nesses casos, vale declarar guardrails. Por exemplo:

queremos aumentar conclusão sem elevar fraude acima de X.

Agora existe um limite. Uma solução que aumenta muito conversão e ultrapassa o risco aceitável não deveria vencer apenas porque o impacto agregado parece alto. Em produtos financeiros, às vezes a pergunta importante não é:

qual iniciativa gera mais impacto?

É:

qual combinação de resultado e risco estamos dispostos a aceitar?

Isso precisa existir antes do score.

Cliente grande precisa entrar como estratégia, não como truque na pontuação

Essa situação merece tratamento próprio em SaaS B2B. Um cliente responsável por grande parte da receita pede uma feature que beneficia pouca gente. No RICE, Reach será baixo. Talvez o score fique péssimo. Construir mesmo assim pode ser totalmente racional.

O erro seria manipular Reach ou Impact até a planilha produzir o resultado que a empresa já decidiu comercialmente. Melhor registrar:

RICE baixo. Priorizado por risco de renovação do contrato X.

Agora qualquer pessoa consegue entender a decisão. Não foi “o modelo mostrou que essa é a melhor feature para o produto”. Foi “estamos conscientemente usando capacidade para proteger uma relação comercial estratégica”. Isso é muito mais saudável. Framework não deveria servir para esconder exceções. Deveria torná-las visíveis.

“Concorrente tem” é evidência fraca até existir um problema

Outra fonte clássica do backlog:

o concorrente lançou.

Isso pode ser relevante. Mas ainda não descreve o problema. Talvez o concorrente tenha outra base, outro modelo de negócio, outro ICP, outra estratégia — ou simplesmente tenha tomado uma decisão ruim. A pergunta seguinte deveria ser: o que essa funcionalidade permite fazer que hoje impede nossos clientes de atingir algum resultado?

Se existe uma resposta clara, ótimo. Agora temos problema. Se não existe, talvez tenhamos apenas ansiedade competitiva. Roadmap orientado por screenshot de concorrente envelhece muito rápido.

“Cliente pediu” também não é problema ainda

Cliente costuma pedir solução. “Preciso exportar em XLSX.” “Quero dark mode.” “Vocês precisam ter subcontas.” “Adicionem um campo personalizado.” O pedido é evidência de alguma necessidade. Mas ainda vale perguntar:

o que você está tentando fazer quando precisa disso?

Talvez “exportar XLSX” signifique “preciso mandar os dados para o contador”. Talvez exista outra solução. Talvez cinco pedidos diferentes sejam manifestações do mesmo problema. Reescrever backlog em termos de problema pode reduzir bastante a lista antes de qualquer priorização.

Três perguntas que eu faria antes de abrir a planilha

O que acontece se não fizermos isso pelos próximos seis meses?

Essa pergunta separa urgência real de urgência verbal. Respostas concretas: ficaremos fora da nova regra, perderemos o contrato, custo operacional continuará crescendo R$ 40 mil por mês, infraestrutura atinge o limite estimado em novembro. Respostas menos concretas: seria bom ter, concorrente já tem, vendas acha importante. As duas categorias podem entrar no roadmap. Não precisam receber o mesmo senso de urgência.

Que problema estamos tentando resolver?

Se o card só contém a solução, volte uma casa. Talvez dois itens sejam o mesmo problema.

Que evidência faria esta prioridade mudar?

Essa pergunta testa se existe decisão ou convicção. Se nenhuma informação possível mudaria a posição do item, talvez ele não esteja sendo priorizado. Já foi decidido. Nesse caso, seja explícito.

Priorizar também significa dizer não agora

Backlog congestionado não é resolvido apenas escolhendo os dez primeiros. O item número 74 continua existindo. E daqui a duas semanas alguém perguntará novamente por ele. Se a resposta for “ficou para depois”, a discussão recomeça inteira. É melhor registrar:

Não priorizado neste ciclo. Afeta aproximadamente 4% da base, possui alternativa manual e exigiria cerca de dois meses de desenvolvimento.

Agora existe contexto. E, principalmente: o que faria a decisão mudar?

Se atingir 15% da base.

Se chamados ultrapassarem 200/mês.

Se entrar no requisito de três oportunidades enterprise.

Se a operação manual ultrapassar X horas por semana.

Isso transforma “não” em “não nessas condições”. A próxima conversa pode começar pela informação nova, não pela repetição do pedido.

Nem todo item precisa permanecer no backlog para sempre

Essa é outra fonte de congestionamento. Um pedido entrou há dois anos, nunca chegou perto do topo, nenhum cliente voltou a mencionar, a estratégia mudou. Mesmo assim continua lá porque “vai que um dia”.

Backlog não precisa ser arquivo histórico de toda ideia que alguém já teve. Feedback pode ter seu próprio repositório. Ideias podem ter outro lugar. O backlog deveria representar trabalho suficientemente relevante para ainda disputar capacidade. Se um item não possui evidência, responsável, gatilho, relação com objetivo, nem perspectiva de ser considerado, talvez mantê-lo na fila apenas produza falsa sensação de possibilidade. Apagar também é priorizar.

Um backlog saudável não é necessariamente curto

Pode existir um backlog grande e útil. O problema não é a quantidade absoluta. É ninguém entender por que algo está onde está. Eu gostaria que uma pessoa conseguisse abrir um item longe do topo e descobrir qual problema representa, para quem, que evidência existe, por que não está sendo feito agora e o que poderia mudar essa decisão. Quando isso existe, o backlog deixa de ser uma caixa de pedidos. Vira memória das decisões de produto.

A melhor técnica é a que melhora a conversa

RICE, impacto × esforço, WSJF, MoSCoW, ICE. Você pode trocar o framework e continuar com o mesmo problema se cada demanda entra por uma regra diferente e exceções são escondidas dentro da pontuação. A técnica não elimina julgamento. Ela organiza julgamento.

Para um time pequeno, eu começaria com algo simples:

1. separar obrigação de iniciativa opcional;

2. escrever problema antes da solução;

3. definir o objetivo que está sendo priorizado;

4. estimar alcance;

5. declarar evidência e incerteza;

6. estimar custo;

7. registrar por que algo ficou de fora.

Depois, se RICE ajudar a comparar o conjunto, use. O importante não é conseguir dizer:

esse card tem score 1.742.

É conseguir dizer:

escolhemos isso porque afeta esta parte da base, esperamos este resultado, temos esta evidência e estamos conscientemente abrindo mão daquilo.

Esse é o tipo de prioridade que sobrevive quando alguém pergunta “por quê?” três meses depois.

E existe uma ligação direta com roadmap: priorizar backlog sem saber quais problemas a empresa escolheu enfrentar produz uma lista bem ordenada e uma estratégia confusa. No artigo Como criar um roadmap de produto que sobrevive ao trimestre, a discussão continua justamente nesse nível.

Fontes

Intercom. RICE: Simple prioritization for product managers, Sean McBride, publicado em 5 de janeiro de 2018. Apresenta o sistema criado pela equipe da Intercom para comparar iniciativas utilizando Reach, Impact, Confidence e Effort.

Intercom. No framework original, Reach é estimado em pessoas ou eventos dentro de um período comum; Impact utiliza a escala 3, 2, 1, 0,5 e 0,25; Confidence utiliza como referências 100%, 80% e 50%; e Effort é estimado em pessoa-mês. A fórmula apresentada é (Reach × Impact × Confidence) ÷ Effort.

O RICE é utilizado neste artigo como ferramenta de apoio à decisão, não como modelo capaz de representar sozinho restrições regulatórias, riscos de segurança, compromissos contratuais ou escolhas estratégicas.