Líder de entrega na Google partilha como os fluxos de trabalho baseados em agentes estão a transformar os modelos de gestão de produto
Anshumani Ruddra explica como os fluxos de trabalho baseados em agentes ajudam as equipas de entrega a desenvolver mais rapidamente, tornando simultaneamente o discernimento humano, a validação e a tomada de decisões ainda mais importantes.
Anshumani Ruddra
Líder de Produto na Google
Mudança para fluxos baseados em agentes: Os fluxos de trabalho baseados em agentes substituem as transferências lineares por uma entrega paralela e multifuncional, assente em código e documentação partilhados.
Discernimento humano: A IA assume a coordenação e a elaboração de rascunhos, enquanto os líderes mantêm a responsabilidade pela qualidade, criatividade, definição de prioridades e confiança.
Começar por auditar: As equipas devem auditar semanalmente os consumos de tempo antes de selecionar ferramentas, evitando uma adoção genérica e conjuntos de ferramentas vistosos, mas ineficazes.
Os rituais são importantes: Uma entrega de IA mais rápida continua a exigir um âmbito claro, alinhamento com as partes interessadas, validação rigorosa e listas de verificação disciplinadas para manter a qualidade do produto.
Modelo de liderança: Uma adoção bem-sucedida da IA combina líderes que alteram os seus fluxos de trabalho com equipas que experimentam e partilham melhorias em toda a organização.
Anshumani Ruddra é líder de produto na Google, onde trabalha na área de entregas dos seus produtos de pagamentos. É também formador e já desempenhou funções de liderança de entregas ao nível executivo.
Conversámos com Anshumani para perceber como a IA está a transformar as entregas em empresas como a Google. Eis o que nos disse.
Desenvolver produtos na Google
Chamo-me Anshumani Ruddra. Passei mais de 22 anos a desenvolver produtos para consumidores na intersecção entre tecnologia, narrativa, cultura pop e comportamento humano — comecei como autor de livros infantis, passei depois a ser designer de jogos em êxitos sociais globais como Mafia Wars e Café World e, mais tarde, fiz crescer a Hotstar até se tornar uma das maiores plataformas de streaming do mundo durante os anos da IPL.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Nos últimos cinco anos na Google, liderei a gestão de produto da aplicação GPay na Índia, um enorme sucesso, geri toda a oferta de produtos de pagamentos da Google para a região da APAC e desenvolvi produtos de IA destinados aos consumidores. Atualmente, lidero um esforço de desenvolvimento de produto de IA de ponta a ponta para criar um produto completamente novo.
Além disso, ensino líderes e executivos de produto a desenvolver com IA através do meu curso na Maven, Level Up to Product Super IC. Desempenho simultaneamente duas funções — operador e professor — e ambas moldam a minha abordagem à entrega de produtos: menos coordenação e aprovações, mais passagem da ideia ao protótipo funcional sem esperar por autorização.
Como a IA permite às pessoas fazer mais daquilo que fazem melhor
Procuro não pensar na IA apenas como mais uma ferramenta, só que melhor. Essa perspetiva leva-nos a pensar que se trata apenas de eficiência. A IA é um multiplicador — possivelmente um multiplicador que só surge uma vez num século.
Permite-me passar muito menos tempo na estrutura de ligação da entrega: síntese de reuniões, elaboração de PRD, atualizações de estado e de partes interessadas e investigação inicial. Passei grande parte desse trabalho para um «sistema operativo agêntico» pessoal, permitindo-lhe funcionar praticamente sozinho.
Agora, passo o meu tempo nos 10% que são difíceis e humanos, não nos 90% de coordenação que costumavam consumir a semana. Concentro-me mais no trabalho propriamente dito: o raciocínio, as decisões de avaliação e a criação de protótipos.
Por falar em criação de protótipos, essa é, por si só, uma enorme mudança. Agora posso validar uma visão criando eu próprio um protótipo funcional antes de atribuir a tarefa a alguém. A barreira à construção desapareceu. Se consigo imaginá-lo, consigo pôr uma primeira versão a funcionar.
Quando utilizar IA e quando é necessária uma pessoa
O trabalho mais automatizável é a camada de síntese e administrativa:
- Transformar o áudio bruto das reuniões em decisões e tarefas
- Gerar os primeiros rascunhos de PRD e da investigação
- Fazer a triagem dos sinais recebidos
- Tratar das atualizações para as partes interessadas
Implementa-se este sistema com agentes pessoais que monitorizam os dados que recebe, destacam aquilo que requer uma decisão e elaboram um rascunho do resto.
A inteligência sobre os clientes também é muito pouco utilizada neste contexto: existem agora ferramentas que indicam quais as funcionalidades a desenvolver e estimam o impacto no ARR, mas a maioria das equipas continua a agregar manualmente os comentários do Slack e dos pedidos de suporte.
Mas as pessoas continuam a ter de definir o que significa «bom». Enquanto líder, definir a qualidade é uma responsabilidade sua, e é por isso que considero as avaliações tão importantes.
As pessoas também têm de lidar com o gosto e o discernimento de produto, com saltos genuinamente criativos do zero ao um e com o trabalho humano de elevada confiança que envolve orientar equipas, navegar na política interna e tomar decisões difíceis de priorização.
A IA dá-lhe mais oportunidades de acertar no alvo; cabe ainda a uma pessoa decidir onde está o alvo.
Porque é que as plataformas tecnológicas devem começar por uma auditoria
As ferramentas de IA são exatamente como um excelente videojogo — fáceis de jogar, incrivelmente difíceis de dominar. A experiência inicial, tão apelativa, leva as pessoas a pensar que tudo será simples, por isso ficam chocadas quando surge a complexidade. Muitas desistem. A verdadeira competência não está na elaboração de instruções; está na vontade de persistir e aprender ao seu próprio ritmo, mais depressa do que parece confortável.
No trabalho, a minha plataforma é composta sobretudo pelos modelos Gemini mais recentes, com o Antigravity como centro de agentes. O gestor de agentes do Antigravity é subestimado. É verdadeiramente inovador. No que diz respeito à gestão de projetos, a Google utiliza ferramentas personalizadas próprias, equivalentes ao Jira e ao GitHub no mundo exterior.
Para os meus projetos pessoais e atividades de ensino, o meu conjunto de ferramentas principal é:
- Claude Code para programação. É o elemento de maior destaque. Utilizo vários agentes em paralelo. É o mais próximo de um assistente real, não apenas de uma funcionalidade de preenchimento automático.
- Replit para prototipagem. A sua abordagem de planear primeiro e os agentes em paralelo distinguem-no.
- NotebookLM e Obsidian para investigação e escrita.
- Codex e Claude Cowork tratam de muitas tarefas agendadas e automatizações, integrando o correio eletrónico, o calendário, as unidades na nuvem e as notas de reuniões.
- Granola e Wispr Flow completam o conjunto de ferramentas. Defendo vivamente a conversão de voz em texto e a utilização da voz como método de introdução.
Nos últimos 6–12 meses, o conjunto de ferramentas evoluiu de «utilizar IA para redigir coisas mais rapidamente» para um verdadeiro sistema operativo pessoal baseado em agentes — menos centrado em pedidos pontuais e mais em agentes permanentes que assumem fluxos de trabalho recorrentes de ponta a ponta.
O meu conselho para criar um conjunto de ferramentas: não comece pela ferramenta mais vistosa. Analise como passa a sua semana, identifique os maiores desperdiçadores de tempo e escolha a ferramenta específica que os elimina. As estratégias genéricas de adoção não funcionam.
Como os fluxos de trabalho baseados em agentes simplificam a entrega de projetos
Concentrámo-nos deliberadamente primeiro na base partilhada que torna estes fluxos de trabalho possíveis, porque tudo se mantém unido ou desmorona nesse ponto.
Quase todos os nossos processos funcionam agora como fluxos de trabalho baseados em agentes, abrangendo o design, a gestão de produto e a execução de engenharia. Os fluxos de trabalho baseados em agentes gerem a estratégia e o raciocínio por detrás do que precisa de ser desenvolvido, o design de componentes, ecrãs e layouts, e a forma como o código de back-end e front-end se articula. Isto não é uma experiência isolada num canto da equipa; é assim que o trabalho é realizado de ponta a ponta.
Concentrámo-nos deliberadamente primeiro na base partilhada que torna estes fluxos de trabalho possíveis, porque tudo se mantém unido ou desmorona nesse ponto. Na prática, isto significa criar uma infraestrutura comum para toda a equipa, um conjunto comum de competências dos agentes e uma estrutura comum através da qual todos trabalham. A peça mais importante é uma documentação que não esteja apenas preparada para humanos, mas também para agentes. Se a sua documentação só fizer sentido para as pessoas, os seus agentes irão desviar-se, pelo que investimos bastante em escrever para os dois públicos em simultâneo.
Concretamente, isto assume a forma de ficheiros de conhecimento claramente assinalados, PRDs e documentos de design de engenharia. Normalmente, mantemo-los em Markdown, de forma muito concisa, e escrevemo-los para que façam sentido tanto para humanos como para agentes. Fundamentalmente, os humanos validam todos estes ficheiros antes de começarmos a desenvolver qualquer coisa. A validação humana dos dados de entrada mantém o fluxo de trabalho baseado em agentes limpo, porque os agentes são tão bons quanto os documentos e as competências para os quais os orientamos.
Mantemos também listas de verificação muito claras e garantimos que os agentes as seguem. Um agente só assinala uma etapa como concluída quando a respetiva lista de verificação está verdadeiramente satisfeita; só então avançamos para a etapa seguinte. Esta disciplina de documentação clara, dados de entrada validados por humanos, competências partilhadas e listas de verificação passo a passo transforma o trabalho baseado em agentes de uma novidade em algo fiável.
Os benefícios são reais quando a base está implementada. A parte difícil é o investimento inicial na infraestrutura partilhada e na documentação preparada para agentes. As equipas que ignoram essa etapa conseguem uma demonstração apelativa e depois veem-na desmoronar-se à medida que a complexidade aumenta. As equipas que fazem esse trabalho obtêm uma execução genuinamente rápida e paralela em design, produto e engenharia.
Como a IA altera os modelos tradicionais de gestão de projetos
O modelo em cascata tradicional simplesmente já não funciona. A gestão de projetos tradicional era implacavelmente linear: o primeiro passo conduzia ao segundo e depois ao terceiro, com transferências rígidas entre disciplinas. O produto escrevia a especificação, o design criava os modelos, a engenharia desenvolvia-os e, depois, o design revia o acabamento — cada etapa aguardava pela anterior.
Essa cadeia linear desfez-se, o que é algo maravilhoso. As etapas são agora intercambiáveis e as fronteiras entre design, engenharia e produto esbateram-se. Por exemplo, os designers já incorporaram diretamente o sistema de design na base de código — os componentes certos, os layouts e os tokens de cor específicos. A engenharia pode então desenvolver um fluxo completo de uma funcionalidade e o design corrige todos os problemas da interface diretamente no código para concluir o acabamento. Ninguém está à espera de uma transferência do Figma. O design está a trabalhar no mesmo meio que a engenharia.
O mesmo esbatimento acontece a montante. A equipa de produto pode redigir muitos mais PRDs em paralelo, desbloqueando a engenharia. A engenharia pode gerar documentos de conceção técnica aprofundados e detalhados sem que o produto tenha de aprovar cada passo, porque a IA permite que cada disciplina produza trabalho que anteriormente exigia um especialista.
Agora, diferentes membros da equipa podem assumir diferentes partes do trabalho. Assim, em vez de uma corrida de estafetas linear, em que os testemunhos caem a cada passagem, surge uma equipa pequena e com elevada autonomia, na qual todos podem avançar para áreas adjacentes para desbloquear o trabalho.
Na prática, isto significa privilegiar sistemas leves em detrimento de processos pesados: menos reuniões de ponto de situação e etapas de aprovação, mais protótipos funcionais. Os PRDs e os documentos de conceção técnica são gerados rapidamente e tratados como artefactos vivos, em vez de especificações imutáveis. Uma base de código partilhada — com o sistema de design incorporado — funciona como a única fonte de verdade, onde produto, design e engenharia se encontram.
O resultado é velocidade — as equipas validam a visão através da construção, em vez da coordenação, e entregam um produto aperfeiçoado que anteriormente exigia vários ciclos de passagem, numa fração do tempo.
Porque é que a IA não pode eliminar a necessidade de rituais de projeto
Todos os rituais habituais continuam a existir e vários tornam-se ainda mais importantes com a IA, e não menos. As pessoas assumem erradamente que construir mais depressa significa uma disciplina mais relaxada. A verdade é precisamente o contrário.
Definir o âmbito continua a ser tão importante como sempre. Uma equipa continua a precisar de uma definição absolutamente clara do que está a tentar construir. O que mudou foi aquilo que se torna possível dentro desse âmbito. Se uma equipa construir de forma eficiente com IA, muitas coisas que tinham baixa prioridade ou que ficavam eternamente presas num backlog podem agora ser priorizadas e lançadas. Assim, é possível construir um produto mais relevante e mais completo do que antes. A ambição do âmbito pode crescer, mas a necessidade de o definir claramente mantém-se.
As equipas continuam a precisar de alinhamento total. As partes interessadas continuam a precisar de alinhamento. Ao trabalhar entre várias equipas, é necessário continuar a alinhar deliberadamente tanto dentro da própria equipa como entre essas equipas. A IA não alinha as pessoas por si.
Validar o trabalho é ainda mais importante. Ao construir numa grande empresa, os seus produtos chegam a milhões de pessoas, e não apenas a dezenas ou centenas de utilizadores. Os produtos continuam a ter de ser excelentes, funcionar muito bem e apresentar um bom desempenho a essa escala. O facto de a IA ajudar a construir mais depressa não reduz esse padrão. Por isso, a validação continua a ser inegociável.
O que mudou é que o processo já não é tão difícil nem tão lento. Os próprios rituais — um âmbito claro, um alinhamento real e uma validação rigorosa — continuam a ser verdadeiros e tornam-se ainda mais importantes. Precisamos de repensar os processos que tradicionalmente dificultam uma execução mais rápida. A IA permite reduzir a cerimónia e a fricção em torno destes rituais, protegendo simultaneamente a sua substância.
Porque é que o discernimento se tornará ainda mais importante nas organizações que colocam a IA em primeiro lugar
A curto prazo, mais empresas tecnológicas irão adotar IA no desenvolvimento e na entrega de produtos de ponta a ponta. A previsão mais arrojada, contudo, diz respeito ao passo seguinte da sua expansão. A IA não ficará confinada à tecnologia. Expandir-se-á para grandes empresas, depois para empresas não tecnológicas e, por fim, para negócios tradicionais.
Quando estes ganhos passarem dos indivíduos para pequenas equipas e depois para organizações inteiras, o efeito dinamizador irá transformar radicalmente as equipas e os fluxos de trabalho. A estrutura de formação das equipas de entrega e a forma como o trabalho flui através delas serão muito diferentes da atual.
Mas a importância de tomar boas decisões não desaparecerá; na verdade, tornar-se-á mais importante porque agora tomamos decisões com muito mais frequência. Quando a entrega global era lenta, tomavam-se apenas algumas decisões fundamentais, talvez uma vez a cada poucas semanas ou meses. Agora, é necessário tomar decisões de elevada qualidade várias vezes por dia, por vezes várias vezes por hora.
O desenvolvimento orientado por IA tem de ser adotado tanto de cima para baixo como de baixo para cima.
Por conseguinte, o foco tem de passar para a tomada de decisões humanas. Cada área de especialização terá de definir um conjunto claro de perspetivas através das quais cada decisão possa ser analisada, permitindo decisões mais precisas e rápidas. Igualmente importante, essas decisões têm de ser registadas para que os agentes as compreendam e possam consultá-las posteriormente.
As equipas vencedoras tratarão o discernimento humano de alta qualidade e bem documentado como um recurso escasso, porque a IA o torna simultaneamente mais frequente e mais valioso.
Porque é que os líderes de entrega têm de adotar a IA e incentivar a experimentação
O ponto fundamental é que o desenvolvimento orientado por IA tem de ser adotado tanto de cima para baixo como de baixo para cima. Não pode ser apenas uma coisa ou outra.
A vertente de cima para baixo exige o compromisso da liderança. Se a liderança sénior não aderir, não experimentar e não tentar alterar os seus próprios fluxos de trabalho e sistemas de entrega, será muito difícil para a organização adotar a IA de forma significativa. Não é possível impor uma transformação que não se está a viver pessoalmente. Os líderes que delegam a IA numa equipa de trabalho, mantendo inalteradas as suas próprias formas de trabalhar, transmitem um sinal claro de que isto é opcional, e a organização interpreta esse sinal corretamente. Por isso, o meu primeiro conselho aos meus colegas líderes de entrega é que alterem primeiro os seus próprios fluxos de trabalho, antes de pedirem a qualquer outra pessoa que altere os seus.
A vertente de baixo para cima é igualmente importante. Os colaboradores mais jovens e as equipas individuais têm de ter liberdade para experimentar, desafiar convenções e questionar os fluxos de trabalho existentes. Precisam de espaço para experimentar, questionar a forma como a entrega sempre foi feita e, depois, chamar a atenção da liderança para aquilo que aprenderam. Se esse canal não existir, se as pessoas não tiverem essa liberdade e as suas conclusões nunca chegarem aos níveis superiores, então tudo se desmorona tão seguramente como quando a liderança está ausente.
A coisa mais útil que um líder de entrega pode fazer neste momento é assegurar ambas as pontas em simultâneo. Liderar pela frente, repensando visivelmente os seus próprios sistemas de entrega, e, ao mesmo tempo, criar condições para que as suas equipas experimentem livremente e lhe apresentem aquilo que funciona. Tem de ser tanto de cima para baixo como de baixo para cima.
Quando apenas uma das pontas se envolve, a adoção fica estagnada. Quando ambas se envolvem, a mudança consolida-se.
Acompanhe
Pode acompanhar o trabalho de Anshumani Ruddra no LinkedIn. Pode também consultar o seu blogue e os seus cursos.
Em breve haverá mais entrevistas com especialistas no The Digital Project Manager!
