
O vice-presidente de Produto da Amex afirma que a IA deve ser integrada gradualmente nas organizações de produto — saltar uma única etapa vai custar-lhe caro

Abishek (Abhi) Gandotra
Vice-presidente de Produto na American Express

Abhi Gandotra explica por que motivo a adoção da IA deve avançar por etapas e por que razão o discernimento, os padrões partilhados e bases sólidas se tornam ainda mais importantes à medida que a construção se acelera.
Abishek (Abhi) Gandotra
Vice-presidente de Produto na American Express

Key Takeaways
Prototipagem com IA: A prototipagem com IA permite às equipas de produto testar ideias funcionais em poucos dias, substituindo debates abstratos por evidências de utilizadores reais.
Discernimento Humano: À medida que a IA reduz os custos de construção, a definição de prioridades, a avaliação de riscos e a decisão sobre o que não construir tornam-se responsabilidades fundamentais do produto.
Realidade Regulamentada: Na banca, os protótipos continuam a exigir controlos, registos de auditoria, tratamento de exceções, análise de conformidade e integrações fiáveis com sistemas legados antes do lançamento.
Percurso de Maturidade: A adoção bem-sucedida da IA evolui da produtividade para a eficiência, a inteligência e a autonomia, exigindo cada fase bases mais sólidas.
Mudança na Liderança: Os diretores de produto devem desenvolver literacia em IA, reforçar a especialização no domínio e utilizar uma experimentação mais rápida para fazer menos apostas estratégicas, mas melhores.
Abishek (Abhi) Gandotra começou a sua carreira como engenheiro, mas transitou para a área de produto — levando consigo os seus conhecimentos técnicos. Atualmente, é VP de Produto na American Express. É também o autor de O Agente Soberano.
Juntou-se a nós para partilhar o que está a aprender à medida que a IA esbate ainda mais as fronteiras entre engenharia e produto. Foi isto que nos contou.
Da engenharia ao produto
Sou Abhi Gandotra e lidero a área de produto da Plataforma Bancária na American Express. Comecei como engenheiro, passando a primeira década da minha carreira a escrever código. Consequentemente, nunca tratei a tecnologia como uma caixa negra. Quando algo não é lançado, quero saber porquê — na camada onde falha.
Transitei para a área de produto porque me preocupava menos em construir as coisas corretamente e mais em construir as coisas certas. Na Green Dot, passei mais de uma década a desenvolver uma plataforma de banca como serviço — levámo-la de uma ideia a mais de 1B$ em receitas B2B, através de mais de 80 parceiros empresariais. Isso ensinou-me aquilo em que ainda acredito: as plataformas vencem quando tornam fáceis os problemas difíceis dos outros. Agora, na Amex, faço isso pela infraestrutura bancária e de pagamentos, a uma escala diferente e com o nível regulamentar correspondente.
Para mim, o momento da IA não é apenas entusiasmo passageiro. Estou a lançar produtos com estas ferramentas neste momento — a criar agentes, a implementar um programa de capacitação em IA em toda a minha área e a liderar pequenas equipas que passam da ideia ao software funcional em poucos dias. Os meus instintos de engenheiro regressaram por completo. A distância entre "tenho uma ideia" e "está a funcionar" nunca foi tão curta. É essa a parte que considero entusiasmante — não o entusiasmo passageiro, mas a velocidade.
More Articles
Liderar o produto a partir da camada de infraestrutura
Como referi, lidero a área de produto da Plataforma Bancária na American Express — a plataforma de banca digital e pagamentos que sustenta as nossas experiências de banca para consumidores e empresas. É a camada de infraestrutura: os canais, as capacidades de conta e movimentação de dinheiro e os controlos que suportam todos os elementos voltados para o cliente.
Os nossos "utilizadores" dividem-se em dois públicos distintos: os clientes finais, que experienciam o produto como os seus serviços bancários e de pagamentos, e as equipas internas de produto e engenharia, que desenvolvem sobre a nossa plataforma. O trabalho de plataforma exige servir simultaneamente quem desenvolve e os utilizadores finais — se otimizarmos apenas para um deles, o outro fica prejudicado.
Operamos à escala e com o nível regulamentar esperados de uma instituição financeira com mais de cem anos, o que significa que a fiabilidade e a conformidade não são funcionalidades, mas requisitos básicos. O nosso modelo de entrega combina produto e engenharia internos com parceiros tecnológicos essenciais, pelo que desempenho sobretudo um papel de orquestração — alinhando os roteiros internos com as capacidades externas e os controlos exigidos pelas nossas equipas de risco e conformidade.
Como a IA transfere a prototipagem da engenharia para o produto

