Priorização de Roadmap: RICE vs Kano vs Opportunity Solution Tree

Já vi um time se pontuar para fora de um ano inteiro de features mortas usando RICE. Quinze itens, todos cuidadosamente classificados, todos entregues no prazo. A ativação não se moveu. A retenção não se moveu. A receita por conta ficou estagnada. O CEO finalmente fez a pergunta que todo PM teme: "O que realmente aprendemos?" Ninguém tinha uma boa resposta, porque o framework nunca foi sobre aprendizado. Era sobre defender a ordem de uma lista.

Esse é o problema com frameworks de priorização. A maioria dos PMs usa RICE porque a Intercom publicou sobre isso em 2017 e o método se espalhou como uma praga por todas as áreas de produto com uma assinatura do Notion. Parece rigoroso. Produz um número. As partes interessadas acenam quando veem a planilha. Mas o framework não é a resposta para o problema do seu roadmap. O framework é um mecanismo que força a conversa que seu time está evitando. Escolha o que força a conversa certa e você vai entregar melhor. Escolha o errado e vai entregar muito.

Então vamos falar sobre os três que você realmente vai precisar defender: o que cada um faz bem, onde cada um falha e quando combiná-los.

O cálculo RICE, com números reais

RICE é a sigla para Reach (alcance), Impact (impacto), Confidence (confiança) e Effort (esforço). A fórmula é direta:

Pontuação = (Reach x Impact x Confidence) / Effort

• Reach: quantos usuários isso afeta em um determinado período. Geralmente mensal. Seja honesto sobre o que "afeta" significa.
• Impact: o quanto isso move a métrica-alvo por usuário afetado. A rubrica original da Intercom usa 3 / 2 / 1 / 0,5 / 0,25 para massivo / alto / médio / baixo / mínimo. É propositalmente grosseira.
• Confidence: uma porcentagem. 100% significa que você tem dados. 80% significa que você tem evidências. 50% significa que está chutando.
• Effort: meses-pessoa somando produto, design e engenharia.

Um exemplo real. Imagine um SaaS B2B com 4.000 contas ativas por mês e você está pontuando três candidatos do roadmap para o próximo trimestre:

A importação em massa vence por larga margem. E honestamente, com essa pontuação, deveria mesmo. Você tem alta confiança, alcance razoável e baixo esforço. O RICE está fazendo exatamente o que foi criado para fazer: destacar a aposta óbvia de custo baixo e eficácia alta.

Quando o RICE realmente funciona:

• Produtos maduros com KPIs claros. Você sabe como é ativação, retenção e conversão. Consegue prever o impacto dentro de uma faixa razoável.
• Times grandes entregando em paralelo. Quando cinco squads precisam coordenar sequenciamento, uma rubrica de pontuação compartilhada é mais rápida do que dez reuniões.
• Defender decisões de prioridade para um executivo orientado a finanças. Um CFO consegue ler uma tabela RICE. Ele não consegue ler um mapa de jornada do cliente.

Onde o RICE falha:

• Produtos em estágio inicial. O Reach é um chute porque você ainda não conhece seu público real. O Impact é wishful thinking porque você não sabe como é o sucesso.
• Apostas em fase de descoberta. O RICE penaliza incerteza por meio do multiplicador de Confidence, o que significa que qualquer coisa genuinamente nova é esmagada por qualquer coisa incremental. Seu roadmap se enche de features de importação em massa e nunca inclui a aposta que poderia mudar a trajetória de verdade.
• Apostas estratégicas. "Devemos expandir para o mid-market?" não cabe em uma tabela RICE. Não tente.

A crítica honesta: o RICE otimiza o que você consegue medir, não o que importa. Use-o onde a medição é fácil; ignore-o onde não é.

O modelo Kano, com uma pergunta de pesquisa que realmente funciona

O modelo Kano é mais antigo e mais peculiar do que o RICE. Noriaki Kano o desenvolveu nos anos 1980 para explicar por que algumas features os clientes adoram e outras mal percebem. Existem cinco categorias, mas você só precisa de três para priorização:

• Básico (Must-have): os clientes não percebem quando está lá, mas ficam furiosos quando não está. Autenticação de dois fatores. Exportação para CSV. Busca decente. Construir isso não os faz te amar. Deixar de construir os faz ir embora.
• Performance (Quanto mais, melhor): satisfação linear. Carregamento de página mais rápido, mais integrações, melhor uptime. Vale investir proporcionalmente ao custo.
• Encantamento (Delighters): os clientes não esperam, não conseguem pedir, mas adoram quando recebem. O que faz o demo fechar. Os threads do Slack, os atalhos de teclado do Linear, os cursores multiplayer do Figma quando foram lançados.

As outras duas categorias (Indiferente e Reverso) são onde você corta features. Indiferente significa que ninguém se importa. Reverso significa que algumas pessoas ativamente não gostam (pense em sugestões agressivas de IA em uma ferramenta de produtividade tranquila).

