Priorização — RICE, MoSCoW e Value vs. Effort

Nível: Júnior | Duração estimada de leitura: 19 minutos | Categoria: Trilha Júnior — Módulo 5

Introdução

Todo Product Owner enfrenta o mesmo problema todo dia: tem mais coisa para fazer do que tempo e capacidade para fazer. O backlog nunca para de crescer. Stakeholders nunca param de pedir. O time nunca tem capacidade infinita.

A questão não é se você vai precisar priorizar. É como vai fazer isso.

Existe uma forma muito comum de priorizar que a maioria dos POs usa sem perceber: a intuição. Você sente que aquela feature é mais importante do que a outra, que aquele bug precisa ser resolvido antes daquele ajuste, que a demanda do comercial pesa mais do que a do suporte. E vai colocando as coisas no backlog na ordem que parece certa no momento.

O problema da intuição não é que ela esteja errada — às vezes está certa. O problema é que ela é invisível. Quando um stakeholder questiona por que o item dele está abaixo do item de outro, você não tem uma resposta que ele possa entender e avaliar. Tudo que você tem é "eu acho que é assim". E "eu acho" raramente sobrevive a uma reunião com um diretor determinado.

Frameworks de priorização não são fórmulas mágicas que tiram a dificuldade da decisão. São linguagens compartilhadas que tornam o raciocínio por trás da prioridade visível, questionável e melhorável. Com um framework, você pode mostrar seu trabalho — e convidar os stakeholders a corrigirem os dados, não a contestarem o seu julgamento.

Neste módulo você vai aprender três dos frameworks mais usados no mercado, como aplicar cada um na prática, quando usar qual e como usá-los para ter conversas de prioridade mais objetivas com seu time e seus stakeholders.

Por que priorização é difícil mesmo com frameworks

Antes de aprender os frameworks, é importante entender o que eles não resolvem — para que você não se decepcione quando a teoria encontrar a realidade.

Frameworks dependem de dados que nem sempre existem

O RICE, por exemplo, usa números para calcular uma pontuação. Mas de onde vêm esses números? Você precisa estimar quantos usuários serão impactados, com que intensidade, com qual confiança. No começo da carreira, e especialmente em produtos novos, muitos desses números são suposições — não dados sólidos. E suposições embaladas em fórmulas podem dar uma falsa sensação de rigor.

Priorização tem componentes políticos que nenhum framework captura

Às vezes um item precisa ser priorizado porque o cliente principal da empresa pediu, porque o CEO quer mostrar em uma conferência ou porque existe um prazo regulatório inegociável. Nenhum framework de priorização vai dizer isso — você precisa saber quando essas forças existem e como incorporá-las de forma transparente.

Frameworks são ferramentas de apoio, não substitutos do julgamento

O objetivo dos frameworks é estruturar o raciocínio, não eliminar a necessidade de pensar. Você ainda vai precisar fazer escolhas, exercer julgamento e defender posições. O framework torna esse processo mais transparente e mais fácil de comunicar — não mais fácil de fazer.

Com isso claro, vamos aos frameworks.

MoSCoW: a forma mais simples de classificar o que importa

O MoSCoW é o framework de priorização mais acessível e um dos mais usados no mercado. O nome é uma sigla formada pelas iniciais das quatro categorias em inglês, com letras "o" adicionadas para formar uma palavra pronunciável. Em inglês: Must have, Should have, Could have e Won't have — em português: Deve ter, Deveria ter, Poderia ter e Não vai ter agora.

Vamos entender cada categoria com profundidade.

Must Have — Deve Ter

São os itens absolutamente essenciais para que o produto ou a entrega tenha valor. Sem eles, a sprint, o release ou o produto não funciona de forma aceitável. Se um Must Have não for entregue, o resultado é considerado um fracasso.

A pergunta que define um Must Have é: "Se não entregarmos isso, o que acontece?" Se a resposta for "o produto não funciona", "o cliente cancela", "existe risco legal ou regulatório", "perdemos receita imediata significativa" — é Must Have.

Exemplo prático: imagine que seu time está lançando um portal de autoatendimento para clientes solicitarem devoluções. A funcionalidade de "selecionar os itens do pedido para devolver" é Must Have — sem ela, o fluxo de devolução não existe. O botão de "salvar como favorito" para o endereço de coleta é conveniente, mas claramente não é Must Have para o lançamento inicial.

Cuidado com a inflação de Must Haves. Este é o erro mais comum ao usar MoSCoW. Stakeholders tendem a classificar tudo como Must Have porque acreditam que isso aumenta as chances de entrega. Se metade do backlog é Must Have, o framework perdeu o sentido. Uma regra prática: Must Haves devem representar no máximo 60% da capacidade de uma sprint ou release. Se passar disso, algo está errado na classificação.

Should Have — Deveria Ter

São itens importantes que agregam valor significativo, mas que podem ser adiados sem comprometer a funcionalidade central. Se um Should Have não for entregue na sprint ou release atual, é inconveniente — mas não é uma falha.

A pergunta que define um Should Have é: "Se não entregarmos isso agora, o que acontece?" Se a resposta for "vai gerar reclamação de usuário mas o produto ainda funciona", "vai aumentar um pouco o esforço manual", "é uma melhoria relevante que não é urgente" — é Should Have.

Exemplo prático: no mesmo portal de devoluções, a funcionalidade de notificação por email ao cliente sobre o status da devolução é Should Have. O cliente vai conseguir solicitar a devolução sem ela, mas a experiência vai ser pior — ele vai precisar acessar o portal para verificar o status manualmente.

Could Have — Poderia Ter

São itens que agregariam valor mas têm baixa urgência e baixo impacto relativo. Entram na sprint apenas se sobrar capacidade depois que os Must Haves e Should Haves forem entregues.

A pergunta que define um Could Have é: "Se não entregarmos isso neste ciclo, alguém vai reclamar ou perceber?" Se a resposta for "talvez, mas não vai ser prioritário para ninguém" — é Could Have.

Exemplo prático: no portal de devoluções, a opção de o cliente escolher entre crédito na conta ou estorno no cartão como forma de reembolso poderia ser um Could Have em um primeiro release — especialmente se a empresa já tem uma política padrão definida.

Won't Have (this time) — Não Vai Ter Agora

Esta é a categoria mais subutilizada e, ao mesmo tempo, a mais poderosa do MoSCoW. O Won't Have não significa que o item nunca vai ser feito — significa que está explicitamente fora do escopo deste ciclo ou release.

Por que isso é poderoso? Porque ao tornar explícito o que está fora do escopo, você reduz ambiguidade, alinha expectativas e evita que o time passe tempo discutindo itens que não vão ser feitos agora. Stakeholders que sabem que algo está no Won't Have não ficam esperando — eles sabem que precisam planejar sem aquela entrega por enquanto.

Como usar o MoSCoW na prática

Reúna o time e os stakeholders relevantes. Liste todos os itens em avaliação. Para cada item, faça a pergunta de cada categoria em ordem — começando pelo Must Have e descendo. O item "cai" na primeira categoria cujos critérios ele não atende.

Por exemplo: "Este item pode ser lançado sem isso?" Se não — Must Have. "Se pode, isso é importante o suficiente para que precisemos neste ciclo?" Se sim — Should Have. "Se não for prioritário agora, ainda queremos incluir se sobrar capacidade?" Se sim — Could Have. Se não — Won't Have.

O resultado é uma classificação compartilhada pelo grupo — não uma decisão unilateral do PO. Isso é o que torna o MoSCoW especialmente útil para alinhar expectativas com múltiplos stakeholders ao mesmo tempo.

RICE: quando você precisa de mais precisão

O RICE é um framework de pontuação criado pela equipe de produto da Intercom — uma empresa de software de comunicação com clientes — para ajudar a comparar itens do backlog de forma mais objetiva. O nome é uma sigla em inglês para quatro fatores: Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço).

A fórmula do RICE é:

Pontuação RICE = (Alcance × Impacto × Confiança) ÷ Esforço

Itens com pontuação mais alta são priorizados. Vamos entender cada componente em profundidade, porque a qualidade do RICE depende completamente da qualidade das estimativas de cada fator.

R — Reach (Alcance)

O alcance responde à pergunta: quantos usuários ou clientes este item vai impactar em um período de tempo definido?

A unidade de medida deve ser consistente para todos os itens que você está comparando. Pode ser "usuários por mês", "transações por trimestre", "clientes afetados por semana" — o que fizer mais sentido para o seu produto. O importante é usar a mesma unidade para todos os itens.

Exemplo: uma feature que vai aparecer no fluxo principal do produto, que todos os 5.000 usuários ativos por mês passam por ele, tem Alcance = 5.000. Uma feature que só aparece para clientes do plano premium, que são 800 usuários, tem Alcance = 800.