A maior mudança que fiz foi deixar de tratar a prototipagem como um pedido à engenharia e passar a tratá-la como uma capacidade do produto.
Há um ano, validar uma ideia nova significava redigir um documento, adicioná-la a uma lista de tarefas pendentes e esperar semanas pela disponibilidade da engenharia para construir algo que os utilizadores ou parceiros pudessem avaliar. Agora, lidero pequenas equipas que passam do conceito ao software funcional em poucos dias — utilizando ferramentas de programação com IA para criar um protótipo funcional com base num SDK real, e não numa simulação interativa. Numa iniciativa recente, uma integração com um sistema de processamento salarial, uma pequena equipa criou e testou uma integração funcional no tempo que anteriormente demorávamos apenas a alinhar os requisitos.
Isto mudou a forma como tomamos decisões. Quando se consegue apresentar software funcional a um parceiro ou interveniente em poucos dias, a conversa deixa de ser abstrata — estamos a debater algo real, com limitações reais, em vez de discutir uma apresentação. Isso eliminou grande parte da paralisia por análise que costumava consumir a fase inicial do nosso roteiro. E, com os gestores de produto da minha equipa a definir o âmbito e a criar eles próprios os protótipos, o tempo da engenharia é dedicado ao que realmente precisa dele.
Agora, a parte difícil não é construir. É avaliar o que merece ser construído. O bom discernimento e a priorização são os recursos escassos. É nessa mudança que estou mais focado enquanto líder.
Um fluxo de trabalho realista, da ideia ao protótipo
Eis o nosso fluxo de trabalho generalizado, da ideia ao protótipo funcional, comprimido de semanas para dias.
- Enquadrar o problema: Começa por ser humano — uma necessidade de um parceiro ou uma lacuna que identificámos. Uso um assistente de IA como parceiro de reflexão para testar rigorosamente o enquadramento: para quem se destina, qual é realmente o trabalho a realizar e o que faria com que não valesse a pena desenvolvê-lo? Isto torna a questão mais precisa antes de começar o desenvolvimento.
- Sintetizar os contributos: Direcionamos a IA para o material relevante — investigação, temas de suporte, panorama competitivo e contexto interno anterior — e obtemos uma visão sintetizada em minutos, em vez de dias. Uma pessoa revê-a para identificar o que o modelo não detetou ou sobrevalorizou; a síntese é um ponto de partida, não a decisão final.
- Criar um protótipo funcional: Esta é a maior mudança. Em vez de escrever uma especificação e esperar pela disponibilidade da equipa de engenharia, uma pequena equipa utiliza ferramentas de programação com IA para criar software funcional com uma interface real — não um modelo simulado clicável, mas algo que funciona. Dias, não semanas.
- Colocá-lo perante as pessoas: Apresentamos o protótipo funcional aos intervenientes ou a um parceiro numa fase inicial. Como é real, o feedback é genuíno — discutimos o comportamento e os casos-limite, em vez de reagirmos a uma apresentação.
- Decidir com discernimento: Aqui, a IA recua. Decidir se investimos mais, como se enquadra no roteiro e quais são as implicações em termos de controlos e conformidade — estas são decisões humanas, com uma responsabilização clara por conceção.
Começa por ser humano. Decidir se investimos mais, como a IA se enquadra no roteiro e quais são as implicações em termos de controlos e conformidade — estas são decisões humanas, com uma responsabilização clara por conceção.

Porque tem de mudar o âmbito de intervenção dos PM
Por isso, tenho vindo a redefinir ativamente o âmbito da responsabilidade dos PM, os pontos de transição entre produto e engenharia e — de forma crítica — o nível de qualidade exigido aos artefactos criados pelos PM que chegam à produção.
No momento em que um PM consegue disponibilizar algo de ponta a ponta, é necessário responder a novas perguntas que o modelo anterior nunca nos obrigou a fazer. Pelo que é agora responsável um PM que não era antes? Em que áreas é que o discernimento da engenharia continua a ter de validar o trabalho e em que áreas apenas o torna mais lento? O que significa estar "pronto para produção" quando a pessoa que o criou não é engenheira?
O meu foco é a coerência, não disponibilizar mais depressa por si só. Dar a todos o poder de criar comporta o risco de cada pessoa criar a sua própria versão de tudo, fragmentando a organização em silos competentes que não acumulam valor. Por isso, a reformulação diz tanto respeito a bases partilhadas e a um padrão de qualidade comum como a capacitar os PM. Quando bem executas, as equipas avançam muito mais depressa e desenvolvem o trabalho umas das outras, em vez de trabalharem à volta umas das outras.
Porque deve a IA gerar opções enquanto as pessoas aplicam o seu discernimento

