Na maioria das equipes de produto, o backlog é o lugar onde a urgência vai morrer. Tudo o que entra nele era urgente quando foi adicionado — uma reclamação de cliente, um pedido de vendas, um recurso de concorrente, uma ideia interna. Seis meses depois, está tudo lá, tudo ainda parece urgente e ninguém sabe ao certo o que fazer primeiro.
O problema não é falta de ferramentas. Há dezenas de frameworks de priorização: RICE, MoSCoW, Kano, ICE, pontuação ponderada. O problema é que a maioria exige uma falsa precisão — atribuir números a incógnitas — que passa a sensação de rigor, mas na prática só lava o feeling com uma planilha.
O que realmente funciona é mais simples: duas dimensões, avaliadas com honestidade, e a disciplina de agir com base no resultado.
A priorização se resume a duas perguntas. Primeira: quanto isto melhora o resultado que nos importa? (Impacto.) Segunda: quanto vai custar entregar? (Esforço.) Todo o resto é um refinamento dessas duas ou uma distração.
Às vezes se acrescenta a confiança como terceira dimensão — "quanta certeza temos do impacto?" — e vale ter isso em mente. Mas, na prática, a maioria das equipes sabe quando está chutando. A disciplina está em rotular o chute com honestidade, e não em dar nota de 1 a 5 e jogar numa fórmula.
O difícil não é entender a matriz — é ser honesto ao preenchê-la. Toda equipe tem funcionalidades que quer construir e que pertencem aos "Ralos de tempo", mas que vivem sendo reclassificadas como "Grandes apostas". O framework só funciona se a equipe for honesta quanto ao impacto.
O impacto é a dimensão mais difícil de avaliar, porque muitas vezes exige prever o futuro. A tentação é dar uma nota numérica e se sentir científico. Uma abordagem melhor é qualitativa, mas estruturada.
Faça três perguntas para cada funcionalidade em análise:
As equipes subestimam o esforço de forma sistemática. Isso está bem documentado — tem relação com a falácia do planejamento e o viés de otimismo — e é ainda mais evidente em funcionalidades que mexem em vários sistemas, exigem coordenação entre equipes ou envolvem capacidades que a equipe nunca construiu.
Duas práticas ajudam. Primeiro, consulte sempre a engenharia antes de dar a nota de esforço, e não depois. Gerentes de produto que estimam o esforço sozinhos quase sempre subestimam. Segundo, use o conceito de "incógnitas desconhecidas" (unknown unknowns) como multiplicador explícito de esforço. Toda funcionalidade que toque uma área nova do código, uma API de terceiros ou um fluxo de usuário não testado recentemente merece uma nota de esforço 1,5 vez maior do que o trabalho aparente sugere.
Boa parte da urgência de um backlog de produto não é urgência de verdade — é recência. Um cliente reclamou na semana passada, então o pedido dele parece premente. Um concorrente lançou algo no mês passado, então igualar parece crítico. Mas recência não é o mesmo que importância, e reagir à recência é uma das formas mais certeiras de deixar escapar o trabalho realmente importante.
Um teste prático: pergunte-se se você ainda acharia isso urgente caso tivesse ouvido falar seis meses atrás, e não na semana passada. Se a resposta for não, é viés de recência em ação, não prioridade estratégica. Registre, avalie com calma na matriz e resista à vontade de furar a fila só porque o assunto é recente.
A matriz nem sempre dá uma resposta limpa. Dois itens caem no mesmo quadrante, com notas parecidas, e você ainda precisa escolher um. Nesses casos, dois critérios de desempate são úteis: alinhamento estratégico (qual deles aproxima mais você de onde quer estar em 18 meses?) e reversibilidade (qual é mais difícil de desfazer se estiver errado?). Prefira o item mais alinhado à estratégia e mais reversível.