Como decidir o que se constrói primeiro: RICE, ICE, MoSCoW, Kano e Opportunity Scoring, com exemplos reais e um guia de quando usar cada um.
RICEMoSCoWKanoPriorização
7 min de leitura
Todas as equipas de produto têm mais boas ideias do que tempo para as construir. A priorização é o processo de decidir que ideias são construídas, por que ordem, e porquê. Bem feita, é a coisa de maior leverage que um PM faz. Mal feita, ou não feita de todo, produz equipas que lançam muito e não saem do sítio.
Os frameworks deste guia não substituem o julgamento. Tornam o teu julgamento explícito, defensável e partilhado. É esse o verdadeiro objetivo: não uma fórmula que te diz o que construir, mas uma estrutura que torna os trade-offs visíveis para a equipa os poder debater antes de construir, não depois.
O Problema
Porque a priorização é a skill mais difícil de um PM
A priorização é difícil por três razões que se reforçam mutuamente. Primeira, o backlog é infinito: as boas ideias vêm de todo o lado, e cada stakeholder acredita que a sua é a mais importante. Segunda, cada “sim” é também um “não” a outra coisa, mas o custo de dizer não é imediato e o custo da alternativa é hipotético. Terceira, a informação de que precisarias para decidir com confiança está normalmente incompleta.
Pressão dos stakeholders
As vendas querem funcionalidades que fecham deals. A engenharia quer limpar dívida técnica. O marketing quer uma landing page melhor. A liderança quer a grande aposta. Todos têm razão no seu contexto. O PM tem de segurar o todo.
O custo de oportunidade é invisível
Quando constróis a funcionalidade A, não vês o valor da funcionalidade B que não construíste. O custo de uma má decisão de priorização é real mas não observável, o que torna fácil racionalizar quase qualquer escolha.
A incerteza é irredutível
Nunca tens dados perfeitos sobre o impacto antes de construir. Os frameworks não eliminam a incerteza. Forçam-te a tornar as tuas estimativas explícitas para poderem ser desafiadas e refinadas.
O objetivo dos frameworks de priorização não é produzir a resposta certa. É tornar o raciocínio transparente o suficiente para a equipa poder ter uma discussão produtiva sobre os trade-offs. Uma decisão bem fundamentada que consegues defender bate uma decisão intuitiva que não consegues explicar.
Framework 1
RICE: o backlog quantificado
O RICE foi desenvolvido pela Intercom e é o framework de scoring mais usado em product management. Calcula um score de prioridade para cada iniciativa com base em quatro fatores: Reach, Impact, Confidence e Effort.
Quantos utilizadores é que isto vai afetar por trimestre? Usa dados reais sempre que possível: utilizadores ativos que passam pelo fluxo relevante, não toda a tua base de utilizadores. Exemplo: se 2.000 utilizadores/mês passam pelo fluxo de checkout, uma melhoria do checkout tem Reach = 2.000.
Impact
Quanto é que vai mexer a agulha para cada utilizador que alcança? Usa uma escala padrão: 3 = enorme, 2 = alto, 1 = médio, 0,5 = baixo, 0,25 = mínimo. É aqui que vive a maior parte da subjetividade. Sê conservador e documenta o teu raciocínio.
Confidence
Quão confiante estás nas tuas estimativas de Reach e Impact? Expressa em percentagem: 100% = suportado por dados, 80% = forte evidência qualitativa, 50% = intuição, 20% = especulação. Isto evita que estimativas excessivamente confiantes dominem o backlog.
Effort
Quantos person-months é que isto exige? Inclui design, engenharia, QA e tempo de PM. Estima em meios person-months. Um score de 1 = 1 person-month. Este é o denominador. Itens de elevado esforço precisam de impacto proporcionalmente maior para ranquear bem.
Exemplo: Um redesenho do fluxo de checkout com Reach = 2.000, Impact = 2, Confidence = 80%, Effort = 3 person-months pontua: (2.000 × 2 × 0,8) ÷ 3 = 1.067. Compara isto com uma pequena alteração de copy com Reach = 500, Impact = 1, Confidence = 100%, Effort = 0,1, que pontua (500 × 1 × 1) ÷ 0,1 = 5.000. A pequena alteração pontua mais alto, um reality check útil contra o enviesamento do “grande projeto”.
Framework 2
ICE: triagem rápida para backlogs grandes
O ICE é uma versão mais leve do RICE, desenhada para velocidade. Pontua cada item em três dimensões (Impact, Confidence e Ease), cada uma de 1–10, e depois multiplica-as. ICE Score = Impact × Confidence × Ease.
Impact (1–10)
Quanto é que isto vai mover uma métrica-chave? 10 = impacto transformador na north star. 1 = negligenciável. Ao contrário do RICE, não exige uma unidade específica. É um julgamento relativo ao longo do backlog.
Confidence (1–10)
Quão certo estás da tua estimativa de impacto? 10 = já testámos isto, os dados são claros. 1 = pura hipótese. Baixa confiança deve atenuar o entusiasmo por ideias de alto impacto. Pontua com honestidade.
Ease (1–10)
Quão fácil é isto de implementar? 10 = horas de trabalho. 1 = meses de trabalho. Nota: este é o inverso do Effort no RICE. O ICE favorece quick wins; o RICE divide explicitamente pelo esforço para normalizar pela escala.
O ICE é melhor usado quando tens um backlog grande que precisa de ordenação rápida e não tens os dados para uma análise RICE rigorosa. É também útil em produtos em fase inicial, onde as estimativas de impacto são inerentemente especulativas. A precisão do RICE seria falsa precisão.
Framework 3
MoSCoW: definir o âmbito de releases
O MoSCoW não produz uma lista ordenada. Produz baldes. Cada requisito é categorizado como Must have, Should have, Could have, ou Won't have (desta vez). Foi desenhado para definir o âmbito de releases: traçar uma linha clara entre o que entra e o que não entra.
Must have
O produto falha sem isto. Não “importante”, mas essencial. Se isto não for entregue, a release não faz sentido. O teste: se isto fosse cortado, o produto ainda entregaria a sua promessa central? Se não, é um Must.
Should have
Importante e esperado, mas o produto entrega sem isto. Tipicamente itens cuja ausência seria notada mas que não partem o caso de uso central. São os primeiros candidatos a adiar se o sprint estiver em risco.
Could have
Bom de ter se houver tempo. Baixo custo de incluir, baixo custo de excluir. Podem ser incluídos conforme a capacidade do sprint permita. Não devem orientar o planeamento. Se nunca forem feitos, é aceitável.
Won't have (desta vez)
Explicitamente fora do âmbito desta release, não para sempre. Este balde é crítico: previne o scope creep ao tornar as exclusões explícitas. Os stakeholders que sabem que o seu pedido está em “Won't have desta vez” deixam de o empurrar para se infiltrar.
O erro mais comum no MoSCoW: Musts a mais. Se tudo é um Must, nada é. Um âmbito de release saudável tem no máximo 60% do esforço em itens Must have. Caso contrário, só renomeaste o teu backlog inteiro.
Framework 4
Kano: perceber o que os utilizadores de facto valorizam
O modelo Kano é único entre os frameworks de priorização porque se foca na satisfação do utilizador em vez do esforço ou do impacto. Categoriza as funcionalidades por como a sua presença (ou ausência) afeta a satisfação do utilizador, o que revela que nem todas as funcionalidades contribuem igualmente para a satisfação.
Expectativas Básicas (Must-be)
Os utilizadores esperam estas. A sua presença não aumenta a satisfação. A sua ausência causa forte insatisfação. Exemplo: uma app que crasha frequentemente. Corrigi-la não vai encantar os utilizadores; não a corrigir vai perdê-los.
Funcionalidades de Performance
Mais é melhor. Estas funcionalidades aumentam a satisfação proporcionalmente: quanto mais depressa a app carrega, melhor. Investir nelas tem um retorno claro e linear. A maioria das funcionalidades de roadmap vive aqui.
Delighters (Atrativas)
Os utilizadores não esperam estas. Ficam surpreendidos e encantados quando existem. A sua ausência não prejudica a satisfação. Mas, quando presentes, geram resposta positiva desproporcionada. As funcionalidades “wow” que impulsionam o word-of-mouth.
O Kano é mais útil na discovery, antes de construir, para classificar pedidos de utilizadores. Um pedido de funcionalidade que soa empolgante pode ser uma Expectativa Básica, table stakes que toda a gente já tem. Uma funcionalidade pequena e inesperada pode ser um Delighter com impacto desproporcionado no NPS e no referral. O Kano evita que invistas desproporcionadamente em funcionalidades que só te trazem à paridade.
Framework 5
Opportunity Scoring: encontrar as lacunas
O Opportunity Scoring, desenvolvido por Tony Ulwick, identifica onde os utilizadores estão mal servidos. Para cada job-to-be-done ou necessidade do utilizador, mede-se duas coisas: quão importante é o outcome para os utilizadores, e quão satisfeitos estão atualmente com as soluções existentes. A lacuna é onde vive a oportunidade.
Alta oportunidade. Os utilizadores ligam a isto mas as soluções existentes não os servem bem. É aqui que a inovação produz mais valor, e onde a diferenciação competitiva é mais alcançável.
Exemplo: os utilizadores dizem que “organizar as minhas tarefas de trabalho” é criticamente importante mas só estão algo satisfeitos com as ferramentas atuais.
Alta importância, alta satisfação
Baixa oportunidade. Os utilizadores ligam a isto, e já estão bem servidos. Investir aqui significa lutar num campo de batalha apinhado. Terias de ser dramaticamente melhor para deslocar o que existe.
Exemplo: “enviar uma mensagem” numa app de mensagens é importante, mas o Telegram e o WhatsApp já o têm coberto.
Guia de Decisão
Que framework usar, e quando
Usa o RICE quando
Tens dados (ou consegues estimar a partir de dados), precisas de comparar um grande número de iniciativas diversas, e queres um score que consigas defender perante stakeholders. Ideal para planeamento de roadmap trimestral com um produto estabelecido.
Usa o ICE quando
Estás em fase inicial ou precisas de fazer triagem rápida de um backlog grande sem análise profunda. Também útil para experiências de growth onde a velocidade importa mais do que a precisão. Pensa nele como o RICE com rodinhas: mais rápido, menos rigoroso.
Usa o MoSCoW quando
Estás a definir o âmbito de uma release ou sprint específico e precisas de traçar uma linha clara de entra/não entra. Particularmente útil quando os stakeholders precisam de acordar o âmbito antes de o desenvolvimento começar. Combina-o com o RICE para decidir o que vai para cada balde.
Usa o Kano quando
Estás em discovery e queres perceber que necessidades dos utilizadores são table stakes vs. diferenciadores. Útil antes de investir na síntese de user research. Enquadra o que andas a procurar. Também poderoso para análise competitiva.
Usa o Opportunity Scoring quando
Estás a definir uma nova direção de produto e queres identificar os jobs-to-be-done mais mal servidos. Exige um inquérito a utilizadores, mas produz a ligação mais direta entre as necessidades dos utilizadores e as apostas de produto.
Nenhum framework sobrevive ao primeiro contacto com a política organizacional. O verdadeiro valor destas ferramentas é tornarem o teu raciocínio legível. Quando um stakeholder contesta, não estás a defender a tua intuição: estás a explicar porque é que os números dão assim, e a convidá-lo a desafiar os pressupostos, não a conclusão.