A IA é excelente a gerar opções; as pessoas têm de continuar a assumir o discernimento, especialmente no setor bancário regulamentado.
Recorro à IA para:
- Descoberta e síntese: extrair informação relevante da investigação, dos pedidos de suporte, do feedback dos parceiros e do panorama competitivo muito mais depressa do que uma pessoa conseguiria ler tudo.
- Prototipagem e experimentação: criar software funcional para testar uma ideia, em vez de a discutir.
- O primeiro rascunho de quase tudo: requisitos, análises e estudos de mercado.
A IA permite-nos chegar a um ponto de partida credível — algo que costumava ocupar a maior parte do nosso tempo — em minutos.
Mantenho explicitamente sob responsabilidade humana:
- Priorização e decisões sobre o roteiro: a IA pode apresentar os compromissos, mas decidir o que vamos desenvolver — e o que deliberadamente não vamos desenvolver — exige discernimento sobre a estratégia, a apetência pelo risco e os nossos clientes, algo que não estou disposto a delegar.
- Tudo o que envolva decisões regulamentares ou de risco: no nosso mundo, "o modelo sugeriu-o" não é uma resposta que se possa dar a um regulador.
- As decisões difíceis relativas a pessoas e intervenientes: refiro-me à capacidade de interpretar o ambiente e gerir prioridades concorrentes entre parceiros. Estas decisões são irredutivelmente humanas.
Como a IA traz rapidez e excesso de confiança
A vantagem mais evidente está na rapidez no início do ciclo de vida:
- Os ciclos de prototipagem que costumavam demorar semanas agora demoram dias, o que significa que testamos mais ideias e eliminamos as más mais cedo — antes de consumirem capacidade real de engenharia.
- Os meus PMs conseguem agora analisar pesquisas, feedback do suporte e análises da concorrência numa fração do tempo, pelo que chegam mais bem preparados às conversas de definição de prioridades.
- Os PMs que não conseguiam lançar nada sem um engenheiro conseguem agora criar sozinhos um protótipo funcional. Isso muda a dinâmica da equipa. As pessoas sentem-se novamente mais como criadores.
Mas aprendemos da pior maneira que os resultados da IA são apresentados com confiança mesmo quando estão errados, e isso é perigoso num ambiente regulamentado. No início, um protótipo parecia suficientemente aperfeiçoado para criar uma falsa sensação de confiança sobre quão perto estávamos de algo real. A demonstração funcionava, mas os difíceis 20% — os casos extremos, os controlos e a lógica de conformidade — estavam completamente por tratar.
A lição foi que a IA reduz de tal forma o custo dos primeiros 80% que as equipas subestimam os 20% restantes, que é onde reside toda a dificuldade na banca. Agora separamos explicitamente aquilo que "parece concluído" daquilo que "está concluído" e estabeleci como norma que uma demonstração funcional é o início da conversa difícil, não o fim.

Reflexões de Abhi
A lição foi que a IA reduz de tal forma o custo dos primeiros 80% que as equipas subestimam os 20% restantes, que é onde reside toda a dificuldade na banca. Agora separamos explicitamente aquilo que “parece concluído” daquilo que “está concluído,” e estabeleci como norma que uma demonstração funcional é o início da conversa difícil, não o fim.
A distância entre a demonstração e o valor do produto
Existe uma grande distância entre a magia de uma demonstração e o valor duradouro de um produto. A IA é excelente no impressionante momento de passar do zero a um, mas desilude consistentemente no trabalho pouco glamoroso que gera impacto sustentado.
Alguns exemplos concretos:
- A "última milha" nos fluxos de trabalho regulamentados: A IA disponibiliza rapidamente um protótipo funcional, mas, na banca, o valor não está no percurso ideal — está nos controlos, nos registos de auditoria, no tratamento de exceções e na lógica de reconciliação. A IA não acelerou significativamente essa parte. Esperava que reduzisse o tempo de todo o desenvolvimento; apenas reduziu o tempo da primeira metade. A segunda metade continua tão difícil como sempre e é aí que reside a maior parte do valor real do produto.
- Integração com a realidade dos sistemas legados: Grande parte do valor de uma plataforma provém da forma eficiente como é integrada nos sistemas existentes — APIs de parceiros, processadores centrais e serviços internos com décadas de existência. As ferramentas de IA são excelentes em ambientes criados de raiz, mas enfraquecem visivelmente assim que encontram as nossas limitações reais. O trabalho de integração confuso e exigente em termos de contexto, que define a engenharia de plataformas no mundo real, é precisamente aquele em que menos ajudam.
- Qualidade das decisões ao nível da estratégia: Esperava que a síntese feita pela IA tornasse mais rigorosa a nossa definição de prioridades. Tornou-nos mais rápidos e mais bem informados, mas não facilitou as decisões difíceis — porque as decisões difíceis nunca tiveram que ver com falta de informação; tiveram que ver com convicção, compromissos e apetite pelo risco. A IA deu-nos mais análise; não nos deu mais clareza. Foi útil corrigir essa expectativa.
Porque é que a integração da IA deve ser uma progressão passo a passo

