Em janeiro escrevi que a resistência à IA em times de desenvolvimento de produto não é técnica. É cultural e começa na liderança.

Esse tema tem vindo acompanhado de outras discussões bem interessantes:

• Como a IA impacta a organização dos times de produto?
• Os três papéis (engenharia, design e gestão de produtos) continuam relevantes?
• As proporções continuam as mesmas? 1 designer para cada gestora de produtos e de 5 a 9 engenheiras para cada gestora de produto?
• O que muda no modo de trabalho?

Resposta curta, direta e transparente: não sei. E quem disser que sabe provavelmente está simplificando demais ou dando respostas incompletas. Estamos construindo essas respostas em tempo real.

Ainda é cedo para conclusões definitivas. Mas já há sinais suficientes para observar alguns efeitos práticos. Não como tendência consolidada, e sim como movimentos que começam a surgir em diferentes contextos.

O que segue são observações de campo: situações que tenho visto se repetir, com variações, em empresas de tamanhos e setores diferentes.

Quando a execução fica mais barata, o resto precisa se reorganizar

O efeito mais imediato da IA no desenvolvimento de produto tem sido o aumento da velocidade de execução. Escrever código inicial, gerar variações de uma solução, criar protótipos, consolidar dados de pesquisas e entrevistas ou testar hipóteses ficou mais rápido em muitos contextos.

Isso não elimina o trabalho. Mas muda o custo de fazer certas coisas. E quando o custo de executar muda, o restante do sistema tende a se reorganizar em torno disso.

Durante muito tempo, a capacidade de implementação era um dos principais limitadores. Havia sempre mais ideias do que capacidade de construir. Isso fazia com que a organização dos times fosse pensada em torno dessa escassez. Squads estruturados para entregar um backlog, com engenharia sendo o principal recurso escasso.

Em alguns lugares, esse equilíbrio começa a ser tensionado. Não porque engenharia deixou de ser importante, mas porque a produtividade individual aumentou. O que antes levava dias pode levar horas. O que antes exigia uma sequência longa de refinamentos agora pode ser testado mais rapidamente.

Isso não acontece em todos os times, nem de forma uniforme. Mas acontece o suficiente para levantar uma pergunta: se construir ficou mais barato, onde passa a estar o gargalo?

O gargalo começa a se mover

Em algumas conversas recentes, ouvi algo que, há pouco tempo, seria improvável: equipes de engenharia dizendo que conseguem implementar mais rápido do que as decisões são tomadas.

Não é uma reclamação generalizada. Nem um diagnóstico universal. Mas aparece com frequência crescente. Quando o custo de testar uma hipótese cai, a definição do que testar passa a pesar mais.

Isso não significa que produto “vira gargalo” ou que a solução seja aumentar o número de PMs. Mas torna mais visível o papel da decisão. Priorizar, definir problema, escolher o que não fazer, dar direção clara. Coisas que sempre foram importantes, mas que ficavam parcialmente escondidas atrás do esforço de implementação.

Em uma empresa com que conversei recentemente, a equipe de engenharia passou a gerar múltiplas variações de uma mesma solução em pouco tempo. O processo de design, por outro lado, ainda estava organizado para refinar uma única versão até o nível de pixel perfeito antes de qualquer teste. A tensão que surgiu ali não era sobre quem estava certo, mas sobre a necessidade de ajustar o modo de trabalho a uma nova realidade de custo e velocidade.

Quando testar fica barato, a ordem das coisas talvez precise mudar.

A proporção dos times começa a ser questionada

Por muito tempo, a configuração clássica de times de produto envolveu uma pessoa de produto, uma de design e um grupo maior de engenharia. Em alguns contextos, de 5 a 9 engenheiras para cada PM.

Esse modelo foi construído em um cenário em que a capacidade de implementação era o principal limitador. Se a produtividade de engenharia aumenta, é natural que algumas empresas comecem a se perguntar se essa proporção ainda faz sentido.

