Já faz um tempo que não compartilho com a comunidade os meus conhecimentos, aprendizados e pensamentos. Mas, nos últimos dias, tenho visto discussões a respeito de priorização e, depois da minha Live no Product Tank com o Alexandre Nigri, algumas pessoas me procuraram para falar sobre o assunto.
Eu educadamente recusei, porque sei que minha visão é pouco, digamos, ortodoxa. Na minha visão, não deveríamos discutir priorização – a nível de funcionalidade, que fique claro – com stakeholders, e nem utilizar frameworks para priorizar funcionalidades com eles. Em geral, entendo que as pessoas de Produto podem estar procurando esse tipo de material, porém esse não é o meu propósito quanto a esse tema.
Depois de ler este artigo, minha visão se consolidou. Eureka! Destaco aqui a conclusão do artigo, que majestosamente descreveu muitas das questões que defendo em termos de priorizar funcionalidades:
“A priorização é mais do que um exercício analítico/intelectual. É um desafio organizacional com divergências naturais entre as partes interessadas. Os líderes de produto precisam pensar em motivar os tipos certos de participação e abordar os problemas emocionais que surgem. Planilhas e modelos são necessários, mas não suficientes.”
Inclusive, em um curso para pessoas de Produto que ministrei, não incluí propositalmente a priorização no conteúdo. Por conta disso até recebi alguns feedbacks negativos – “faltou no curso o framework de priorização, dona Pri!”.
Veja bem, não estou incentivando aqui que você não converse com seu stakeholder, não é isso! Muito menos que você não priorize. A questão é que existem diferentes níveis de envolvimento das partes interessadas (por isso o mapa de stakeholders é tão útil), além de que o universo de priorização é bem mais complexo do que criar planilhas e educar seus stakeholders sobre elas.
Achou confuso? Vou explicar melhor o que quero dizer com isso ao longo deste artigo. Se você quer ter menos dor de cabeça ao priorizar funcionalidades, vem comigo!
A problemática
Vou contar aqui uma história da época em que eu era Product Owner. Para dar mais contexto: era PO em uma empresa sem Product Managers, portanto o papel e as responsabilidades eram muito similares às desse cargo.
Nessa época, eu estava dando meus primeiros passos autônomos como PO. Juntamente com uma colega, estava construindo uma ferramenta para potencializar vendas da companhia. Tínhamos realizado uma série de levantamentos de esforço e de funcionalidades desejadas pelos stakeholders – e nos encontrávamos numa famosa “sinuca de bico” para priorizar tantas funcionalidades e iniciativas.
Eu sentia que precisava de mais informação, como por exemplo, retorno esperado da implantação e economia esperada. Ao questionar a minha gestão sobre retornos, a mesma foi taxativa:
“Não faça esse tipo de pergunta. Isso é uma afronta ao stakeholder“.
Sem entender direito as minhas responsabilidades e com pouca maturidade no papel – mas sempre com a maior boa vontade – conseguimos a atenção do time de stakeholders por quase 2 horas utilizando o framework RUT (relevância, urgência, tendência). Durante aquele período, o time votou e discutiu sobre como priorizar funcionalidades. Foi absolutamente maravilhoso.
Eu e minha colega, satisfeitas com o resultado, declaramos que as funcionalidades que seriam priorizadas eram as X e Y, concomitantemente. Eis que um HiPPO levantou e disse:
“Eu não concordo com esse cálculo, quero priorizar a funcionalidade A. Essa é a mais importante.”
Resumo da história: o método para priorizar funcionalidades falhou. Talvez, assim como eu, você tenha pensado agora: “Como assim o stakeholder não acatou as métricas do RUT? Um absurdo!” Deixando um pouco a revolta de lado, vale questionar: auais foram as causas dessa decepção?
Em um primeiro momento, você pode achar que o stakeholder é mandão, ou que sabe trabalhar com o método ágil. Mas não foi nada disso, caro padawan.
O problema aqui é que a priorização RUT (assim como RICE, MoSCoW, etc) são percepções do time sobre coisas incertas. São formas de tentar tangibilizar coisas intangíveis. E intangível como é, atinge pontos importantes de segurança psicológica de um stakeholder, que pode (e deve) ter outras preocupações além de qual funcionalidade devemos entregar, por exemplo:
- Quais são as metas do ano?
- Como estão as metas do trimestre, e do mês?
- Como está o gasto de dinheiro do orçamento da área?
- Qual o principal resultado esperado pela empresa e porque eu preciso de recursos (pessoas, automatizações) para me ajudar?
Dessa forma, a priorização de funcionalidades com stakeholders se torna um problema analítico, político e psicológico. Psicológico pelos motivos citados acima, político porque envolve outras camadas da organização, como a estratégica e tática. E por fim, analítico, porque não temos dados “de verdade”, apenas percepções intangíveis de esforço ou impacto, dadas por pessoas diferentes com backgrounds diferentes.
Para onde deveríamos estar olhando
As ferramentas de priorização, no geral, tratam do nível mais granular da funcionalidade. Por exemplo, a Matriz Esforço x Impacto, MoSCoW e BVP trabalham em nível de backlog (máxima granularidade).
Quando a priorização nasce a partir de um nível mais macro – do nível estratégico-tático, olhando para problemas que a empresa tem para resolver, pressão de mercado e orçamento/investimento disponível – elas não são tão eficientes. Tem um diagrama bem legal aqui, no qual eu explico melhor essa questão da granulidade.
Como Product Manager, sabemos que você está resolvendo (ou deveria estar resolvendo) questões vitais e importantes da empresa – e não somente construindo funcionalidades, uma atrás da outra. Em parelelo a isso, stakeholders estão se preocupando em como levar áreas a outro patamar, e C-Levels estão pensando em como levar a empresa a um maior market share ou melhor valuation.
Portanto, quero te convidar a olhar com atenção para este modelo de atuação da Reforge:
Neste modelo, temos C-Levels e VPs trabalhando na missão e estratégia da empresa. Diretores, gerentes e lideranças estão olhando para estratégia, roadmap de produto e suas metas, e o time de Desenvolvimento está focado nas hipóteses e no backlog.
Dessa forma, o PM trabalharia junto com as lideranças na priorização de problemas a resolver e elaboraria hipóteses de soluções com o time de desenvolvimento, focados sempre nas questões primordiais nas quais o negócio se ancora, priorizando contexto sobre controle.
“Mas Pri, ali tem roadmap, não tem? Stakeholders não priorizam iniciativas?” Bem, iniciativas não são projetos! Iniciativas são aquelas que dizem “o que vamos fazer para resolver determinado problema”. Marty Cagan também fala sobre isso neste artigo.
Perceba esse lindo roadmap de exemplo. Nele temos prioritariamente as metas, e depois as funcionalidades – que foram preenchidas após a rodada de hipóteses com a liderança superior, na qual foram discutidas e priorizadas as metas.
Quer dizer que não devemos discutir a funcionalidade em si com stakeholders? Claro que devemos! Toda colaboração é válida. No entanto, é importante ressaltar aqui que o domínio da solução é do time, e stakeholders e lideranças apenas colaboram com ela. Aqui, nesse nível de atuação, a autonomia deve ser do time com contexto da liderança.
Na minha empresa não é assim. O que eu, como PM, posso fazer?
Meu ponto aqui é trazer que existe um problema organizacional a respeito de priorização de funcionalidades e projetos. Quanto mais madura uma empresa é – em termos de cultura de produto – mais ela está trabalhando olhando para necessidades do cliente.
Ou seja, ela está mais próxima do cliente e dá mais espaço para equipes de Produto e Research construírem soluções associadas a problemas dos usuários, ao mesmo tempo que estão ligadas a ROI. Por outro lado, quanto menos madura, mais orientada a projetos top-down e “comando e controle” a empresa é.
Esse problema afeta diretamente a atuação do PM. Isso porque, por incrível que pareça, quanto mais madura for a empresa, menos você vai precisar de suportes externos de priorização (porque estará trabalhando no racional das hipóteses).
Vamos relembrar aqui o template da hipótese, que carrega conceitos importantes sobre incertezas e aprendizados. A hipótese traz uma forma de pensar orientada a incerteza que temos, como vamos mitigá-la e como vamos medi-la. O cartão da Strategyzer ajuda a ilustrar bem esse uso:
A medição dessa hipótese e o aprendizado sobre ela é o que vai trazer os insumos necessários para a priorização.
É importante que pensemos sobre os problemas que os frameworks de priorização resolvem e também tentar endereçá-los de outras formas. Que perguntas estamos tentando responder com esse framework, ou planilha de priorização?
Vamos ao menos, começar de algum lugar. Os frameworks atuais, por exemplo, fomentam a discussão e a colaboração com stakeholders, e sabemos que o caminho é longo até a maturidade.
Porém, o alerta que quero deixar aqui é: não é seu stakeholder que vai aprender a usar os frameworks de priorização, é você PM quem vai deixar de usá-los!
É claro que você pode continuar usando um framework para elevar a discussão, se isso te se ajusta bem ao seu método de trabalho e te torna mais confiante. Mas é importante ter clareza sobre quais problemas você resolve com ele, principalmente no que tange problemas da empresa. Combinado?
O que eu, como gestor de PMs, posso fazer?
Você, gestor de PMs e gestor de gestores de PMs, pode fomentar a discussão sobre quais problemas estão sendo resolvidos, além de elevar a maturidade do seu time.
Isso é possível deixando mais claro ao time qual é o processo de tomada de decisão da empresa e como funcionam os níveis estratégicos e táticos, discutindo prioridades não a nível de funcionalidades, mas sim de resultados a serem alcançados.
Entregue aos seus PMs os custos e os retornos e faça com que isso seja visível e acessível. Fomente a decisão baseada em dados e solicite sempre dados concretos nos racionais apresentados a você.
Resumindo, comece a liderar mais pelo contexto do que pelo controle. Lidere buscando outcomes sobre outputs.
Conclusão
Priorizar funcionalidades vai além dos frameworks, métodos e racionais, pois existem questões organizacionais e de segurança de dados envolvidas. Como vimos ao longo do texto, ela começa em nível estratégico: tendo uma linha mestra, uma visão que orienta a empresa e com objetivos e resultados bem construídos.
Sabemos que a caminhada em Produto está se desenvolvendo e que a utilização de frameworks é muito comum, visto que podem ajudar a elevar o nível de discurso de priorização, tentando tangibilizar algo que poucos conhecem.
Leia também:
