Tenho dois livros que me formaram em produto: o Inspired, do Marty Cagan, e o Gestão de Produtos, do Joca Torres, com quem ainda tive a sorte de fazer mentoria. Por anos esses dois foram o meu mapa: o que é um PM, o que é um product designer, o que é um engenheiro, quem faz o quê. Cada papel com um contorno claro.
No último ano, vendo meu time trabalhar com IA na Prolog, comecei a sentir esses contornos escorregarem. Não que os livros tenham ficado errados: é que a camada onde cada papel acontece subiu.
No primeiro texto da série eu contei o incômodo que me fez começar a reconstruir tech na Prolog, e no segundo, o que é harness, a infra que faz a IA render. Lá no fim do primeiro eu prometi abrir uma parte específica: como o trabalho de cada cargo muda quando a IA passa a ser quem constrói. É esse o assunto aqui.
O trabalho não some, ele sobe uma camada
A IA não está apagando o papel de cada profissão, está mudando a camada onde ele acontece.
A leitura fácil, a que vende susto, é “a IA vai substituir o cargo X”, e não foi o que eu vi acontecer. O que eu vi foi o conteúdo do trabalho mudar de lugar: o que antes era fazer virou dirigir e criticar quem faz.
O engenheiro, que escrevia o código, agora revisa o que o agente escreveu. O PM, que escrevia a spec, agora julga o protótipo que saiu dela em horas. A pessoa é a mesma, o instrumento na mão dela é que mudou.
Quando voltei ao Cagan e ao Joca com isso na cabeça, a ficha caiu de outro jeito. Os dois descrevem, com cuidado, a execução de cada papel (a tarefa concreta, o entregável, o que sai das suas mãos no fim do dia), e é exatamente isso que a IA está assumindo. O que sobra pro humano é a outra metade: decidir o que merece ser construído, achar o buraco no que foi construído, ter gosto pra saber o que é bom. O julgamento, não a execução.
Então vou fazer o que fiz comigo: pegar a definição de cada papel pelos livros, e perguntar o que dela a IA come e o que dela sobra (e fica mais caro).
O time dos três, segundo os livros
Antes de separar papel por papel, vale lembrar como os livros montam o time. O Joca é direto: um produto de sucesso precisa ser desejável, viável e possível de construir, e isso define “as três funções essenciais para se criar um produto de sucesso” (cap. 2): designer de UX, gestão de produtos e desenvolvedor, o trio que ele chama de core team. O Cagan, no Inspired, descreve os mesmos papéis no capítulo de abertura, “Key Roles and Responsibilities”.
Os dois insistem num ponto que vou retomar lá no fim: não é relação de chefe e subordinado. Nas palavras do Joca, “engenharia de produtos, gestão de produtos e UX são um time, não há relação de subordinação entre nenhum desses grupos” (cap. 31), e no Cagan a mesma ideia aparece como PM e engenharia sendo “pares, nenhuma posição é subordinada à outra” (cap. 5, na minha tradução). E quando a IA entra no meio do trio, é essa parceria que mais muda de forma.
Engenheiro: de produtor de código a crítico de agente
Pra engenharia, o que conta deixou de ser quanto código você produz: virou quão bem você critica o que o agente produziu.
A definição do Joca é tão clara que dói rever agora: “engenharia de produtos é responsável por desenvolver o produto e mantê-lo operando”, e, mais adiante, a engenharia “constrói o produto” (cap. 31). Construir era o verbo. O Cagan completa pelo outro lado, falando da relação com produto: “o product manager é responsável por definir a solução, mas o time de engenharia sabe melhor o que é possível, e é ele quem no fim entrega essa solução” (cap. 5, na minha tradução). Definir de um lado, entregar do outro.
Agora a entrega da primeira versão é do agente. O que não mudou, e ficou mais caro, é tudo que o Cagan colava no engenheiro como fonte de inovação: “os engenheiros sabem melhor que ninguém o que é possível” (cap. 5). Saber o que é possível, achar o buraco no plano que o agente propôs, enxergar o trade-off de performance ou segurança que ele não enxerga, decidir quando intervir e quando deixar correr. Isso pesa mais a cada mês. Memória de sintaxe, boilerplate na mão, varrer Stack Overflow, volume de código como troféu pessoal: isso pesa menos.
Na Prolog eu falei isso com todas as letras pro time: ninguém vai ser avaliado por linha de código. Quem sempre foi bom em “achar buraco” fica mais valioso, e quem se identificava com “produzir muito código rápido” vai ter que recalibrar onde investe. E isso não diminui a engenharia. O valor dela sempre esteve mais em saber o que presta do que em produzir rápido, e agora isso só fica explícito.
PM: de spec-writer a arquiteto de iteração
O PM sente isso quando o protótipo fica barato: o trabalho dele para de ser escrever o documento e vira escolher qual ideia merece o tempo do time.
O Cagan é categórico sobre o coração do trabalho: “alguém precisa descobrir qual é a solução, o produto, incluindo as funcionalidades, a experiência do usuário e os critérios de lançamento. Esse alguém é o product manager, e essa tarefa é o coração do trabalho dele” (cap. 1, na minha tradução). O Joca dá o contorno largo: gestão de produtos é “a função responsável por todos os aspectos de um produto de software, durante todo o ciclo de vida desse produto, desde a sua concepção até o fim de sua vida” (cap. 2).
Repara que nos dois a palavra-chave é descobrir, não especificar. O Cagan tem um capítulo inteiro só pra defender que o trabalho é discovery, não “requisitos”: software tem dois estágios, “descobrir o que construir (o produto certo) e construir (o produto do jeito certo). O primeiro é dominado pelo discovery, o segundo é execução” (cap. 12, na minha tradução). Esse sempre foi o recado dele, e a IA só tornou ele literal.
Porque quando o build colapsa de semanas pra horas, o gargalo deixa de ser construir e passa a ser decidir o que vale construir. O spec longo revisado em comitê, o planning trimestral fechado, o status report como entregável, o controle de tráfego entre engenharia e design: tudo isso pesa menos. O que pesa mais é discovery rápido (prototipar pra entender, não specar pra construir), curadoria de hipótese (qual ideia merece tempo do time) e decidir o que não fazer, com mais frequência. Algumas empresas já estão chamando esse PM de “Editor” ou “Arquiteto”. Não é menos PM: é outro PM, quem cura, quem decide com gosto, quem dá direção. O que era central no antigo, escrever a spec, é o que ficou leve.
Product designer: de produtor de telas a maestro de experimento
No design, a unidade de trabalho sai da tela e vai pro sistema que produz telas, e o product designer passa a escolher qual variação sobrevive.
No Joca, a definição de UX é entender pra desenhar: “UX é o responsável por entender a fundo o usuário e o problema que se deseja resolver para esse usuário” (cap. 32). E o fluxo que ele descreve é o ritual que todo mundo conhece: protótipo de papel, depois wireframe, depois “o designer visual de UX começa a colocar cor e forma nessas telas”. O Cagan corta o papel em dois com a mesma lógica: o interaction designer “desenvolve um entendimento profundo dos usuários e cria as tarefas, a navegação e o fluxo”, mapeia isso em wireframes e passa pro visual designer, que “põe carne no wireframe” (cap. 4, na minha tradução).
Esse encadeamento, entender, esboçar, refinar tela por tela, é justo o que a IA encurta. A unidade de trabalho deixa de ser “a tela” e vira “o sistema que gera telas”. Refazer a mesma variação cinco vezes no Figma, especificar componente por componente, o handoff pixel-perfect como rito: pesa menos. Prototipar em velocidade de iteração (várias opções em paralelo, descarta as ruins), definir o sistema visual em vez de cada tela isolada, e a crítica visual rápida (ver a IA propor algo e bater o olho que está errado antes do usuário bater): pesa mais.
E aqui o Cagan diz, lá em 2008, uma coisa que protege o product designer de achar que virou apertador de botão: o trabalho dele nunca foi só desenhar bonito. “Um bom produto exige uma boa experiência do usuário. E uma boa experiência exige a colaboração próxima entre produto e design” (cap. 4, na minha tradução). A IA gera a variação, e quem decide qual delas merece chegar no usuário continua sendo gente com gosto.
QA: de testador a construtor de validação
O QA é o caso mais interessante, porque é o papel que os livros quase não isolaram, e é o que a IA mexe mais.
Repara: no trio do Joca (designer, PM, desenvolvedor) e nos papéis do Cagan, qualidade aparece diluída, como responsabilidade do time, não como cadeira própria com um método próprio. Por muito tempo isso fez sentido, mas agora não faz mais, e a razão é simples: se o agente constrói rápido e a validação continua manual, você só produziu dívida técnica em alta velocidade.
Então o QA deixa de ser quem roda o caso de teste na mão e vira quem desenha o testing harness, o sistema que testa o sistema: configurar IA pra escrever teste pro código que outra IA escreveu, detectar regressão antes do usuário, pensar onde o defeito tende a aparecer. Na prática, virou uma pergunta operacional que adotamos: cada bug que escapa vira “como a gente detecta isso automaticamente da próxima vez?”. Teste manual exaustivo de fluxo conhecido, regressão rodada à mão a cada release, QA como portão único antes de subir: pesa menos. Validação como sistema, não como passe de bola no fim da esteira.
É o papel que mais sobe de camada justamente porque era o menos definido. Onde os livros não cravaram um contorno, a IA está desenhando um novo.
A constante: o que os livros já diziam que importava mais
Tem uma coisa que não muda, e ela estava escondida à plena vista nos dois livros: o que eles colocam como a característica mais importante é exatamente o que a IA não faz.
O Joca abre o capítulo das características de um bom PM sem rodeio: “a mais importante de todas é, sem dúvida alguma, a empatia” (cap. 4). Não é tabela de função nem entregável: é a capacidade de se colocar no lugar de quem usa. O Cagan, do lado dele, gasta o livro inteiro defendendo discovery, taste e julgamento acima de processo, e os dois, cada um do seu jeito, estavam dizendo a mesma coisa: o que separa o bom do mediano nunca foi a parte mecânica do trabalho.
E a parte mecânica é justamente a que foi pro agente. Escrever a spec, desenhar a tela, escrever o código, rodar o teste. O que ficou, e ficou mais caro, é senso crítico, taste (saber o que é bom), julgamento sob ambiguidade, curiosidade, cuidado com quem usa o que você faz. Resumindo na frase que usei com o time: o conteúdo do trabalho muda, a pessoa que faz, não.
O que isso vai cobrar (sem clichê)
Não quero fechar isso bonito demais, porque não é. Essa mudança cobra coisas concretas, e nenhuma é confortável.
A primeira é deixar hábito de uma década pra trás. Quem está há cinco, dez anos no jeito antigo carrega padrões que ajudaram a chegar até aqui, e são justamente esses padrões que pesam pra mudar. Não tem atalho, e o incômodo é esperado.
Depois, criticar a IA tanto quanto criar com ela: aceitar a sugestão que apareceu não é trabalho; achar o buraco no plano que ela propôs, sim. O que sempre foi caro (pensamento crítico, taste, julgamento) fica mais caro.
Tem também o errar como time, não como pessoa. A gente não demite engenheiro por bug em produção, a gente melhora o review, e quando a IA erra é o harness que a gente fortalece. Bug do agente é processo, não pessoa: um compromisso, não um slogan.
E a mais incômoda: aceitar que algumas funções mudam mais que outras. Isso gera desconforto em quem mudou pouco até agora, e não dá pra fingir que está tudo igual. O que dá pra fazer é trazer pra conversa aberta.
E pra não soar como quem chegou no destino: a Prolog ainda está no começo disso. A gente segue no AI-assisted, com ganho de 10 a 20%, não no AI-first de 5x ou 10x. Estou contando uma direção que a gente está construindo, com acerto e com erro, não uma vitória.
O que eu levo disso
Os livros não ficaram errados. Eles descreviam a execução de cada papel com uma precisão que eu só fui entender de verdade agora (escrever a spec, desenhar a tela, construir o produto, rodar o teste), e essa execução agora é do agente. E o que sobrou pro humano é a outra parte, julgar, criticar, ter gosto, cuidar de quem usa, que, voltando ao Cagan e ao Joca, é o que eles diziam que importava mais desde a primeira página.
Talvez seja essa a parte boa: o trabalho que a IA tirou da nossa mão é o que era mais repetitivo, e o que ela deixou é o que sempre foi mais difícil, e mais interessante. Vou continuar contando como for indo.
Fontes
- Marty Cagan, Inspired: How to Create Products Customers Love (1ª edição, 2008). As definições de papel vêm dos capítulos 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) e 12 (Product Discovery). As traduções dos trechos são minhas.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). As definições vêm dos capítulos 2 (O que é gestão de produtos de software?), 4 (Principais características de um gestor de produtos), 31 (Engenharia de produtos e gestão de produtos) e 32 (UX e gestão de produtos).
- A leitura sobre o papel subir uma camada apoia a série: OpenAI, Harness Engineering, e Peter Pang, CTO da CREAO.