Como estimar: use dados de analytics. Quantos usuários passam por aquela tela ou aquele fluxo por mês? Se não há dados diretos, use proxies — quantos usuários têm aquela característica específica, quantas transações daquele tipo acontecem por período.

I — Impact (Impacto)

O impacto responde à pergunta: quando um usuário encontra esta feature, quanto ela melhora a experiência ou aumenta a conversão para o objetivo que estamos perseguindo?

O RICE usa uma escala pré-definida para o impacto, o que ajuda a manter a comparação consistente entre itens diferentes:

• 3 pontos: Impacto massivo — vai transformar drasticamente a experiência do usuário ou a conversão
• 2 pontos: Impacto alto — vai melhorar significativamente a experiência ou a conversão
• 1 ponto: Impacto médio — vai melhorar de forma perceptível mas não transformadora
• 0,5 pontos: Impacto baixo — melhoria pequena, perceptível apenas por usuários atentos
• 0,25 pontos: Impacto mínimo — praticamente imperceptível para a maioria dos usuários

Exemplo: uma feature que elimina um passo de fricção que 40% dos usuários abandona no checkout tem Impacto = 3. Uma mudança na ordem dos campos de um formulário que já funciona bem tem Impacto = 0,25.

Como estimar: esta é a estimativa mais subjetiva do RICE, e por isso é a mais importante de defender com dados. Comportamento do usuário (onde ele abandona, onde ele trava), entrevistas de discovery e testes de usabilidade são as melhores fontes para calibrar o impacto.

C — Confidence (Confiança)

A confiança responde à pergunta: quão seguros estamos de que as estimativas de alcance e impacto estão corretas?

O RICE usa uma escala percentual para a confiança:

• 100%: Alta confiança — temos dados sólidos que sustentam as estimativas
• 80%: Confiança média — temos algumas evidências, mas há incerteza relevante
• 50%: Baixa confiança — é principalmente uma suposição fundamentada
• Abaixo de 50%: Você provavelmente não tem informação suficiente para usar o RICE neste item — considere fazer mais discovery antes

A confiança funciona como um "desconto" sobre as estimativas de alcance e impacto. Um item com alcance alto e impacto alto mas confiança de 50% vai ter uma pontuação 50% menor do que um item equivalente com confiança de 100% — e isso é correto, porque o primeiro é muito mais arriscado.

Exemplo: uma feature para um segmento de usuários que você entrevistou 10 vezes e cujos padrões de comportamento você tem dados sólidos tem Confiança = 100%. Uma feature baseada em uma sugestão de stakeholder sem validação de usuário tem Confiança = 50% ou menos.

E — Effort (Esforço)

O esforço responde à pergunta: quantas "pessoas-mês" (ou pessoas-semana, dependendo do seu contexto) serão necessárias para entregar este item?

O esforço inclui o trabalho de todos os envolvidos — não apenas o desenvolvimento, mas também design, QA, documentação, configuração de ambiente. Uma feature que parece simples mas exige mudança em múltiplos sistemas pode ter esforço muito maior do que aparenta.

Exemplo: uma feature que requer 2 semanas de um dev, 3 dias de um designer e 1 semana de QA tem esforço de aproximadamente 1 pessoa-mês (considerando que uma pessoa-mês tem cerca de 20 dias úteis: 10 + 3 + 5 = 18 dias, aproximadamente 1 pessoa-mês).

O esforço é o divisor da fórmula — o que significa que quanto maior o esforço, menor a pontuação. Itens de alto valor com baixo esforço (os chamados "quick wins") naturalmente recebem pontuações altas no RICE.

Calculando o RICE na prática com um exemplo completo

Imagine que você tem dois itens no backlog:

Item A: Filtro de pedidos por status no aplicativo

• Alcance: 4.000 usuários por mês (quase todos os usuários que acessam "Meus Pedidos")
• Impacto: 2 (impacto alto — elimina uma dor significativa identificada em entrevistas)
• Confiança: 80% (temos dados de analytics e entrevistas, mas não fizemos teste de protótipo)
• Esforço: 0,5 pessoa-mês (feature relativamente simples)

Cálculo: (4.000 × 2 × 0,80) ÷ 0,5 = 6.400 ÷ 0,5 = 12.800 pontos

Item B: Relatório exportável de histórico de compras em PDF

• Alcance: 800 usuários por mês (apenas usuários do plano premium)
• Impacto: 1 (impacto médio — útil, mas não resolve uma dor crítica)
• Confiança: 50% (baseado em pedido de um stakeholder, sem validação de usuário)
• Esforço: 1 pessoa-mês (geração de PDF com formatação é mais complexa do que parece)

