Dwight D. Eisenhower foi general do Exército americano, comandou as forças aliadas no Dia D e se tornou o 34° presidente dos Estados Unidos. Um homem ocupado, por qualquer definição.
E foi ele quem disse:
“O que é importante raramente é urgente. E o que é urgente raramente é importante.”
Se isso era verdade para quem gerenciava uma guerra mundial, imagina para quem gerencia um produto.
A armadilha é que tudo parece urgente. O cliente reclama. O suporte encaminha. O time pede. O gestor sugere. A concorrência lança. E a pergunta que ninguém quer responder é: o que não vai entrar?
Na sua agenda
Antes de priorizar um roadmap, você precisa priorizar a sua própria semana.
Shreyas Doshi, ex-PM do Google, Stripe e Twitter, popularizou um framework chamado LNO: Leverage, Neutral, Overhead. A ideia é classificar cada tarefa em uma dessas três categorias:
- Leverage: trabalho que só você pode fazer e que tem alto impacto. Aqui é onde você cria mais valor. Deveria receber sua melhor energia.
- Neutral: necessário, mas que outra pessoa poderia fazer. Faça bem, mas sem gastar mais do que o necessário.
- Overhead: tarefas operacionais e administrativas. Minimize. Delegue. Automatize.
O diagnóstico doloroso: a maioria dos PMs passa o dia em tarefas Neutral e Overhead, e pouco tempo nas de Leverage. Reunião de status. Relatório semanal. Aprovações que poderiam ser assíncronas. No fim do dia, a sensação é de muito esforço e pouco avanço.
Para as tarefas que chegam o tempo todo, há uma regra simples que nunca mais larguei: se leva menos de 5 minutos, faça agora. Colocar numa lista só cria mais atrito do que simplesmente resolver.
Para o trabalho que exige concentração real, a resposta são os blocos de tempo. Cal Newport, no livro Deep Work, defende que trabalho de alta qualidade precisa de foco sem interrupções – algo raro em um ambiente cheio de notificações e reuniões. Blocos de 90 minutos a 2 horas, com o telefone em silêncio, produzem mais do que dias inteiros de atenção fragmentada.
A matriz de Eisenhower
O general não criou só a frase. O framework que leva seu nome divide qualquer tarefa em dois eixos: urgência e importância. O resultado são quatro quadrantes:
- Urgente + importante: faça agora. Crise real, prazo crítico, incidente em produção.
- Importante + não urgente: agende. Estratégia, melhoria de processo, aprendizado. É aqui que mora o crescimento – e onde a maioria nunca chega.
- Urgente + não importante: delegue. Parece emergência, mas não exige você especificamente.
- Não urgente + não importante: elimine. A reunião que poderia ser um e-mail. O relatório que ninguém lê.
O problema é que urgência chama atenção. Importância, não. Por isso quase todos passam o dia apagando incêndios do terceiro quadrante – e nunca chegam ao segundo, onde ficam as coisas que realmente mudam o jogo.
No roadmap
Priorizar features é uma das partes mais difíceis do trabalho de produto. Todo mundo tem uma opinião. Ninguém quer ouvir “não agora”.
Para ter uma linguagem comum entre times, parto do ICE score – criado por Sean Ellis, pioneiro do movimento de growth. Cada iniciativa recebe uma nota de 1 a 10 em três dimensões:
- Impact: se funcionar, o quanto muda os resultados?
- Confidence: o quanto temos certeza de que vai funcionar?
- Ease: o quanto custa implementar?
Na prática, uso uma variação. Troco confidence por urgência – porque confiança eu já formo durante o discovery, mas urgência muda toda semana com sinais novos do mercado, do suporte, da concorrência. Fica assim:
- Impacto: esse recurso vai ajudar muito o cliente?
- Urgência: tem algum sinal claro do mercado ou dos clientes pedindo isso agora?
- Ease: pouco esforço, fácil de fazer, rápido?
Não rende uma sigla simpática como ICE, mas me dá respostas melhores. E aplico dois pesos extras na hora de decidir: impacto vale mais que os outros dois – produto sem impacto não merece esforço, por mais fácil que seja. E urgência real fura a fila – se um cliente grande está prestes a churnar por causa de uma feature, isso passa na frente do roadmap planejado, mesmo que o impacto agregado seja menor.
O score serve para ordenar a maioria. As exceções existem para serem reconhecidas como exceções, não para virarem a regra.
Para comunicar o roadmap sem criar falsas expectativas com datas, uso o Now / Next / Later – o NNL. Em vez de um cronograma cheio de marcos que raramente se cumprem, o roadmap vira três camadas simples:
- Now: o que estamos construindo agora.
- Next: o que vem em seguida, com razoável certeza.
- Later: ideias e apostas que estamos considerando, sem compromisso de prazo.
Isso reduz a pressão de ter uma resposta precisa para “quando vai ficar pronto?” e aumenta a honestidade sobre o que é certo e o que ainda é incerto.
No desejo do cliente
Dá para entregar tudo o que os clientes pedem? Não. Mas dá para ser muito mais inteligente sobre o que priorizar.
Na revisão de roadmap, sempre começo pelos itens mais citados pelo suporte. Tickets de atendimento são uma fonte riquíssima: revelam onde os clientes travam, onde sentem falta de algo, onde a plataforma falha. Se dez clientes diferentes abriram tickets sobre o mesmo problema, é um sinal que não dá para ignorar.
Mas o ticket diz o que incomoda – não necessariamente o que mais importa. Por isso combino com dados quantitativos: quais páginas são mais acessadas, quais fluxos têm mais abandono, onde o tempo de sessão é maior. Esses dados mostram onde os clientes passam o tempo, e portanto onde melhorias têm mais impacto real.
As conversas de discovery completam o quadro. O que o cliente diz que quer nem sempre é o que ele precisa – mas a forma como ele descreve o problema quase sempre aponta para qual é o trabalho que ele está tentando fazer.
Com esse triângulo – suporte, dados, discovery – a maioria das apostas deixa de ser aposta. Vira evidência.
Ainda fazemos apostas, claro. Mas a maior parte das fichas vai nos projetos seguros: no desejo já identificado, já expressado, já confirmado pelos usuários. Tenho certeza de que o McDonald's gasta muito mais energia aperfeiçoando a batata frita – o item mais pedido, o que define a experiência – do que criando novas sobremesas. E essa não é uma escolha conservadora. É uma escolha inteligente.
Priorizar é dizer não
No fim, toda decisão de priorização é uma decisão sobre o que não fazer.
Produto que tenta fazer tudo não faz nada bem. Time que trabalha em tudo ao mesmo tempo avança em nada. Agenda sem prioridade é agenda de outra pessoa.
Priorizar não é sobre organização. É sobre escolha. E a escolha mais difícil é sempre aquela em que algo real fica de fora – mas que você faz mesmo assim, com clareza, porque sabe que é o caminho.