Aqui está o template de pesquisa que uso de fato, duas perguntas por feature:

1. Como você se sentiria se o produto tivesse essa funcionalidade?
2. Como você se sentiria se o produto não tivesse essa funcionalidade?

Ambas respondidas em uma escala de 5 pontos: Gosto / Espero / Sou neutro / Tolero / Não gosto.

A tabulação cruzada indica a categoria. "Gosto / Não gosto de não ter" = Performance. "Neutro / Não gosto de não ter" = Básico. "Gosto / Neutro em relação a não ter" = Encantamento. Aplique isso em 50 a 100 clientes por segmento e você tem um sinal que vale defender.

Quando o Kano vence:

• Decisões de paridade de features. "O Concorrente X acabou de lançar Y. Precisamos disso?" O Kano diz se Y é Básico (sim, entregue agora), Performance (sim, mas no cronograma) ou Encantamento (somente se diferenciar).
• Corte de escopo. Quando a engenharia diz que o spec vai levar seis semanas e você tem quatro, o Kano diz o que cortar. Corte Encantamento primeiro se os Básicos ainda não estiverem prontos.
• Decisões de "devemos construir isso?" Se uma feature recebe pontuação Indiferente, os dados dizem para desistir.

A armadilha: o Kano precisa de dados reais de clientes, não do instinto do PM para classificar. Já vi roadmaps inteiros justificados por uma análise Kano que consistia em três pessoas em uma sala de reunião discutindo em qual coluna colocar a exclusão em massa. Isso não é Kano. É um PM lavando opiniões pelo nome de um framework.

Opportunity Solution Tree, quando vence

Teresa Torres criou o Opportunity Solution Tree (OST) para times que praticam descoberta contínua. A estrutura:

                  Resultado
                     |
       -----------------------------
       |             |             |
  Oportunidade Oportunidade Oportunidade
       |             |             |
   ---------     ---------     ---------
   |       |     |       |     |       |
 Solução Solução Solução ... Solução
   |
Experimento

Você começa com um Resultado (um resultado de negócio mensurável, como "aumentar a conversão de trial para pago em 15%"). Você mapeia Oportunidades (pontos de dor do cliente, necessidades não atendidas, momentos de atrito) coletadas em entrevistas semanais com clientes. Abaixo de cada oportunidade você brainstorma múltiplas Soluções. Abaixo de cada solução promissora, você desenha um Experimento para validar antes de construir.

O brilhantismo está em forçar uma hierarquia. Você não pode priorizar uma solução contra outra solução. Só pode priorizar oportunidades e então escolher a melhor solução para a oportunidade escolhida.

Quando o OST vence:

• Times de descoberta contínua. Times com pontos de contato semanais com clientes e que fazem teste de protótipo. A árvore se atualiza conforme a descoberta revela novas oportunidades.
• Organizações orientadas a resultado. Onde a liderança define metas como resultados, não como listas de features. O OST traduz resultados em um pipeline de descoberta e construção.
• Evitar o modo fábrica de features. O golpe fatal do OST é tornar visível quando uma solução não está vinculada a uma oportunidade que está vinculada ao resultado. Se não há conexão, não construa.

Onde o OST falha:

• Organizações onde "descoberta" significa uma entrevista com usuário por trimestre. O OST é um sistema operacional de descoberta contínua. Sem a cadência de descoberta, a árvore é decorativa. Você vai preenchê-la com oportunidades que assumiu, não oportunidades que encontrou.
• Times sem acesso a pesquisa. Se o seu PM precisa lutar para conseguir cinco ligações com clientes por mês, o OST é aspiracional, não operacional.
• Trimestres de pura execução. Às vezes você precisa entregar o que está bloqueando a renovação. O OST não vai ajudar a sequenciar oito features conhecidas.

"Agora, a seguir, depois" e por que é RICE disfarçado

A maioria dos roadmaps "agora / a seguir / depois" são classificações RICE com os números escondidos. O PM pontuou tudo, o topo da lista foi para Agora, o meio para A Seguir, o fundo para Depois. O formato finge ser flexível, mas a priorização é idêntica a uma planilha ordenada.

O formato realmente significa algo quando cada balde tem um padrão epistêmico diferente:

• Agora: alta confiança, escopo definido, comprometido. Você vai entregar isso. O time é dono do resultado.
• A Seguir: confiança média, problema validado, solução ainda em descoberta. Você acredita que isso importa. Ainda não provou que a solução funciona.
• Depois: oportunidades, não soluções. Coisas que você ouviu de clientes que ainda não ganharam um slot.

Se o seu balde "Depois" tem nomes de features com estimativas de esforço, você está fazendo RICE disfarçado. Se o seu balde "Depois" tem problemas de clientes com perguntas em aberto, você está fazendo certo.

Confiança, o input que ninguém pontua honestamente

Todo PM que já conheci infla a confiança na feature preferida. A pessoa que criou a coluna de confiança no framework esperando que fosse uma ferramenta de calibração a vê se tornar uma coluna de vibes.

