Como as líderes de IA fazem gestão de produto

Duas mudanças fundamentais

Ant Murphy analisou mais de 30 entrevistas com pessoas que trabalham em times como Claude Code (Anthropic), Codex (OpenAI) e Cursor para identificar como as principais empresas de IA fazem gestão de produto. Ele identifica duas mudanças grandes.

A primeira: todos viram gestores. Inspirando-se no livro "Who Not How", de Dan Sullivan, Murphy argumenta que o trabalho com IA desloca a pergunta de "como eu faço isso?" para "como eu faço a IA fazer isso por mim?". Em seu próprio negócio, ele usa agentes para puxar métricas, validar hipóteses e gerenciar ferramentas como Notion, Jira e Confluence - praticamente não abre mais essas ferramentas diretamente.

A segunda: o trabalho ficou maior. Fiona Fung, gestora do time de Claude Code, afirmou que codificar raramente é mais a parte lenta. Quando o código deixa de ser o gargalo, a decomposição em user stories de horas ou dias perde sentido: quadros Kanban agora exibem funcionalidades inteiras, não por falta de volta ao waterfall, mas porque a unidade de trabalho aumentou.

Práticas consistentes entre as empresas

Trabalho bottom-up. Cat Wu, Head de Produto de Claude Code, disse que quer que cada pessoa leve uma ideia ao mundo em menos de uma semana, às vezes em um dia. Alexander Embiricos, que lidera o Codex, explicou por que isso funciona: ninguém sabe o que é tecnicamente viável nem o que vai ressoar - divergir rápido é estratégia deliberada para território desconhecido. Murphy alerta que isso não se traduz a contextos regulados, como bancos. Além disso, não é todo mundo enviando o mesmo código: designers entregam mudanças de baixo risco, engenheiros ficam com problemas complexos, e existe revisão de PR, testes automatizados, evals e ambiente beta antes de produção. Cat Wu reconheceu custos do ritmo: recursos sobrepostos, inconsistência e clientes com dificuldade de acompanhar.

Dogfooding. Todos usam o próprio produto, mas o time do Codex percebeu que sua visão "AGI-pilled" divergia do uso real dos clientes e ajustou o curso - dogfooding não substitui discovery, e as empresas continuam fazendo o básico: estratégia, discovery e decisões orientadas por dados.

Protótipos. Fiona Fung conta que, em vez de debater no quadro branco, ela e Boris (criador do Claude Code) prototiparam caminhos distintos e os compararam. Com o custo de prototipagem reduzido, criar 10+ opções se torna viável. Protótipo não significa necessariamente código: a fidelidade adequada ainda importa, e tokens têm custo.

Sessões longas de IA. Sobre PRDs não há consenso: alguns adotam spec-driven development com arquivos detalhados; outros dão apenas um objetivo ao modelo. O que todos alinham é que agentes autônomos precisam de contexto para decidir, visão clara do estado final, critérios de verificação e infraestrutura para construir, testar, corrigir e repetir - às vezes chamado de "loop engineering".

Papéis se misturam, mas não desaparecem

Apesar do discurso de "Product Builders", nenhuma entrevista relatou colapso completo dos papéis - ao contrário, essas empresas contratam mais PMs, designers e engenheiros do que nunca. Há nuance: buscam engenheiros com product taste e designers/PMs que consigam codar com IA. A aplicação mais próxima de um papel único são os Forward Deployed Engineers, que constroem junto com clientes e por isso precisam de habilidades de discovery.

Murphy conclui que quem só move pixels no Figma, cria tickets ou escreve sintaxe pode ser de fato substituído - mas grandes PMs, designers e engenheiros trazem profundidade que a IA não elimina. Seu alerta final: não copie cegamente essas empresas, pois o contexto é diferente, e competências como taste, compreensão do cliente, julgamento e verificação (temas da parte 2) talvez não tenham sido cultivadas na sua companhia.