Como Priorizar Recursos Quando Você Quer Construir Tudo
Priorização de recursos é a questão mais importante que um product manager ou founder enfrenta. Aqui está como fazer corretamente.
Todo produto em crescimento tem mais ideias de recursos do que pode construir. Clientes pedem coisas. Seu produto tira a lista de feature requests para a próxima era. Você vê concorrentes lançando e quer corresponder. O inbox do seu founder é infinitamente longo.
A questão não é "qual recurso é bom?" (muitos são). É "qual recurso é mais importante que os outros?" A resposta determina não apenas o que você constrói, mas o quão rápido sua empresa cresce.
O erro de "dados + democratização"
Muitos times tentam resolver a priorização sendo "orientados por dados". Eles acompanham solicitações de clientes. Eles votam. Eles criam quadrados de priorização com "impacto" no eixo Y e "esforço" no eixo X e veem o que aparece no canto direito superior.
O problema é que dados sozinhos podem não levá-lo a uma conclusão. Se 10 clientes pequenos pedem um recurso e 1 cliente grande pede outro, qual é mais importante? Dados dizem 10, negócio diz 1. Se um recurso traz retenção mas outro traz aquisição, qual você construa primeiro? Dados não dizem isso. Se um recurso é fácil mas não importa e o outro é difícil mas crítico, qual você escolhe? Essa é uma decisão, não uma dedução de dados.
E democratização — deixar todos votar — é tipicamente uma forma de construir o average de opiniões mais barulhentas ao invés do melhor resultado.
Priorização é um compromisso com uma crença sobre qual direção crescerá seu negócio mais rápido. Sem isso, você está otimizando para input, não para resultado.
A estrutura que funciona
Uma estrutura melhor começa com um problema, não um recurso. Não "Construir X recurso". "Como resolvemos o problema Y?" Depois de identificar o problema, você prioriza em duas dimensões: magnitude de impacto e confiança que esta solução o resolve.
Magnitude: Quanto de seu OKR será movido por resolver esse problema? Se você tem um OKR de "aumentar churn em 20%", quais problemas, se resolvidos, moveria esse métrica? Um cliente dizendo "eu quero um dashboard customizado" é um problema diferente de "clientes não estão usando a funcionalidade X que você já tem". O primeiro afeta talvez 5% de seu churn. O segundo talvez 40%.
Confiança: Quão seguro você está que essa solução realmente resolve o problema? Se você entrevistar 20 clientes e 19 dizem "sim, resolveria meu problema", sua confiança é alta. Se você tem 2 clientes pedindo a mesma coisa, sua confiança é mais baixa.
Coloque esses em uma matriz. Magnitude Alta + Confiança Alta? Construa. Magnitude Baixa + Confiança Baixa? Não construa. Magnitude Alta + Confiança Baixa? Valide primeiro antes de construir. Magnitude Baixa + Confiança Alta? Talvez, se seu tempo for realmente vago.
Um cliente diz "eu preciso de um integração com Salesforce." O sintoma é que eles estão digitando dados duas vezes. O problema é a desconexão entre dois sistemas. A solução poderia ser uma integração ou poderia ser uma API que deixa Salesforce puxar dados. A maioria dos times pega a solução do cliente e a constrói. A melhor equipe identifica o problema subjacente e explora soluções.
O papel do trade-off
A priorização só funciona se você realmente está disposto a dizer não. Se você diz "sim" para tudo, você não está priorizando — você está adiando. O trabalho real é aceitar que cada "sim" é um "não" a algo mais.
Se você construir recurso A, você não pode construir recurso B neste trimestre. Se isso quebrou uma promessa a um cliente, você tem que estar ok com isso. Se você adia um recurso que move seu OKR por seis meses porque um cliente grande pediu algo que não move seu OKR, você tem que entender o trade-off.
A maioria dos times não são ruins em priorização — são ruins em trade-offs. Eles constroem o que as pessoas ruidosas pedem enquanto esperando que de alguma forma também vão conseguir as coisas que importam. Isso é como você fica com um produto que é muitas coisas para muitas pessoas e bem em nenhuma para ninguém.
Em FabricLoop, times de produto mantêm um roadmap visível que monta o contexto — o problema que estão resolvendo, por que é importante (qual OKR move), magnitude esperada, confiança do time. Solicitações de clientes vivem no mesmo lugar, com contexto sobre qual problema tentam resolver. Quando alguém (CEO, grande cliente, seu próprio instinto) quer adicionar algo, a discussão é clara: onde vai isto na matriz? O que está se movendo para fazer espaço?