Se o título desse artigo chamou sua atenção, saiba que temos algo em comum. Talvez eu até consiga adivinhar! Posso não saber em que ramo você atua, mas aposto que tem relação com T.I. ou indústria de manufatura.
Acertei? Se não for o caso, posso tentar mais uma: talvez você tenha aspiração a um cargo de Product Manager ou já está na área de desenvolvimento de produto construindo grandes soluções para sua empresa.
Mas chega de suposições, se você chegou até aqui, garanto que você vai aprender várias coisas interessantes para aplicar na sua área.
Então vamos voltar ao ponto: uma das responsabilidades mais desafiadoras de Product Managers e de Product Owners – como priorizar as features de um produto.
Por que a priorização de features é importante?
Toda pessoa que inicia na área de gestão de produto identifica como um dos principais desafios o gerenciamento de novas solicitações de features que chegam das diferentes partes interessadas.
E mesmo que esta não seja uma situação incomum para qualquer gerente de produto, aposto que pode parecer bastante assustador no começo.
Ao longo de todo o roadmap, o produto idealizado atravessa diferentes estágios de maturidade. E em cada estágio, irão surgir várias novas solicitações de features – cada qual com seus critérios de aceitação definidos.
Geralmente, cada solicitação visa um certo grau de impacto no negócio e algum item de melhoria na experiência do usuário. Mas, a real é que não importa o quão sensatas essas features possam parecer, na prática, a velocidade do desenvolvimento precisa ser medida em relação a ambos – o esforço e o valor que irá resultar delas.
Numa configuração típica como gestão de produto em um ambiente ágil, você acaba conversando com vários stakeholders (as partes interessadas) e com os usuários do seu produto.
Vamos ver como a Joana tem tentado lidar efetivamente com várias solicitações de seus stakeholders:
Ah, claro! Quase esqueço de apresentar a Joana.
A Joana ingressou recentemente na empresa “AZ” como gerente de produto. Ela, e as outras pessoas da equipe, vêm desenvolvendo uma plataforma (produto) para simplificar a recomendação de produtos com base no que o(a) cliente já adicionou ao carrinho.
Periodicamente, Joana organiza reuniões com os stakeholders para demonstrar as features recém-adicionadas ao produto e oferecer uma visão dos próximos lançamentos.
Após algumas semanas, Joana reune suas anotações – onde mantém os registros de todas as novas solicitações de features. Pensando em realizar uma avaliação justa do progresso e da capacidade de receber novas solicitações, ela recorre ao seu agile board (ou kanban) e analisa primeiro os itens marcados como “concluído”, e consegue suspirar de alívio.
Mas, ao observar a lista de itens “a fazer”, verifica que ainda há muito a ser realizado. Além disso, seus olhos caem sobre um monte de itens parados no backlog. Aqui, Joana volta para a lista de novas features com as quais já se comprometeu e leva as mãos à cabeça.
Na sua opinião, qual deveria ser a abordagem de Joana para essa situação?
A seguir, veremos como Joana poderia gerenciar melhor essa situação com uma abordagem estruturada, priorizando determinadas solicitações de features em detrimento de outras.
Antes de compartilhar algumas dicas com Joana, vamos espiar algumas das conversas que levaram a essa situação:
Stakeholder A — “Joana, estava pensando numa nova feature que poderia aumentar significativamente o nível da experiência do usuário ao simplificar os fluxos de trabalho e aumentar as conversões em nosso site. Vamos adicionar?”
Joana – “Hm, parece interessante mesmo… vamos adicionar isso à lista atual.”
Stakeholder “B” — “Joana, faz um favor? Aumenta um pouco os botões do site e deixa eles mais arredondados nos cantos? Isso não deve ser trabalhoso de implementar, né!”
Joana — “Claro, sem problemas! Você vai gostar da repaginada quando ficar pronto.”
Você identificou algum padrão nas respostas que Joana deu?
Acontece que Joana se comprometeu com as solicitações sem ao menos considerar o esforço e o valor que cada feature carrega. Ela respondeu afirmativamente a todos os pedidos, sem pensar duas vezes.
Eliminando “ruídos de ideias”
A dura verdade é que muitas ideias não agregam valor ao produto. Por isso, é de extrema importância para Product Managers eliminar esse “ruído de ideias” e aprender a arte de dizer “NÃO” a cada solicitação de feature – e até mesmo evitar o burnout.
Então, vamos ver agora como Joana poderia ter respondido alternativamente aos pedidos acima.
Stakeholder A — “Joana, estava pensando numa nova feature que poderia aumentar significativamente o nível da experiência do usuário ao simplificar os fluxos de trabalho e aumentar as conversões em nosso site. Vamos adicionar?”
Joana — “Essa feature seria realmente incrível, <nome> (demonstra empatia); acontece que não podemos acomodar mais nenhuma nova feature por enquanto. Como o prazo para entregar as features atuais é até <cronograma>, vamos precisar focar nas prioridades que já foram definidas, caso contrário, corremos o risco de não vencer essa entrega. Mas se você me enviar um lembrete depois de entregarmos a demanda atual, ficarei feliz em reconsiderar. (Veja, Joana não se comprometeu – apenas forneceu um cronograma alternativo)”
Stakeholder “B” — “Joana, faz um favor? Aumenta um pouco os botões do site e deixa eles mais arredondados nos cantos? Isso não deve ser trabalhoso de implementar, né!”
Joana — “<Nome>, agradeço demais a sugestão de como nosso produto pode melhorar. Entendo perfeitamente por que esse recurso é importante para você. Acontece que por mais que eu queria fazer, corremos o risco de perder o compromisso de entregar até <cronograma>, a menos que a gente despriorize algumas outras features.”
Top 3 métricas de priorização de features para produtos
Veja, sem a padronização de uma abordagem para priorizar as várias solicitações de novas features, o trabalho de gestão do produto certamente se tornará mais estressante.
Além das estratégias acima, aqui estão as três principais métricas de priorização de features que podem te ajudar a gerenciar com eficácia o roadmap do produto.
1. RICE
RICE (que traduzindo significa ARROZ), como você já deve ter adivinhado, é um grão de cereal amiláceo comestível consumido por quase metade da população mundial. É apenas a semente de uma espécie de grão chamado “Oryza sativa” (o arroz asiático).
E se você está se perguntando o que isso tem a ver com gerenciamento de produtos, já te adianto: absolutamente nada.
RICE, na verdade, é um acrônimo para reach, impact, confidence e effort. É como um sistema de pontuação que mede cada feature em relação a quatro fatores:
- Reach (Alcance) — mede o número de usuários que seriam afetados pela nova feature.
- Impact (Impacto) — que pode ser medido usando uma escala de 1 a 5 (Escala Likert), onde 1 indica baixo impacto e 5 alto impacto.
- Confidence (Confiança) — mede o nível de confiança em relação ao impacto que pode ser gerado. Isso pode ser medido de forma semelhante ao impacto em uma escala Likert. No entanto, um recurso de baixo impacto com alta confiança pode aumentar a pontuação. Por isso, é aconselhável considerar as escalas de acordo.
- Effort (Esforço )— pode ser calculado como o número de FTEs (funcionários em tempo integral) necessários para concluir o recurso em um cronograma específico, exemplo: um mês. Você pode chegar a isso convertendo as horas em FTEs.
RICE (Pontuação Padronizada) = (Alcance x Impacto x Confiança)/Esforço
Uma feature com uma pontuação RICE alta pode ser considerada com maior prioridade em relação a uma pontuação mais baixa.
2. Matriz de esforço x impacto
- Impacto — pode implicar qualquer resultado comercial potencial, como receita, retornos incrementais, aprimoramento da base de clientes e maior penetração no mercado. O impacto pode ser medido de várias maneiras, dependendo do contexto do negócio.
- Esforço — o esforço, por outro lado, leva em consideração diferentes custos: operacionais, de desenvolvimento, custos ao adiar de uma feature específica. O esforço é geralmente capturado em termos de tempo e custo. O tempo é frequentemente convertido em um componente de custo.
Ambas as métricas podem ser medidas por uma Escala Likert (onde 1 é a maix baixa e 5 a mais alta).
Pontuação do Impacto x Esforço = Impacto/Esforço
3. Método MoSCoW
Nessa métrica, geralmente tentamos encaixar as features em três níveis ou categorias mutuamente exclusivas. Uma feature pode fazer parte de qualquer uma dessas três categorias.
- Must-have (deve ter) — categoriza uma feature definitivamente crítica de se ter e tem um impacto significativo no sucesso do produto.
- Should-have (deveria ter) — envolve features que são necessárias para o produto, mas não agora, talvez em um momento posterior.
- Could-have (seria legal ter) — features que são consideradas como complementos. Você pode visualizar como agrados que simplesmente podem aumentar o fator de encanto do seu produto. Frequentemente, melhorias estéticas como mudanças no design e paleta de cor se categorizam como could-have.
Essa métrica permite que você foque nas features mais críticas ao invés dos itens que não são sensíveis ao tempo.
Limitações e desafios
Ainda que as métricas acima sejam populares e frequentemente usadas no setor, há algumas desvantagens das quais você precisa se atentar. Muitas vezes, confiar apenas nesses métodos não ajuda por vários motivos:
- A estimativa que você vai chegar raramente vai ser 100% precisa.
- Nas organizações, por vezes há muitas interdependências e sinergias que tornam essas estruturas de priorização tendenciosas e inconclusivas.
- Embora você chegue a features com pontuação máxima, talvez seja necessário despriorizá-las e repriorizar outras que obtiveram uma pontuação mais baixa com base na necessidade ou em vieses pessoais.
Conclusão
Se você ficou até aqui, tenho certeza de que deve ter aprendido algo novo que dá para aplicar.
Embora eu tenha mencionado algumas desvantagens dessas métricas, elas são bastante úteis e podem ser aplicadas a praticamente qualquer situação na tomada de decisão embasada e te levar um passo à frente na jornada de gestão de produtos.
Você também pode criar uma métrica híbrida combinando os itens acima de alguma forma significativa.
Como acontece com qualquer abordagem ou metodologia, pode haver vieses e conflitos – e é aqui que suas habilidades de gestão e estratégias de negociação eficazes podem brilhar.
Este post é uma tradução livre do artigo 🔗“Top 3 feature prioritization metrics & strategies for Product Managers” escrito por Sayan Mukherjee.