Cálculo: (800 × 1 × 0,50) ÷ 1 = 400 ÷ 1 = 400 pontos

O Item A tem uma pontuação 32 vezes maior do que o Item B. Isso não significa que o Item B nunca vai ser feito — significa que, comparando esses dois itens, o Item A claramente deve vir primeiro. E agora você tem um número para mostrar quando alguém questionar essa prioridade.

O que fazer com a pontuação RICE

Calcule o RICE para todos os itens que você está comparando. Ordene pelo score do maior para o menor. Use essa ordenação como ponto de partida para a discussão de prioridade — não como resultado definitivo.

O valor do RICE não está no número em si, mas na conversa que ele gera. Quando um stakeholder questionar por que o item dele está abaixo de outro, você pode mostrar os números e perguntar: "Você acha que minha estimativa de alcance está errada? Ou o impacto deveria ser mais alto?" Isso transforma a conversa de "minha demanda é mais importante" para "vamos corrigir os dados se estiverem errados".

Value vs. Effort: a matriz visual de priorização

A matriz de Value vs. Effort — também chamada de Impact vs. Effort ou, em algumas versões, de Matriz de Esforço e Valor — é o framework mais visual dos três. Em vez de uma fórmula, ela usa um gráfico de dois eixos para classificar os itens do backlog em quatro quadrantes.

O eixo vertical representa o Valor (ou Impacto) — o quanto aquele item beneficia o usuário ou o negócio.

O eixo horizontal representa o Esforço — quanto trabalho é necessário para entregar aquele item.

Os quatro quadrantes que resultam dessa combinação têm características e estratégias distintas:

Quadrante 1: Alto Valor, Baixo Esforço — Os Quick Wins

Este é o quadrante mais valioso. São os itens que geram muito retorno com pouco investimento de tempo e recursos. Em português, chamamos esses itens de "vitórias rápidas" ou "frutas baixas" — as que você consegue alcançar sem precisar de escada.

Exemplos típicos de quick wins: corrigir um texto de erro que confunde o usuário, adicionar um atalho para uma ação frequente, melhorar a clareza de uma mensagem de confirmação.

Estratégia: priorize imediatamente. Esses itens devem subir para o topo do backlog. Entregar quick wins rapidamente também tem um efeito secundário valioso: demonstra ao time e aos stakeholders que o processo está funcionando e que o produto está evoluindo.

Quadrante 2: Alto Valor, Alto Esforço — Os Grandes Projetos

São as iniciativas estratégicas — as features que vão transformar o produto, mas que exigem sprints de trabalho para serem entregues. São necessárias para o crescimento do produto a longo prazo, mas precisam de planejamento cuidadoso.

Exemplos: refatoração completa do sistema de pagamentos, redesign do onboarding, nova arquitetura de permissões.

Estratégia: planeje com antecedência e quebre em entregas menores sempre que possível. Um grande projeto pode ser dividido em múltiplas histórias, onde cada uma já entrega valor incremental. Isso reduz o risco de investir muito esforço e só perceber os resultados muito depois.

Quadrante 3: Baixo Valor, Baixo Esforço — Os Preenchimentos

São itens que não geram muito valor mas também não custam muito. Podem ser feitos quando o time tem capacidade excedente ou quando o contexto torna aquela pequena entrega especialmente oportuna.

Exemplos: ajustar o alinhamento de um elemento visual, adicionar uma dica de ferramenta, mudar a ordem de campos em um formulário secundário.

Estratégia: faça quando houver espaço, mas não os priorize ativamente. Não deixe esses itens consumirem o tempo que deveria ir para Quick Wins ou Grandes Projetos.

Quadrante 4: Baixo Valor, Alto Esforço — Os Sumidouros

Este é o quadrante mais perigoso. São itens que consomem muito esforço e geram pouco retorno. Muitas vezes aparecem no backlog porque "alguém pediu" ou porque "parecia uma boa ideia na época" — mas quando você analisa o valor real que geram, o investimento não se justifica.

Exemplos comuns: features altamente customizáveis que só 2% dos usuários vai usar, integrações com sistemas que quase ninguém usa, relatórios complexos que nunca são abertos.

Estratégia: evite ou elimine. Se um item está neste quadrante e nenhuma análise muda essa classificação, ele provavelmente não deveria existir no backlog. Remova ou coloque no Won't Have do MoSCoW.

Como usar a matriz na prática

