Mais valioso, menos protegido: o que sobra do papel de produto
O papel de produto foi desenhado em cima de uma premissa: engenharia é o recurso mais caro e escasso da empresa. Essa premissa caiu. E quando a premissa de um sistema cai, não adianta trocar uma peça.
Essa é a tese que o Anand Subramani desenvolveu na primeira metade do webinar Product Management Fundamentals in the AI Era, da Reforge. A segunda metade, com a JZ, virou outro post — o fluxo da Laurel, da spec ao merge. Essa aqui é a parte que explica por que aquele fluxo tem o formato que tem.
A premissa que organizou tudo
O mundo antigo tinha três papéis e uma divisão limpa: produto responde o quê (quem é o cliente, o que vamos construir, em que ordem), engenharia responde o como, e o quando é de todo mundo.
Engenharia era a maior fatia do gasto de P&D, então o pecado capital era engenheiro ocioso. Tudo foi desenhado pra evitar isso: produto mantém uma fila de specs prontas, semanas ou trimestres à frente; engenharia termina uma e começa a próxima.
A lógica era financeira, não cultural. Se uma feature média custa entre meio milhão e um milhão de dólares em tempo de gente — o número que ele usou pra ilustrar —, você pensa muito antes de mandar construir. E a regra sai sozinha: o pensamento antecipado é proporcional ao custo de construir.
Ele foi generoso num ponto: se sua empresa ainda funciona assim, você não está atrasado. Você é a maioria.
Não dá pra trocar uma peça só
A parte que mais me pegou é uma analogia velha. Anos 80 e 90, montadoras japonesas comendo a indústria americana. Pesquisadores entraram nas fábricas da Ford e da GM pra entender por que era tão difícil copiar o que a Toyota fazia. A resposta, num estudo de pesquisa operacional que ele citou: quando as premissas por trás de um processo mudam, você não consegue mudar só uma parte do sistema. As peças que faziam sentido antes deixam de fazer sentido, e elas se seguram umas nas outras.
É o que está acontecendo com produto. E é por isso que "vamos colocar o PM pra prototipar" quase sempre falha como mudança isolada: você mexeu numa peça de um sistema que continua desenhado pra proteger tempo de engenheiro.
Vale a qualificação que ele mesmo fez, e que some nas versões resumidas dessa tese: isso vale pra feature média de SaaS, redesign de site, fluxo de login. Não pra legado grande e emaranhado. A escassez de engenharia não acabou — acabou pra uma faixa de trabalho, e essa faixa não é a empresa inteira.
O que mudou é mais estreito e mais profundo do que parece. Entender o problema sempre foi a parte difícil, e continua sendo. O que barateou brutalmente foi o como. O quê ainda é seu.
Captain: a responsabilidade seguiu o risco
No mundo antigo, o PM era o "mini-CEO" do projeto — não porque mandava em alguém, mas porque respondia pelo sucesso ou fracasso. Deu certo, o crédito é do time. Deu errado, ele levanta a mão.
O modelo que substitui isso, o Anand chama de captain — o dono do projeto, sem tradução boa em português. Mantém o que importava: uma única pessoa responsável, nunca responsabilidade difusa. E o captain carrega o estado do projeto inteiro na cabeça — se você perguntar o que está travado em quê, ele sabe.
O que muda é quem ganha o posto. Antes vinha junto com o cargo de produto, por padrão. Agora vai pra função onde o risco está concentrado: projeto com risco de produto (não sabemos se é a solução certa) fica com PM; projeto com risco de engenharia (sabemos o que fazer, não sabemos se dá) fica com engenheiro. Ele já viu captain vindo de engenharia, de design, de vendas, de marketing.
Agora a capitania vai pra quem está melhor posicionado pra parte difícil. E às vezes essa pessoa não é você.
— Anand Subramani, sobre o fim da capitania automática
Tem um modo de falha comum justo nas empresas mais AI-native: elas pularam o captain. São ótimas em muita coisa pequena em paralelo e quebram em projeto grande e cross-funcional. Engenheiro tocando quarenta frentes, ninguém sabendo o estado de nada, todo mundo reagindo ao que os agentes fizeram naquele dia. Ele citou uma empresa que jogou fora o mesmo projeto duas vezes antes de acertar na terceira.
O que sobra
O resumo dele é desconfortável e honesto: você está mais valioso e menos protegido.
Mais valioso porque definir o que fazer virou o gargalo da empresa, e quem faz isso bem destrava um time inteiro. Menos protegido porque a visibilidade e a responsabilidade que caíam no colo do PM júnior e pleno de graça — só por ter o cargo — agora vão pra quem pegar a parte difícil.
E aqui tem um incômodo que eu não consigo resolver. Em Hamburgo eu concordei com o Christian Idiodi: se o trabalho pode ser documentado, ele pode ser automatizado. Spec é trabalho documentado — e a própria JZ descreve treinar skills que simulam o vai-e-vem que produz um. Então o quê é porto seguro mesmo, ou é só o próximo degrau da mesma escada? Não tenho resposta. Só desconfio de quem tem.
A saída não é competir por capitania. É que o trabalho de produto migra de decidir o que se constrói para garantir que todo mundo tenha contexto pra decidir bem. Trabalho diferente e provavelmente mais impactante — e é o que a gente tem tentado montar com o ClickBus-OS.
Com uma ressalva, porque é fácil ler isso como convite a descentralizar tudo: descentralização é dial, não interruptor. A pressão de fundador costuma ser maximalista, e ele acha isso errado pra maioria das empresas. Você provavelmente deveria estar mais adiante do que está hoje — quase certamente não no máximo.
Eu saí com uma pergunta chata pra responder sobre as coisas que estou tocando: em quantas delas o risco principal é de produto? Porque essas são as minhas por mérito. Nas outras, eu estou ocupando a cadeira por herança do cargo — e herança é exatamente o que acabou.