Priorizar features é uma daquelas responsabilidades que todo PM carrega, e que quase sempre vem acompanhada de pressão, ruído e política. O backlog cresce mais rápido do que a capacidade do time, clientes pedem “só mais uma coisinha”, vendas precisa de munição para ontem, suporte está pegando fogo, e a liderança quer “impacto” (sem sempre definir o que é impacto).
No fim, priorização não é sobre escolher o que fazer. É sobre escolher o que não fazer, com clareza, consistência e coragem.
A boa notícia: existem frameworks que ajudam de verdade. A má: nenhum framework substitui contexto, estratégia e conversas difíceis. O que funciona é um sistema: critérios claros + dados suficientes + rituais + comunicação.
O problema real da priorização (e por que a maioria falha)
Antes de falar de frameworks, vale encarar as causas mais comuns de priorização ruim:
Estratégia fraca ou inexistente: se tudo é importante, nada é.
Critérios invisíveis: o time acha que é “no grito”, mesmo quando não é.
Métricas desconectadas: prioriza-se output (entregas) em vez de outcome (resultados).
Viés do stakeholder mais influente: HIPPO (Highest Paid Person’s Opinion) disfarçado de “alinhamento”.
Backlog como cemitério: nada morre, só acumula.
Se você só “aplica um framework” em cima disso, vira planilha bonita com decisão ruim.
Conceitos fundamentais para priorizar bem
O que é “prioridade”, na prática
Prioridade é a combinação de três coisas:
Valor: que benefício real isso gera?
Custo/Esforço: o que isso consome do time?
Timing/Risco: por que agora (ou por que não agora)?
Se você não explicita esses três pontos, você está só organizando opinião.
Outcome > Output
Output: “lançamos a feature X”
Outcome: “reduzimos churn em 1,2 p.p.” ou “aumentamos ativação em 8%”
Framework bom é o que força a conversa sobre outcome, mesmo quando não dá para medir com precisão.
Frameworks que realmente funcionam (e quando usar cada um)
1) RICE (Reach, Impact, Confidence, Effort)
Quando funciona melhor: produto com muitos bets pequenos/médios, necessidade de ordenação objetiva e rápida.
Fórmula:RICE = (Reach × Impact × Confidence) / Effort
Reach (alcance): quantas pessoas serão afetadas em um período
Impact: intensidade do benefício (ex.: 0,25 / 0,5 / 1 / 2 / 3)
Confidence: quão confiável é a estimativa (50% / 80% / 100%)
Effort: esforço do time (pessoas-semana, por exemplo)
Exemplo prático (bem pé no chão):
Feature A: melhorar onboarding
Reach: 20k usuários/mês
Impact: 2 (alto)
Confidence: 0,8
Effort: 8
RICE = (20000×2×0,8)/8 = 4000
Boas práticas no RICE
Use faixas (não números super precisos).
Padronize “Impact” para não virar farra.
Confidence é o antídoto para “achismo com Excel”.
Armadilha comum
Inflar Reach e Impact para “ganhar”. Isso é sinal de governança fraca, não de framework fraco.
2) ICE (Impact, Confidence, Ease)
Quando funciona melhor: quando você não tem dados confiáveis de alcance, mas precisa decidir rápido.
Impact (alto/médio/baixo)
Confidence
Ease (quão fácil é implementar)
Ponto forte: agilidade.
Ponto fraco: pode favorecer “coisas fáceis” e matar bets estratégicos.
Dica prática: use ICE para triagem inicial e depois refine com RICE/WSJF.
3) WSJF (Weighted Shortest Job First), o queridinho de quem precisa falar com negócio
Quando funciona melhor: portfólio com iniciativas maiores, disputas entre times, dependências, contexto de SAFe/lean portfolio.
Fórmula:WSJF = Cost of Delay / Job Size
Cost of Delay normalmente inclui:
Valor para o usuário/negócio
Urgência/time criticality
Redução de risco / oportunidade
Por que funciona: ele obriga a discussão do “custo de esperar”.
Exemplo prático:
Iniciativa B reduz incidentes críticos e evita multa contratual.
Se atrasar 2 meses, o custo é real e grande.
Mesmo sendo “chata” e complexa, WSJF tende a puxar para cima.
Armadilha comum
“Job Size” vira chute de horas e gera falsa precisão. Melhor trabalhar com tamanhos relativos (S/M/L/XL com pontos).
4) Kano (Básico, Performance, Encantamento)
Quando funciona melhor: produto com foco em experiência e diferenciação, ou quando você quer entender o tipo de valor (não só o tamanho).
Básico: se não tiver, gera frustração.
Performance: quanto mais, melhor (linear).
Encantamento: surpresa positiva, diferencia.
Como usar de forma prática (sem virar workshop infinito):
Classifique as demandas do backlog em 30–60 min com time + áreas de contato com cliente.
Garanta um mix: não dá para só “encantar” com a casa pegando fogo.
Armadilha comum
Stakeholder chama tudo de “encantamento” para furar fila.
5) MoSCoW (Must, Should, Could, Won’t)
Quando funciona melhor: planejamento de release, escopo fechado, projetos com data (migração, compliance, contratos).
Must: sem isso, não entrega o objetivo
Should: importante, mas dá para viver sem
Could: se sobrar tempo
Won’t (por agora): fora do escopo
O poder está no “Won’t”
A maioria das empresas usa MoSCoW sem o W — e aí é só lista de desejos.
Armadilha comum
“Must” vira 80% do escopo. A regra prática: Must costuma caber em 50–60% da capacidade.
6) Opportunity Scoring (Jobs to Be Done)
Quando funciona melhor: você quer priorizar baseado em dor/necessidade, especialmente discovery forte.
A lógica:
Quão importante é a necessidade?
Quão bem ela é atendida hoje?
Alta importância + baixa satisfação = oportunidade grande.
Armadilha comum
Medir satisfação sem recorte (segmento, persona, momento). Resultado vira média mentirosa.
Cenários práticos: qual framework escolher
Cenário A: “Tenho 200 itens no backlog e preciso organizar”
Comece com ICE (triagem rápida)
Depois aplique RICE nos top 20–30
Cenário B: “Disputa política entre áreas e iniciativas grandes”
Use WSJF para trazer conversa para custo de atraso
Cenário C: “Quero equilibrar evolução do produto e diferencial”
Use Kano para garantir mix (básico/performance/encantamento)
Cenário D: “Tenho release com data e escopo crítico”
Use MoSCoW com W explícito e publicado
Boas práticas (que valem mais do que o framework)
1) Comece pela estratégia: 3–5 apostas claras
Exemplo de apostas trimestrais:
Reduzir churn em SMB
Aumentar ativação no primeiro valor
Reduzir custo operacional em suporte
Framework sem aposta vira “priorização por features”.
2) Crie critérios públicos e repetíveis
Se a empresa inteira entende os critérios, a discussão sobe de nível.
3) Faça “pré-priorização” com dados mínimos
Antes do ritual de priorização, entre com:
hipótese de impacto
segmento afetado
dependências
esforço relativo
evidência (qualitativa/quantitativa)
4) Tenha um ritual fixo
Ex.: quinzenal ou mensal:
revisar top prioridades
matar itens obsoletos
revalidar apostas
5) Comunique decisão + motivo + trade-off
“Vamos fazer X porque… e isso significa não fazer Y agora.”
Erros comuns (e como evitar)
Backlog infinito → faça “higiene”: arquive, mate, agrupe por outcome
Ranking 1 a 200 → trabalhe com “Now / Next / Later”
Roadmap como promessa → trate como intenção baseada em hipóteses
Priorizar só por receita → você vira refém de curto prazo (e o produto cobra depois)
Esforço estimado sem time → esforço é do time, não do PM (alinhamento rápido resolve)
Checklist prático de priorização (para colar na parede)
Quais são as apostas estratégicas do período?
Cada item tem problema, persona/segmento e resultado esperado?
Existe pelo menos uma evidência (dados, feedback, incidente, contrato)?
Esforço está em tamanho relativo (S/M/L) ou capacidade realista?
Temos critério claro de valor, custo e timing?
A decisão inclui o que não será feito (Won’t)?
Existe plano de medição pós-lançamento?
A comunicação para stakeholders explicita trade-offs?
Conclusão: o que diferencia PM maduro na priorização
Framework é ferramenta. PM sênior usa ferramenta, mas ganha o jogo com sistema.
O que constrói autoridade de verdade não é dizer “usei RICE”, e sim:
conectar decisões a uma tese estratégica,
mostrar critérios claros,
negociar trade-offs com transparência,
medir o que importava depois.
Se eu tivesse que te deixar com uma recomendação final, seria:
Escolha 1 framework principal (RICE ou WSJF), padronize critérios, rode em ciclos curtos e publique os trade-offs.
Quando a empresa confia no processo, a política diminui e, a conversa volta para o que interessa: impacto.