Reúna o time e os stakeholders. Liste os itens em avaliação. Para cada item, estime coletivamente o valor (alto ou baixo, em uma escala simples) e o esforço (alto ou baixo). Posicione os itens nos quadrantes de acordo.

O processo de posicionamento é tão valioso quanto o resultado. Quando o time discute se uma feature tem valor alto ou médio, ou se um item tem esforço baixo ou alto, ele está alinhando o entendimento coletivo sobre o produto — e isso tem valor independente da priorização resultante.

A matriz de Value vs. Effort é especialmente útil em sessões de alinhamento com múltiplos stakeholders porque é visual e intuitiva. Não requer conhecimento prévio de fórmulas. Qualquer pessoa consegue entender e participar do exercício.

ICE: a versão simplificada do RICE

O ICE — sigla em inglês para Impact (Impacto), Confidence (Confiança) e Ease (Facilidade) — é uma versão simplificada do RICE que remove o fator de alcance. É útil quando você está comparando itens que afetam um grupo de usuários similar em tamanho, o que torna o alcance menos diferenciador.

A fórmula é: Pontuação ICE = Impacto × Confiança × Facilidade

A facilidade (Ease) é o inverso do esforço — itens mais fáceis de implementar recebem pontuação mais alta. Geralmente usa-se uma escala de 1 a 10 para cada fator.

Use o ICE quando precisar de uma avaliação rápida e o contexto não exigir a precisão do RICE. É especialmente popular em times que estão começando a usar frameworks de priorização e precisam de algo menos complexo para criar o hábito.

Quando usar cada framework

Cada framework tem um contexto onde brilha mais do que os outros.

Use o MoSCoW quando:

• Precisar alinhar expectativas com múltiplos stakeholders ao mesmo tempo
• Estiver definindo o escopo de um release ou sprint com muita negociação envolvida
• Precisar de um processo de priorização rápido e participativo
• O time ainda não tem dados suficientes para usar uma fórmula quantitativa

Use o RICE quando:

• Tiver dados confiáveis de alcance e impacto para os itens que está comparando
• Precisar de uma justificativa mais rigorosa para decisões de prioridade contestadas
• O backlog tiver itens com perfis muito diferentes (alguns afetam muitos usuários com impacto baixo, outros afetam poucos com impacto alto)
• Quiser criar um processo de priorização mais objetivo e repetível ao longo do tempo

Use o Value vs. Effort quando:

• Precisar de uma visão rápida e visual da distribuição do backlog
• Quiser identificar quick wins imediatamente
• Estiver em uma sessão de alinhamento com stakeholders que não têm familiaridade com frameworks mais técnicos
• Precisar limpar um backlog grande e identificar o que não faz sentido manter

Na prática: combine os frameworks

Os melhores POs não escolhem um framework e usam só ele. Eles combinam conforme o contexto.

Um fluxo que funciona bem: use a matriz Value vs. Effort para uma visão geral do backlog e identificar os quick wins. Aplique o MoSCoW nos itens do quadrante de alto valor para definir o escopo do próximo release. Use o RICE para desempatar itens dentro do mesmo quadrante quando precisar de uma comparação mais precisa.

Como usar frameworks em conversas com stakeholders

O maior valor dos frameworks de priorização não é a pontuação em si — é a conversa que eles tornam possível.

Sem um framework, quando um stakeholder questiona sua prioridade, a conversa fica assim:

Stakeholder: "Por que a minha demanda está atrás da demanda do time comercial?" Você: "Porque analisei e achei que a outra tem mais impacto." Stakeholder: "Eu discordo."

Com um framework, a conversa muda completamente:

Stakeholder: "Por que a minha demanda está atrás da demanda do time comercial?" Você: "Calculei o RICE dos dois itens. O item do comercial tem alcance de 3.000 usuários por mês e impacto alto, com confiança de 80% — deu 9.600 pontos. O seu item tem alcance de 600 usuários e impacto médio, com confiança de 50% — deu 900 pontos. Se você acha que o alcance ou o impacto da sua demanda está subestimado, me mostre os dados e eu recalculo." Stakeholder: "Na verdade, preciso ver os dados que você usou para o alcance..."

Perceba o que mudou: o stakeholder não está mais contestando o seu julgamento — está avaliando os dados. Isso é uma conversa completamente diferente, muito mais produtiva e muito menos política.

Erros comuns ao usar frameworks de priorização

Tratar a pontuação como verdade absoluta