A solução: uma rubrica de confiança vinculada a evidências, não a sensações.

Qualquer coisa abaixo de 60% não deveria estar na coluna Agora de nenhum framework. Qualquer coisa abaixo de 40% deveria ser uma Oportunidade no seu OST, não uma feature no seu roadmap. Se você não consegue chegar a 60% de confiança em algo que está no roadmap há dois trimestres, elimine. O custo de manter isso lá é a aparência de progresso sem o progresso real.

Por que as partes interessadas odeiam o RICE

Essa é a conversa de diagnóstico que tenho com todo time que diz "o RICE não está funcionando para nós". Quase nunca é o framework. É a camada de tradução.

Vendas odeia o RICE porque pedidos de clientes pontuam baixo em Reach. Vendas está trazendo o pedido que bloqueia o negócio do prospect que paga US$ 80K. O Reach para aquele cliente é um. A pontuação RICE é fracionária. Vendas lê isso como "o PM não se importa com receita". Tradução: tire os pedidos que bloqueiam negócios do RICE completamente. Mantenha uma fila separada de "bloqueadores de negócios" dimensionada pelo impacto na taxa de win. Informe a vendas que essa fila existe.

CS odeia o RICE porque apostas de retenção pontuam baixo em Impact. Features de retenção raramente mostram movimentação de métrica no curto prazo. Elas evitam o churn que aconteceria seis meses depois. O Impact do RICE é prospectivo, mas a maioria dos PMs o pontua como movimentação trimestre a trimestre. Tradução: separe as apostas de retenção e pontue o Impact como movimentação anualizada da taxa de churn, não ativação trimestral.

Engenharia odeia o RICE porque o Effort é o seu chute, não o deles. PMs estimam esforço com base em features similares do passado. A engenharia sabe que o código tem três armadilhas. Tradução: nunca publique uma pontuação RICE com o seu número de esforço. Use faixas (1 a 2 meses-PM, 3 a 5 meses-PM, 6+) e deixe a engenharia refiná-las após uma passagem rápida de escopo. O PM é dono de Reach, Impact e Confidence. A engenharia é dona de Effort.

O padrão: o RICE dá um número, mas os quatro inputs vêm de quatro partes interessadas diferentes. Quando você publica uma pontuação única sem mostrar seu raciocínio, cada parte interessada lê o input que lhe importa e discorda dele. Mostre os inputs. Discuta Reach com marketing, Impact com o time de dados, Confidence com pesquisa, Effort com engenharia. A pontuação é o resultado dessas quatro conversas, não um substituto para elas.

Quando combinar todos os três

Este é o conjunto que uso de fato:

1. Use OST para encontrar a oportunidade certa. Mapeie resultados para oportunidades de clientes por meio de descoberta contínua. Escolha a oportunidade que tem a evidência mais forte e o maior potencial de impacto no resultado. Pule essa camada se você já conhece muito bem o problema (features maduras, domínio bem compreendido). Não pule se seu time está entregando features que ninguém pediu.

2. Use Kano para classificar a solução. Depois de escolher uma oportunidade e ter duas ou três soluções candidatas, aplique Kano nas candidatas com dados reais de clientes. Pule essa camada se a solução é claramente Básica (autenticação, exportação, acessibilidade). Não pule se você está escolhendo entre "tornar a feature existente mais rápida" e "adicionar um momento de encantamento" e não consegue identificar qual os clientes vão valorizar de verdade.

3. Use RICE para sequenciar a construção. Depois de escolher quais oportunidades e soluções construir, o RICE as sequencia ao longo do trimestre. Esforço, dependências, capacidade. O RICE é uma ferramenta de sequenciamento, não de descoberta. É aí que ele justifica seu espaço.

O conjunto completo é excessivo para a maioria dos times na maioria das situações. Um time que entrega melhorias incrementais em um CRM maduro não precisa de OST todo trimestre. Precisa de RICE em um backlog limpo. Uma startup pré-product-market-fit não precisa de RICE. Precisa de OST e disposição para descartar metade do roadmap. Adapte a profundidade do framework à situação epistêmica real. Forçar OST em um time sem acesso a pesquisa é teatro. Forçar RICE em um time que não conhece seus KPIs é precisão sem exatidão.

O framework não é a resposta. Escolha o que força a conversa que seu time está evitando. Se seu time está evitando contato com clientes, aplique OST. Se está evitando cortar escopo, aplique Kano. Se está evitando decisões de prioridade de sequenciamento, aplique RICE. E se está evitando os três, o problema não é o framework. O problema é que ninguém quer tomar uma decisão real, e nenhuma planilha vai resolver isso.

Saiba Mais

• Descrição de Cargo de PM (complementar)
• Hábitos de Descoberta Contínua para PMs
• Como Escrever PRDs que Engenheiros Não Odeiam
• Planejamento Trimestral com Engenharia e Design