Não tenho visto mudanças radicais ou generalizadas. Ninguém está desmontando squads nem reduzindo drasticamente times de engenharia por causa da IA. Mas tenho visto discussões surgirem.

Em um caso, a pergunta era se fazia sentido manter o mesmo tamanho de squad quando a capacidade de prototipar e testar aumentou tanto. Em outro, a reflexão era sobre o papel da pessoa de produto em um contexto em que a equipe consegue testar várias alternativas rapidamente. Em outro ainda, sobre como design se encaixa quando o custo de gerar versões de interface cai.

Não há respostas únicas. Mas o simples fato dessas perguntas estarem sendo feitas já indica que a organização dos times começa a ser repensada.

IA como ferramenta de compreensão do sistema

Um uso que tem aparecido com frequência e que talvez receba menos atenção do que deveria é o uso de IA para entender sistemas existentes.

Em empresas com bases de código antigas ou complexas, ferramentas de IA têm sido usadas para:

• explicar trechos de código

• documentar regras de negócio implícitas

• responder perguntas sobre o funcionamento do sistema

• ajudar pessoas de produto a validar comportamentos sem depender de uma única pessoa engenheira

Isso não substitui conhecimento profundo nem elimina a necessidade de senioridade. Mas muda a forma como o conhecimento circula. Coisas que antes estavam concentradas em poucas pessoas passam a ser mais acessíveis.

Em um time com quem conversei, a adoção de ferramentas desse tipo reduziu o tempo necessário para entender partes do sistema que ninguém dominava por completo. Não resolveu todos os problemas, mas diminuiu a dependência de conhecimento individual e facilitou a comunicação entre produto e engenharia.

Esse tipo de uso não aparece muito em discussões mais genéricas sobre IA, mas tem implicações organizacionais relevantes.

Senioridade e supervisão

Outro padrão recorrente é a necessidade de supervisão e revisão. Ferramentas de IA podem acelerar bastante o trabalho de pessoas menos experientes, mas isso não elimina a necessidade de revisão por pessoas mais seniores. Em alguns casos, aumenta.

Quando gerar código fica mais fácil, avaliar a qualidade das soluções, definir arquitetura e garantir coerência do sistema passa a ter um peso maior. Em equipes que já tinham uma prática forte de revisão e colaboração, a transição tende a ser mais suave. Em equipes que dependiam de contribuições mais isoladas, a adaptação pode ser mais complexa.

Isso não é exclusivo da IA. Mas a velocidade com que as coisas podem ser geradas torna mais visível a importância de certos papéis.

As três funções continuam necessárias

Em meio a essas mudanças, uma coisa não tenho visto desaparecer: a necessidade das três funções. Continuamos precisando de engenharia para transformar ideias em sistemas confiáveis, de design para dar forma às soluções e torná-las compreensíveis e utilizáveis e de produto para dar direção, escolher problemas e alinhar decisões ao resultado que a empresa precisa gerar.

A IA muda o tipo de trabalho dentro dessas funções, mas não elimina a necessidade delas.

Certa vez, uma cliente me contou que três pessoas engenheiras decidiram construir um sistema interno usando ferramentas de vibe coding. A expectativa era ter algo pronto em um fim de semana. Três meses depois, o sistema ainda não estava de pé. A conversa que tivemos foi direta: “Joca, éramos três pessoas engenheiras construindo um produto interno, mas nos faltou aquilo que você sempre fala: uma visão clara de produto. Não sabíamos exatamente o que queríamos construir”.

A capacidade de construir ficou mais rápida. A necessidade de direção não diminuiu.

Novos arranjos começam a aparecer

Também começam a surgir novos arranjos dentro das equipes. Em alguns contextos, aparecem pessoas com perfil mais generalista, capazes de tirar ideias do papel rapidamente usando ferramentas de IA. Em outros, surgem iniciativas específicas para apoiar a adoção de IA no time, seja na forma de grupos de experimentação, seja como parte de programas de capacitação interna.

