Priorização virou sequenciamento
Frameworks de priorização existem porque construir era o gargalo. E quando o gargalo some?
Todo framework de priorização que você conhece é filho da escassez. ICE, RICE, matrizes de esforço e impacto: todos existem por uma única razão. A capacidade de construção era o gargalo. O time entregava cinco coisas por trimestre, a lista tinha cinquenta, e quase tudo na lista importava de verdade. Alguém precisava decidir o que ficava de fora, e precisava de um método defensável para isso. Priorizar era, na prática, escolher o que não fazer. E a pontuação era menos sobre matemática e mais sobre dar à exclusão uma aparência de objetividade.
Passei anos da minha carreira nessa liturgia. Coletar estimativas, pontuar impacto, negociar pesos, apresentar a matriz, repriorizar no trimestre seguinte. Planilha, workshop, post-it, rodada atrás de rodada. E ela fazia sentido no seu tempo: com engenharia cara e lenta, errar a aposta custava um trimestre inteiro. O método existia para proteger o recurso mais escasso da empresa.
Um exemplo real do que mudou. Um módulo que, num time tradicional, exigiria dezenas de tickets, dois ou três épicos, uma rodada de refinamento e uma cerimônia de priorização para entrar no trimestre. Hoje eu descrevo esse módulo em trinta minutos, com contexto e critérios de aceite, e ele fica pronto em quarenta. Não é figura de linguagem: é a proporção real entre descrever e construir que eu vivo no dia a dia. O tempo de escrever a especificação ficou maior que o tempo de implementar. E o ciclo de aprendizado encolhe junto: o que vai ao ar hoje gera dado amanhã, e o dado de amanhã decide a próxima construção. Num time tradicional, esse mesmo módulo esperaria meses na fila.
Quando o gargalo some, a pergunta muda de natureza. "O que priorizar" pressupõe que a maior parte da lista vai morrer. Se quase tudo que vale a pena pode ser construído, a pergunta vira outra: o que construir na sequência? Parece a mesma pergunta. Não é. Priorização é sobre exclusão; sequenciamento é sobre ordem. E ordem se decide com outro tipo de insumo: não estimativa de esforço, mas evidência de uso. Dados de comportamento no produto, engajamento real, o que os usuários fazem e o que abandonam. O sequenciamento devolve a decisão para onde ela sempre deveria ter morado: o discovery contínuo. Sequenciar bem é uma habilidade diferente de priorizar bem: exige menos política e mais leitura de evidência.
E o busy work do PM? Desaparece, e eu não sinto saudade. Escrever ticket atrás de ticket, gerenciar backlog, arbitrar disputa de estimativa, atualizar a ferramenta de gestão para ela contar uma história que todo mundo já sabia. Nada disso era o trabalho. Era o andaime em volta do trabalho. O tempo que ia para o andaime volta para o que sempre deveria ter sido o centro: entender o usuário e decidir o próximo passo com evidência. Não com a opinião mais alta da sala, mas com dado. Não conheço PM que sinta falta do andaime.
Se a sua semana ainda é dominada por refinamento de backlog, vale fazer a pergunta: o gargalo que justificava isso ainda existe?