Se definir prioridade na sua vida, com tanta coisa para fazer, estudar, família para visitar, já é difícil, imagine fazer isso para um produto digital.
Vamos construir o que é mais importante, o que exige menos esforço do time ou o que o chefe decidiu?
Compartilho sua angústia. Nós tínhamos (e ainda temos) alguns desses problemas. Como resolvemos (parcialmente), é o que quero te mostrar.
Esse é o tipo de artigo que sinto falta hoje em dia: não apenas mostra o resultado final, mas também o racional por trás das decisões e o caminho percorrido até chegar lá. “Como você fez?” É isso que quero responder.
Como recompensa, no final, deixei o link do prompt do Lovable para você copiar e colar.
Uma ideia e um sonho
Acredito que parte das empresas têm dificuldade em priorizar suas features de app. Um dos motivos: todos acreditam estar trabalhando em uma ideia importante e valiosa. Ao mesmo tempo.
Além disso, é natural que, durante os ciclos de projeto as prioridades mudem. Talvez, por estarem distantes do dia a dia do time técnico, alguns executivos não percebem o impacto dessa mudança na operação.
Ainda há aqueles que tudo que têm é uma ideia e um sonho. Dados, pra quê? Foco no usuário, nem se fala.
E se a gente usar um framework?
James Clear adaptou uma teoria simples, mas interessantíssima:
As metas estão relacionadas aos resultados que deseja alcançar. Os sistemas se referem aos processos que levam a esses resultados.
Segundo ele, a meta é ir dez vezes a academia (resultado). Mas o foco deveria ser: qual sistema estou usando para manter saudável? O sistema é a base para que você continue gerando resultados no longo prazo.
Quando falamos de priorização, principalmente, para Products Managers, UX e até profissionais de Experiência do Cliente (CX), acredito que essa seja a principal lição: foque no sistema, na forma como você faz as coisas. O resultado virá como consequência.
Por isso a necessidade de um método, um como, um processo comum, sistematizado. Ainda assim, flexível.
Não importa se você é de tech e quer aprender gastronomia. Você vai se aproximar de novos interesses, assuntos e temas da mesma forma, com o mesmo processo.
E aí, como você aprende?
Nosso processo de priorização era simples: alguém mandava – a partir de critérios não muito claros, e a gente priorizava. E lá íamos nós. Oi, boletos!
Existem diversas técnicas de priorização. No nosso contexto, o framework RICE (Reach, Impact, Confidence e Effort) foi o que mais se encaixou:
- R (Reach – Alcance): quantos usuários serão alcançados.
- I Impact (Impact – Impacto): qual o impacto para os usuários e o negócio, calculado em uma escala que varia entre muito alto (3) a mínimo (0,25).
- C (Confidence – Confiança): qual seu nível de confiança, com base nos dados que possui. Também é calculado em escala (50%, 80% e 100%).
- E (Effort – Esforço): quanto esforço será empregado naquele projeto. Para nós, a melhor sugestão de cálculo foi multiplicar a quantidade de pessoas pela quantidade de semanas.
O ponto central da técnica de priorização RICE é: priorizar tarefas de alto valor e baixo esforço de desenvolvimento.
O verdadeiro segredo não está no método em si, mas na capacidade de refiná-lo ao longo do tempo.
E se a gente ajustar a metodologia?
Se empresa tivesse mãe, ela diria: você não é todo mundo. Mas, tem CEO, então, ele diz: nosso produto é único no mercado.
Empresas funcionam de forma diferente, com times e comportamentos particulares. A metodologia precisa se adequar ao seu contexto.
Usamos o RICE como o coração, a régua, o que dá pulso na nossa priorização, mas adicionamos outros critérios importantes ao seu cálculo.
Antes de explicar o que mudamos, vale a pena explicar que tipo de demandas desenvolvemos:
- Sustentação: correção de erros, manutenção, atualizações de features e suporte ao usuário após o lançamento.
- Incidentes: bugs, falhas que afetam a segurança ou estabilidade do app.
- Evolução: desenvolvimento de novos produtos, jornadas e problemas complexos, que podem levar meses até entrarem em produção.
Vamos continuar?
#1 No contexto de instituições financeiras, demandas regulatórias ou legais ganham prioridade – Oi, Bacen. Por isso, passamos a dobrar o valor do score sempre que esse caso se aplica.
Disclaimer: Chamei essa adaptação de finRICE – fin, de instituição financeira, e RICE porque… bom, é arroz em inglês.
#2 Redefinimos o C para refletir o nível de clareza do time técnico ao invés de quantos dados ou feedbacks de clientes temos para confiar de que aquela solução é viável.
A pergunta passou a ser: quanta certeza o time tem sobre como executar a demanda?
As regras de negócio estão claras? As APIs estão prontas? As dependências foram mapeadas?
E se uma demanda precisar vir antes de todas as outras?
Tudo bem, isso acontece. Faz parte do jogo.
Sempre que uma demanda é cadastrada, assim como há uma sinalização para demanda regulatória, criamos uma sinalização para demandas de executivos.
A diferença: o score finRICE não é afetado. A solução é sinalizada, mas não ganha prioridade automática. Você passa a ter contexto para negociar.
Agora, temos uma ferramenta visual, clara e baseada em um framework. Ela nos permite mostrar, com dados, porque uma demanda deve ou não ser priorizada. Em parte, sinto que era isso que faltava.
Quando um gestor move uma demanda de menor valor acima de outra mais relevante, isso fica visível a todos.
Nosso papel enquanto PM, UX ou CX é mostrar que, dentro de um contexto, ela pode não ser tão relevante assim. Desenvolver aquela ação, naquele momento, pode gerar menos valor para o negócio e o cliente.
E mais: ganhamos alinhamento sobre expectativas de entrega e transparência real no processo de decisão.
E se tudo for urgente?
Tudo é urgente, tudo é pra ontem, mas o que gera valor?
Para lidar com esse cenário, adicionamos mais dois campos no finRICE, Urgência e Andamento.
- Urgência: classificada como alta, média e baixa – o jeito clássico.
- Andamento: utilizamos um valor percentual. Caso uma demanda seja pausada, podemos negociar a conclusão em outro ciclo de priorização, antes de iniciar novas do zero.
Tanto urgência quanto andamento, não afetam o score, mas podem ser indicadores importantes na tomada de decisão.
Tudo pronto. Temos uma metodologia que abraça nossa cultura, negócio e contexto. Já ficou menos complexo priorizar, hein?!
E se colocarmos pistas visuais de priorização?
No mundo ideal, as demandas que geram maior valor, devem ser feitas primeiro. No mundo real, temos ainda priorização por grito, imprevistos e demandas com prazos apertados.
Um pouco de UX pode nos ajudar a resolver isso. Toda vez que uma demanda é movida manualmente para fora de sua posição inicial, o card fica em vermelho.
Prevalecerá a heurística da autoridade, mas não custa nada penalizar visualmente essas decisões. Mesmo que isso não implique diretamente em mudanças, essa passa a ser uma atitude pouco incentivada, pelo menos, na nossa forma de construir a finRICE.
E se criarmos um indicador de eficiência?
E se toda a equipe pudesse olhar para uma única métrica e avaliar, naquele trimestre ou mês, como estamos performando?
Eficiência foi o nome que dei para essa métrica. Ela tem como referência o NPS, variando de -100 a +100, mas com lógica própria:
- Demandas priorizadas com base no score e concluídas aumentam a nota.
- Demandas priorizadas manualmente reduzem a nota.
Se todas as demandas concluídas foram priorizadas corretamente, a nota é +100. Se todas as demandas concluídas foram priorizadas manualmente (no grito), a nota mínima é -100. Entre esses dois mundos, está nossa performance.
Além disso, incluí o score como fator de peso: quanto maior o score, mais o impacto positivo na Eficiência.
Com isso, deixamos de medir apenas a capacidade de entrega. Passamos a avaliar quanto valor estamos gerando com o que entregamos.
Disclaimer: ainda estamos refinando o modelo.
Uma ideia + ChatGPT + Lovable = finRICE
A primeira ideia? Criar tudo no Excel. Ô, Excel. Me desculpe.
Em um mundo onde existe Lovable e Inteligência Artificial as coisas podem ficar mais fáceis que uma planilha.
O primeiro passo foi criar no ChatGPT um prompt detalhado com as informações do que era o RICE, as regras de negócio que queríamos usar e a primeira versão do wireframe criado no Figma.
Prompt pronto!
Alguns créditos no Lovable depois, nasceu a primeira versão, funcional, mas ainda com sérios problemas de usabilidade.
Com base em outras experiências no Lovable, costumo primeiro construir e validar todas as regras de negócio e features para só depois fazer ajustes de interface e experiência.
UX Importa. Muito.
As melhorias de UX, como por exemplo, priorização manual de demandas, um indicador que trouxesse clareza sobre a qualidade do que estava sendo feito, um hover para demandas adicionadas, entre outras, foram necessidades que surgiram conforme o uso.
Clareza é a palavra-chave que eu gosto de usar para definir uma boa experiência.
De acordo com que usávamos, novas sugestões apareciam. O desafio passou a ser lembrar que o finRICE nasce para ser uma solução que atua no nível tático e estratégico. O dia a dia deveria continuar no JIRA.
Perdão, Intercom! No meio do caminho, percebemos um problema: com milhares de usuários usando nosso app, o score das demandas estava alto – cem, duzentos mil pontos. Testamos a divisão por 10 e depois por 100. Funcionou melhor na interface.
Dica: programe-se para usar pelo menos 20% dos créditos para ajustes de layout. Você vai precisar.
E se der certo?
Supabase conectado, bancos criados. Deu certo. O time aprovou a solução. Começamos a testar e priorizar as demandas.
Alguns ajustes foram necessários para chegarmos na versão mais recente, incluindo rodar a aplicação localmente, por conta de segurança de dados.
Para minha surpresa, o que começou como uma solução para o time do app ganhou tração. Outros times vão adotar o RICE.
Agora, eles estão trabalhando na v2 do finRICE, o bean. Pá ti tum!
E agora?
Propositalmente, falo sobre o Lovable e o uso de Inteligência Artificial no processo de priorização por que a IA é meio, não fim. Ela viabilizou uma solução ágil para uma dor real e deve facilitar o ciclo de vida de adoção. Agora, é atravessa o abismo.
Novas melhorias virão como forma de aprimorar a experiência atual e garantir que a proposta de valor inicial não se perca.
- Área de relatórios de desempenho mensal e trimestral.
- Avaliar o Impacto de forma mais robusta, adicionando critérios de retorno financeiro, processos, redução de custos e fraudes.
- Incluir uma visão de Cost of Delay, inspirado em práticas do Nubank. Obrigado pela dica, Product Guru’s e Júlia Sousa.
- Mais melhorias de UX, aqueles ajustes finos que contribuem para uma ótima experiência.
Alguns aprendizados
Você pode fazer tudo, mas não pode fazer tudo ao mesmo tempo.
- Todo mundo sabe que priorizar é importante. Agora, quão fácil e metodológico estamos tornando esse processo?
- A solução passou a fazer mais sentido no momento que mostrei. Desenhe. Crie. Nem que seja um Excel.
- Usar o ChatGPT + Lovable me economizou muitos créditos.
- Se realmente for um problema ou uma dor, as pessoas irão abraçar a ideia, com ou sem uso de IA.
- A mudança é lenta, lenta demais para nossas cabeças ansiosas.
- Algumas das melhores ideias nasceram com o time: Orion Teles, Christian Diehl, Letícia Menezes e Catarina Gruber. 💜
O prompt é meu, é seu, é nosso…
Obrigado por chegar até aqui! Como forma de retribuição, pedi para o Lovable que criasse um prompt detalhado, com toda a lógica e regras de implementação do finRICE.
Um prompt para você economizar tempo e não passar perrengue. É copiar, colar e começar a priorizar hoje. Você pode baixá-lo aqui e continuar levando a mensagem do Lovable a todos.
Se esse conteúdo te ajudou de alguma forma, comenta aqui ou me envia uma DM, pode ser?
Até a próxima!