Não se trata necessariamente de novos cargos formais. Muitas vezes são ajustes de papel dentro do próprio time. Pessoas de engenharia mais focadas em arquitetura e integração, pessoas de produto com acesso mais direto a dados e experimentação, designers explorando múltiplas variações com mais rapidez.

Esses arranjos ainda estão em fase de experimentação. Cada empresa está encontrando o que faz mais sentido para o seu contexto.

O que muda quando a execução acelera

Talvez a forma mais útil de olhar para isso não seja perguntar “quantas pessoas um time terá”, mas “o que passa a importar mais quando a execução deixa de ser o principal limitador”.

Se testar hipóteses fica mais barato, a escolha das hipóteses ganha peso. Se gerar código fica mais rápido, a qualidade das decisões de arquitetura ganha peso. Se explorar alternativas fica mais fácil, a clareza sobre o problema ganha peso.

Nada disso é novo. Mas fica mais visível.

No artigo anterior, escrevi que a IA muda o tipo de trabalho: menos execução, mais decisão e estratégia. O que começo a observar agora é como essa mudança de tipo de trabalho começa a se refletir na organização dos times.

Ainda não há um novo modelo claro. O que há são ajustes, experimentações e perguntas sendo feitas.

O que parece estável e o que ainda estamos entendendo

Abaixo faço uma síntese, baseada nas minhas observações, do que parece estável e do que ainda estamos entendendo à medida que a IA passa a fazer parte do cotidiano dos times de produto:

O que parece não mudar e o que ainda não sabemos como muda

Estamos escrevendo essa história agora

Ainda estamos em um momento de transição. Em algumas empresas, a adoção de IA já está integrada ao cotidiano. Em outras, está começando. Em outras, ainda é vista com cautela.

O impacto na organização dos times não será uniforme nem imediato. Mas já há sinais de que a aceleração da execução começa a tornar mais visível o papel da decisão, da arquitetura e da definição de problema.

Talvez a pergunta mais útil agora não seja qual será a nova estrutura “ideal” de times de produto, mas como tratamos a própria organização do time como algo que também precisa ser desenhado, testado e ajustado.

Se estamos construindo produtos em ciclos de experimentação, talvez precisemos encarar a organização dos times da mesma forma: como um produto em evolução. Cada ajuste de papel, cada mudança de proporção, cada experimento de forma de trabalho ajuda a entender melhor como organizar pessoas para cumprir a missão que sempre esteve no centro: resolver problemas das clientes por meio de tecnologia de uma forma que gere resultado para a empresa.

Estamos escrevendo essa história agora. E, como em qualquer produto em construção, vamos entender melhor o desenho à medida que experimentamos.

Treinamento e consultoria em gestão de produtos

Ajudo empresas e lideranças (CPOs, heads de produto, CTOs, CEOs, tech founders e heads de transformação digital) a conectar negócios e tecnologia por meio de treinamentos e consultoria focados em gestão de produtos e transformação digital.

Podcasts da Gyaco

Na Gyaco, acreditamos no poder das conversas para promover reflexão e aprendizado. Por isso, temos o podcast Produto em Pauta, que explora o universo de gestão de produtos por ângulos diferentes:

• Mentorias: Nesta série, compartilho conversas reais de mentoria com profissionais de produto, partindo da ideia de que as perguntas de uma pessoa muitas vezes são as perguntas de muitas outras. Exploramos desafios concretos, refletimos juntas e transformamos experiência em aprendizados práticos que você pode aplicar no seu próprio contexto.
• Além das Buzzwords: Nessa série de episódios, Felipe Castro e eu desmistificamos termos de produto com exemplos reais de nossas clientes.

Disponível no YouTube e no Spotify. Gravada em português e, no YouTube, com legendas em inglês.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer aumentar as chances de sucesso do seu produto, resolver os problemas das usuárias e atingir os objetivos da empresa? Conheça meus livros, onde compartilho o que aprendi ao longo de mais de 30 anos criando e gerenciando produtos digitais:

• Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia de sua empresa
• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.