Não é possível saltar as camadas inferiores. O instinto com a IA — especialmente com os modelos capazes de hoje — é avançar diretamente para o estado final impressionante: o sistema autónomo, o agente que atua por si próprio. Aprendi que é preciso merecer chegar lá. Tentar atalhar o caminho sai caro.
Agora penso nisso como uma progressão de maturidade. A capacidade da IA em qualquer contexto operacional sério evolui por etapas — primeiro a produtividade (tornar o trabalho existente mais rápido), depois a eficiência (automatizar passos rotineiros), depois a inteligência (obter conhecimentos mais profundos e apoio à decisão) e só então a autonomia (sistemas que atuam por si próprios). Cada camada depende da que está abaixo. Não é possível implementar um agente fiável numa plataforma que ainda não consegue observar-se a si própria, disponibilizar a sua própria configuração ou mostrar por que motivo tomou uma decisão. Autonomia sem observabilidade não é sofisticação — é risco que não se consegue ver.
Se tivesse percebido isto mais cedo, teria evitado a tentação de prometer em excesso o topo da pilha antes de a base estar consolidada. A demonstração mais ambiciosa cativa-nos facilmente porque entusiasma toda a gente. Mas uma capacidade autónoma vistosa assente numa base imatura falha de formas difíceis de diagnosticar e corrói rapidamente a confiança — e a confiança, quando é gasta num sistema que agiu de forma errada, é dispendiosa de reconstruir.
Por isso, diria a qualquer pessoa que esteja a lançar o seu primeiro produto orientado por IA: seja honesto sobre a camada em que está, forneça valor real nessa camada e deixe que as capacidades de nível superior conquistem o seu lugar. A sequência é o essencial.
Como os CPO podem otimizar para a escassez certa
De um modo geral, o meu conselho é deixar de otimizar para a escassez errada.
Durante a maior parte das nossas carreiras, o estrangulamento estava na produção — conseguir criar as coisas. Por isso, organizámos tudo em torno da capacidade de produção: listas de pendências, planeamento de capacidade, lançamentos mais rápidos. A IA acabou simplesmente com esse estrangulamento. O custo de gerar uma opção, um protótipo, um rascunho ou uma análise está a aproximar-se de zero. E quando uma restrição desaparece, uma nova passa a ser o fator relevante.
O novo recurso escasso é o discernimento — saber o que vale a pena criar, a que dizer não, o que significa algo ser «bom» e o que os resultados confiantes da IA estão discretamente a fazer mal. Por isso, o meu conselho tem três partes:
- Invista o seu dividendo da IA em discernimento, não apenas em velocidade: O objetivo de avançar mais depressa não é lançar mais coisas — é conseguir mais oportunidades para poder ser mais seletivo. Se a IA apenas o fizer criar mais rapidamente as coisas erradas, terá agravado o problema, não o melhorado.
- Mantenha-se próximo da prática: Os líderes que terão dificuldades serão aqueles que encaram isto como uma decisão de ferramentas de outra pessoa. Crie algo por si próprio. Não pode liderar uma equipa durante uma mudança sobre a qual apenas leu — os seus instintos estarão calibrados para um mundo que já não existe.
- Aprofunde o conhecimento do seu domínio, em vez de o tornar mais vago: Atualmente, todos têm acesso à mesma IA de uso geral. A sua vantagem não está no modelo — está no conhecimento específico, conquistado com esforço, dos seus clientes, da sua realidade regulamentar e do seu negócio. A IA transforma o que é genérico numa mercadoria e torna o que é específico mais valioso. Aposte naquilo que é seu.
Este momento recompensa o bom gosto e a convicção, mais do que a informação e o esforço. Isso é desconfortável, porque controla o esforço e tem de desenvolver o bom gosto. Mas os líderes que interiorizarem isso cedo serão os que irão acumular vantagens.
Acompanhe
Pode acompanhar o trabalho de Abhi Gandotra no LinkedIn e no seu site. Ou consultar o seu livro, O Agente Soberano.
Em breve, haverá mais entrevistas com especialistas no The CPO Club!



