Priorização é a função central de um PM. Não é a mais glamourosa, mas é a que mais define o resultado do produto. A maioria dos problemas de produto — times ocupados construindo a coisa errada, backlogs crescendo infinitamente, sprints que entregam sem mover métricas — tem raiz em priorização ruim.

E a maioria dos frameworks de priorização funciona no papel e trava no contato com a realidade.

O que os frameworks resolvem (e o que não resolvem)

RICE (Reach, Impact, Confidence, Effort), ICE (Impact, Confidence, Ease) e similares servem para um propósito específico: forçar uma conversa explícita sobre hipóteses. Quando você pede para um stakeholder estimar "quantos usuários esse item do backlog vai atingir", você está pedindo que ele articule uma hipótese que até então estava implícita.

O número que sai desse processo raramente é preciso. Isso não é problema. A utilidade do framework está na conversa, não na planilha.

Quando RICE falha

RICE falha quando os números são inventados para justificar uma decisão que já foi tomada. Se todo item do backlog prioritário de um stakeholder misteriosamente tem score alto, você não está usando RICE para priorizar — está usando para criar aparência de processo.

Falha também quando o que você está comparando tem dimensões incomparáveis. Reduzir churn de 5% e adicionar uma nova vertical de produto são itens tão diferentes em natureza que colocar ambos numa mesma planilha de RICE cria uma falsa equivalência.

MoSCoW na prática

MoSCoW (Must have, Should have, Could have, Won't have) é útil quando você precisa alinhar rapidamente com stakeholders sobre escopo. O "Won't have" é a parte mais valiosa e mais frequentemente omitida: dizer explicitamente o que não vai entrar nessa versão evita escopo crescendo silenciosamente durante o desenvolvimento.

A armadilha é que "Must have" tende a crescer sem controle. Se tudo é must, nada é. Quando isso acontece, a lista de must have precisa de um critério de corte mais rigoroso: se isso não estiver no produto no dia do lançamento, o lançamento não faz sentido. Apenas isso é must.

Como priorizar quando os dados são incompletos

Você raramente vai ter dados perfeitos para priorizar. O erro é paralisar esperando por mais dados, ou inventar certeza onde não existe.

A abordagem honesta é priorizar baseado na melhor hipótese disponível, tornar a hipótese explícita, e definir como você vai validar se estava certo. Para saber quais métricas de produto usar como referência nessas hipóteses — retenção D30, ativação, churn — veja o guia completo sobre métricas. "Apostamos que essa funcionalidade vai aumentar a retenção D30 porque usuários que completam esse passo retornam a uma taxa 30% maior. Vamos medir isso nas próximas quatro semanas." Isso é priorização baseada em evidência, mesmo com incerteza.

A diferença entre priorização e negociação

Parte do trabalho de priorização é, na prática, negociação com stakeholders. CEO quer uma funcionalidade para um cliente grande. Vendas quer algo para fechar um deal. Marketing tem uma campanha planejada para daqui a seis semanas.

Nessas situações, o critério de priorização raramente resolve sozinho. O que resolve é transparência sobre custo de oportunidade: "se colocarmos esse item à frente, estamos adiando esses outros três. Esses são os impactos esperados de cada um. Qual é a decisão?"

Transformar a conversa de "quem tem mais poder" para "qual é a melhor decisão dado o que sabemos" é a habilidade política central de um PM.

Backlog como ferramenta de pensamento

Backlog não é lista de espera. É uma hipótese sobre o que pode ser construído. Itens que ficam no backlog por mais de três meses sem nunca serem priorizados provavelmente não vão ser priorizados. O trabalho honesto é removê-los ou ser explícito sobre por que continuam lá.

Backlog limpo é sinal de PM que pensa sobre priorização regularmente, não que espera a sprint planning para fazer esse trabalho. As melhores equipes que conheço fazem refinamento contínuo — não como ritual semanal obrigatório, mas como parte do trabalho de entender o que precisa ser construído. Os melhores backlogs são organizados em torno de objetivos claros — e OKRs são uma ferramenta útil para garantir que o que está no topo do backlog está conectado ao que realmente importa no trimestre. Para entender como usar OKRs para guiar priorização sem virar burocracia, veja o guia sobre OKRs para product managers. E para comunicar esse backlog priorizado de forma transparente para stakeholders, veja o artigo sobre como construir um roadmap de produto.

Uma pergunta que ajuda a destravar

Quando você está preso num backlog com muitos candidatos e pouca clareza, tente essa pergunta: "se eu pudesse construir só uma coisa nos próximos três meses, qual teria o maior impacto no problema que estou tentando resolver?" A restrição artificial forçada por essa pergunta costuma revelar o que importa de verdade.

Na comunidade mágica, temos uma trilha inteira sobre decisões de produto — onde PMs discutem casos reais de priorização e o que funcionou (e o que não funcionou).