Há uma pergunta que consome uma quantidade desproporcional de energia em times de produto: qual é a próxima prioridade?
Ela parece inevitável quando entram em disputa pedidos de clientes, dívida técnica, confiabilidade, redução de custos e uma nova frente de receita. No artigo “The Best Prioritization Is No Prioritization”, o investidor e operador do Stay SaaSy propõe uma inversão útil: em muitos casos, o problema não é escolher melhor. É depender demais da escolha.
Priorizar não substitui capacidade de execução
Frameworks como RICE e Kano podem dar vocabulário para uma conversa, mas não eliminam as incertezas que importam. Alcance, esforço e impacto frequentemente são estimativas frágeis, especialmente em mercados que mudam rápido e em produtos com poucos clientes. Depois que o time segue uma direção, também não existe um experimento paralelo que prove que aquela foi a escolha ótima.
O custo menos visível é o da própria rotina de repriorização: reuniões, planilhas, alinhamentos e mudanças de contexto. Quando a organização consegue entregar pouco, cada decisão vira uma disputa de alto risco. Quando consegue entregar mais, ela pode testar mais hipóteses e aprender com o uso real.
Primeiro movimento: construir mais rápido
A tese não é abandonar o julgamento. É deslocar parte do esforço gasto discutindo o backlog para remover atritos da entrega. Ciclos de planejamento podem ser menores; o tempo liberado pode ir para melhorar ferramentas, reduzir bloqueios, dar autonomia aos times e colocar trabalho em produção.
Velocidade não torna qualquer ideia boa. Ela diminui o preço dos erros e aumenta a quantidade de sinais que o produto devolve. Um time que lança, mede e ajusta aprende mais sobre sua própria prioridade do que um time que prolonga a discussão antes de construir.
Segundo movimento: tirar comparações impossíveis da mesa
Outro ponto forte do texto é a defesa de equipes duráveis, com missões claras. Em vez de deslocar pessoas continuamente entre “o produto novo”, “o produto que mais gera suporte” e “a área com problema de escala”, cada grupo permanece responsável por um domínio.
Isso transforma comparações entre objetivos incompatíveis em escolhas dentro de um contexto. Um time de produto principal pode discutir se reduz chamados, melhora a confiabilidade, entrega uma funcionalidade pedida ou corta custo operacional. Ainda há trade-offs, mas eles são mais concretos e mais próximos de dados de clientes, operação e finanças.
A coordenação entre áreas não desaparece. Ela muda de forma: em vez de trocar prioridade toda semana, a empresa toma decisões de capacidade com mais cadência — ampliar, reduzir, dividir ou encerrar uma equipe. São decisões mais lentas, mas justamente por isso reduzem o vai-e-volta que corrói foco.
O que vale testar na prática
- Meça o tempo gasto para decidir. Se o planejamento vira um projeto próprio, há um sinal de atrito organizacional.
- Separe problemas de prioridade de problemas de fluxo. Atrasos podem vir de dependências, falta de clareza, ambientes instáveis ou excesso de trabalho em andamento.
- Dê missões persistentes aos times. Contexto acumulado e responsabilidade contínua costumam valer mais do que realocações frequentes.
- Use decisões de capacidade para mudanças maiores. Quando uma frente precisa crescer ou parar, trate isso como escolha explícita de recursos, não como um remendo semanal no backlog.
“Não priorizar” não é seguir uma lista ao acaso. É desenhar uma operação em que velocidade, foco e aprendizado reduzem a necessidade de arbitrar toda decisão como se fosse única. A pergunta deixa de ser “qual item vence agora?” e passa a ser “o que está impedindo cada time de avançar bem no seu domínio?”.
Fonte: The Best Prioritization Is No Prioritization, Stay SaaSy (16 jul. 2026).