O RICE com estimativas ruins dá uma falsa sensação de precisão. "Este item tem 12.800 pontos" parece muito mais confiável do que "eu acho que este item é mais importante" — mas se as estimativas de alcance e impacto foram feitas sem dados, os dois têm o mesmo nível de confiança. Use os frameworks para estruturar o raciocínio, não para esconder a incerteza por trás de números.

Usar o framework para justificar uma decisão já tomada

Se você já sabe qual item quer priorizar e vai ajustar as estimativas do framework para que o resultado bata com a sua intuição, você está usando a ferramenta de forma desonesta — e eventualmente alguém vai perceber. A integridade do processo é o que torna os frameworks úteis ao longo do tempo.

Priorizar sem considerar dependências

Um item pode ter pontuação altíssima no RICE mas depender de uma mudança de infraestrutura que precisa acontecer antes. Frameworks de pontuação não capturam dependências — você precisa considerar isso explicitamente ao montar o backlog.

Ignorar o contexto estratégico

Às vezes um item com pontuação baixa no RICE precisa ser priorizado por razões estratégicas que o framework não captura: alinhamento com um parceiro importante, janela de mercado que vai fechar, requisito regulatório com prazo. Frameworks são ferramentas de apoio — o julgamento estratégico ainda é do PO.

Fazer o exercício sozinho

Priorização feita pelo PO de forma isolada e apresentada ao time como decisão final perde a maior parte do valor dos frameworks. O processo de estimar coletivamente o alcance, o impacto e o esforço — e discutir as divergências — é onde o alinhamento acontece. Envolva o time e os stakeholders relevantes no exercício.

Certificações e onde estudar

Livros fundamentais:

• Inspired: How to Create Tech Products Customers Love — Marty Cagan: O capítulo sobre priorização é uma das melhores discussões sobre quando confiar e quando questionar os frameworks de pontuação. Marty argumenta que priorização é sempre parte ciência, parte arte — e explica por que.
• Continuous Discovery Habits — Teresa Torres: Tem uma abordagem interessante sobre como o Opportunity Solution Tree pode guiar a priorização de forma mais qualitativa, especialmente útil quando há poucos dados disponíveis.
• Lean Analytics — Alistair Croll e Benjamin Yoskovitz: Aprofunda como os dados que você usa nas estimativas do RICE devem ser coletados e interpretados. Complementa diretamente o que aprendemos no módulo de métricas.

Recursos online:

• Intercom Product Blog: A empresa que criou o RICE tem artigos detalhados sobre como eles usam o framework internamente, com exemplos reais. Vale muito como leitura complementar para entender o contexto em que o RICE foi criado.
• Productboard Blog e Academy: A ferramenta Productboard tem uma série de artigos e vídeos sobre frameworks de priorização com aplicações práticas em diferentes tipos de produto.
• Mind the Product: Comunidade global de product managers com artigos, podcasts e eventos. Tem muito conteúdo sobre priorização escrito por POs com experiência real em diferentes contextos.

Certificações relevantes:

• PSPO I — Professional Scrum Product Owner (Scrum.org): Cobre os fundamentos de priorização dentro do contexto Scrum, incluindo como o backlog deve ser ordenado e justificado.
• PSPO II — Professional Scrum Product Owner II: Aprofunda técnicas de priorização e como comunicar decisões de produto para diferentes audiências — incluindo liderança e stakeholders.
• Certified Product Manager — Product School: Programa mais amplo que inclui uma seção completa sobre frameworks de priorização com exercícios práticos. Reconhecido internacionalmente.

Conclusão

Priorização é a habilidade que separa o PO que gerencia backlog do PO que gerencia produto.

Qualquer um consegue criar uma lista de itens ordenados por pressão de stakeholder ou por intuição. O que diferencia o PO júnior que está crescendo é a capacidade de explicar cada decisão de prioridade com dados e raciocínio, de convidar os stakeholders a questionarem os dados em vez de questionarem o julgamento e de adaptar o framework ao contexto — usando MoSCoW quando precisa de alinhamento rápido, RICE quando precisa de precisão e Value vs. Effort quando precisa de visão geral.

Os frameworks não eliminam a incerteza da priorização. Eles tornam a incerteza visível — e uma incerteza visível pode ser investigada, questionada e reduzida. Uma incerteza invisível escondida por trás de intuição só aparece quando o produto vai na direção errada.

No próximo e último módulo desta parte da trilha, vamos falar sobre OKRs — como conectar o trabalho do backlog aos objetivos estratégicos da empresa e como usar os OKRs para justificar prioridade de uma forma que a liderança entende e respeita.

Até lá.