Recentemente, meu colega Anselmo Filho escreveu um artigo aqui no Blog da PM3, falando sobre margens de erro do método RICE. E isso gerou uma discussão no Linkedin – o que me inspirou a escrever este texto.
Mas é importante frisar que o que trago aqui é minha visão para adicionar ao debate, sem a obrigação de determinar a existência de um caminho único ou correto. Apenas uma perspectiva suplementar para esta conversa, que merece ser amadurecida continuamente.
O dilema da priorização
Todos nós sofremos com priorização. Prazos apertados e pivôs, necessidades de última hora ou hesitação corporativa, além de barreiras internas, como conflitos com nossos vieses ou baixa tolerância à pressão sofrida de um stakeholder importante.
Seja realizando o planejamento trimestral, representado por um roadmap, ou uma questão imediata, como o cumprimento de uma meta apertada em detrimento da qualidade da entrega – e, por consequência, a geração de débito técnico – uma coisa é certa: iremos enfrentar o dilema da priorização.
O framework RICE: objetivo ou subjetivo?
O framework RICE é muito utilizado para amparar nossas decisões e, conforme aprendemos no curso de Product Management, tem um valor imenso para ajudar as pessoas de produto a chegarem em um denominador comum na priorização de iniciativas. O RICE permite que um comitê de produto ofereça suas perspectivas, amparados por uma metodologia que permite quantificar o valor potencial de diferentes iniciativas.
Aliás, não é nem meu ponto aqui hoje falar sobre o RICE. Meu ponto é falar sobre a subjetividade deste método em si. E mais, falar sobre como o papel do Product Manager é essencial na arbitragem de decisões difíceis. Dentre elas, escolhas que custam tempo, esforço e muito dinheiro, na expectativa de que as oportunidades selecionadas gerem valor para a companhia.
A subjetividade do RICE: como a letra C (confiança) pode ser o ponto menos confiável
Para reforçar o que pretendo explorar aqui, nada melhor que trazer uma citação sobre confiança de um dos gênios da nossa atualidade, autor de ‘Pensando Rápido e Devagar’, Daniel Kahnemann:
“A confiança é um sentimento que reflete a coerência da informação e a facilidade cognitiva de processá-la. É sábio levar a sério as admissões de incerteza, mas declarações de alta confiança basicamente te dizem que um indivíduo construiu uma história coerente em sua mente, não necessariamente que a história é verdadeira.”
Sim. Eu já li este trecho umas 50 vezes para conseguir tirar algum valor e ainda será preciso mais 50 leituras para entendê-lo completamente (risos).
E o que é possível aprender com este trecho de um dos livros mais influentes do século sobre a psicologia humana e nossos vieses cognitivos? Que, como indivíduos, somos biologicamente programados para aceitar os caminhos mais fáceis.
E que uma declaração eloquente e bem articulada pode ser apenas uma manifestação lógica, individual. Uma racionalização coerente sobre o fenômeno em análise. É isso que chamamos de confiança.
E é isso que torna o RICE subjetivo. Além das margens de erro, já citadas pelo Anselmo em sua publicação, temos um componente – a letra C – deste framework que é totalmente voltado à maneira como uma pessoa enxerga o mundo. E não acredito que seja possível ponderar Confiança (ou melhor, a maneira como um indivíduo percebe o mundo) num sistema rígido de pontos.
Vou tentar explicar por quê.
Entendendo a ponderação do RICE
Vamos exercitar um trabalho de priorização com estas 3 iniciativas listadas a seguir:
- Iniciativa A: uma mudança na jornada de onboarding, que explora uma oportunidade de melhoria da ativação de nossos usuários;
- Iniciativa B: uma correção na arquitetura, que explora uma oportunidade na melhoria de utilização do app, com geração de relatório mais confiável e mais rápido;
- Iniciativa C: uma nova funcionalidade, que explora uma oportunidade de negócio, nos colocando no páreo com um concorrente, que tende a “roubar” nossos usuários para sua solução que tem essa feature como queridinha.
Colocando num quadro…
Com os pontos e o racional entre parênteses, eu chego nesta classificação:
| Alcance | Impacto | Confiança | Esforço | RICE Score | |
| A – Onboarding | 4 (Todos os novos usuários passam pelo onboarding) | 3 (Melhoria na ativação dos usuários pode levar a maior retenção) | 2 (Diversos fatores afetam a ativação dos usuários, tornando difícil prever os efeitos de mudanças no onboarding) | 3 (Mudanças no onboarding podem exigir alterações consideráveis na UX e na engenharia) | 8 |
| B – Arquitetura | 2 (Apenas usuários que usam a funcionalidade de relatórios serão afetados diretamente) | 3 (Os relatórios mais confiáveis e rápidos podem melhorar a experiência do usuário) | 4 (Os benefícios das melhorias na arquitetura são geralmente bem entendidos e previsíveis) | 5 (A refatoração da arquitetura pode ser um projeto grande e complexo) | 4.8 |
| C – Nova funcionalidade | 3 (A funcionalidade será relevante para um subconjunto significativo de usuários) | 4 (A nova funcionalidade pode ajudar a reter usuários que de outra forma poderiam ser perdidos para o concorrente) | 3 (Embora a funcionalidade seja promissora, é difícil prever seu sucesso) | 4 (Desenvolver uma nova funcionalidade do zero é um projeto complexo) | 9 |
Lembrando que este RICE Score foi calculado dividindo-se a multiplicação dos scores de Alcance, Impacto e Confiança pelo Esforço (A * I * C) / E). Agora que temos a tabela preenchida, podemos fazer uma análise do exercício.
Entendendo a dimensão da confiança
É possível afirmar que há base quantitativa e qualitativa para ponderar estes fatores: Alcance, Impacto e Esforço. Eles podem ser apoiados por uma documentação viva, rica em dados históricos e pela experiência dos stakeholders, principalmente os técnicos, envolvidos no processo de avaliação dos critérios.
Por outro lado, a Confiança, apesar de sua importância, é uma métrica que varia conforme a facilidade cognitiva do indivíduo em relação à iniciativa, mesmo quando ponderada em grupo. Em resumo, a tendência a seguir por caminhos cognitivos mais fáceis de trilhar é mais predominante, influenciando profundamente o que estamos tentando determinar como Confiança.
Insights da tabela RICE
Agora, voltemos a atenção à tabela RICE do exercício, para tentar trazer mais insights:
- Para a iniciativa A, “Diversos fatores afetam a ativação dos usuários, tornando difícil prever os efeitos de mudanças no onboarding” é uma afirmação carregada de suposições mais voltadas à complexidade do comportamento do usuário. Estar confiante aqui é acreditar que o usuário irá se comportar de determinada maneira antes do lançamento da iniciativa. Podemos nos amparar por estudos e entrevistas, mas ainda assim, só saberemos a realidade quando o lançamento ocorrer. Subjetivo demais, não?
- Já em B, “Os benefícios das melhorias na arquitetura são geralmente bem entendidos e previsíveis” apresenta um certo grau de confiança, muito provavelmente pode se amparar na previsibilidade que a liderança técnica responsável pela área traz. Mas ainda assim, não é absoluta em todos os contextos;
- Finalmente, na iniciativa C, “embora a funcionalidade seja promissora, é difícil prever o seu sucesso” é onde até pode ser possível obter um grau de certeza em função de discovery e benchmarks – mas não existe método nem pesquisa suficientemente disponíveis para fornecer 100% de confiança.
Vivendo numa posição onde precisamos arbitrar o tempo de Discovery vs Delivery, não é possível alcançar 100% de certeza antes de realizar um lançamento.
Podemos deliberar sobre o critério Confiança com mais profundidade? Podemos, mas não é aqui que está o foco do trabalho do PM. Nosso trabalho é sobre a tomada de decisão. Quanto mais ponderações forem feitas, mais distantes estaremos de realmente entregar valor para o usuário.
Arbitrando com Confiança
Como gestores de produto, temos o compromisso de arbitrar incertezas. Existem muitos dados de diversas fontes que irão nos apoiar, frameworks que permitem evidenciar raciocínios, assim como documentações extensas. E os acordos entre as pessoas envolvidas nas atividades podem facilitar o entendimento das ponderações dentro do framework RICE.
Como foi abordado, a letra C apresenta uma certa dimensão de subjetividade que possibilita uma reflexão profunda sobre seu valor. Só não vale ficar divagando eternamente sobre ela.
O mais importante disso tudo: nenhum modelo ou framework é rígido
Uma documentação bem construída, análise de dados e políticas expressas bem disseminadas podem até mitigar subjetividade. Mas é importante aceitar que somos responsáveis pelo questionamento contínuo, por confrontar nossos vieses e, principalmente, por aceitar que muito dificilmente teremos 100% de confiança em nossas escolhas. E essa é uma parte integral da jornada do gestor de produto.
Divertido, não?
