A hipótese mais simples que aparece de imediato na mente seria: se a gente expor o clube no checkout vai gerar mais assinaturas > assinaturas aumentam recorrência > recorrência melhora o LTV.

A sequência parece razoável, tem lógica, é simples mas ainda não explica se colocar a oferta no checkout melhora o negócio.

A nova decisão pode aumentar adesões ao clube e, ao mesmo tempo, derrubar a conversão da compra principal. Também pode atrair clientes pelo desconto, gerar churn precoce e reduzir margem em pedidos que aconteceriam de qualquer forma.

Uma Causal Tree serve para ir além, ela transforma uma promessa vaga de impacto em uma cadeia de condições que podem ser medidas, testadas e contestadas.

Os PMs mais sênior que eu conheço, usam esse framework de maneira natural, o que faz eles sairem de: “essa feature deve aumentar receita” para “estes comportamentos precisam mudar, nesta ordem, sem piorar estes guardrails, para que a receita líquida aumente”.

O modelo simples segue esta ordem:

intervenção de produto > mudança de comportamento > métrica líder > resultado de produto > resultado de negócio > guardrails

Vamos nos aprofundar agora…

Mudanças esperadas no comportamento do usuário ao acessar o checkout:

O cliente entende que o clube gera uma economima naquela compra e considera assinar.

Métricas de acompanhamento: % de clientes expostos que abrem os detalhes, % que seleciona a assinatura, tempo adicional criado no checkout, abandono após a exposição.

Clientes que concluem os pedidos junto com adesão ao clube.

Métricas de acompanhamento: adesão líquida ao Clube, conversão do checkout entre expostos e não expostos, pedidos pagos e não cancelados, aprovação de pagamento, receita líquida da primeira compra.

A “adesão líquida” importa porque se você não considerar isso a feature pode ter conquistado 500 assinantes e provocado 700 abandonos de carrinho, ou seja, a feature teve boa adoção mas o resultado financeiro ruim.

Aumento de frequência de compra pelos clientes que tem clube e também a retenção deles. (cenário feliz e o que a empresa quer)

Métricas de acompanhamento: segunda compra em 30, 60 e 90 dias, ticket médio, churn do Clube, margem depois de descontos e frete e contatos ao suporte e pedidos de cancelamento.

Os benefícios que o clube oferecem tornam a feature mais atraente para o cliente, mas também entram diretamente na economia unitária de uma compra. Ela só cria valor quando ela gera frequência adicional e a retenção compensam todo o custo.

Esse acompanhamento deve ser feito com teste a/b, com uma exposição do clube controlada e uma análise que separa quem recebeu a oferta do clube no checkout de quem não recebeu, com acompanhamento por tempo suficiente para identificar a quantidade de recompra e cancelamento.

Parece complicado né?

Para quem não está acostumado isso leva tempo, tanto de carreira como de horas para pensar e desenhar essas causas. Por isso criei uma skill que te ajuda a criar uma Casual Tree de maneira eficiente e estratégica, sem ser genérica baseada no contexto que você der, e se precisar de mais informações ele pede.

Por exemplo, você falararia o objetivo de negócio, qual jornada que você é responsável, o seu backlog atual, baseline que você tem disponível e possíveis restrições e guardrails importantes. Com isso, a skill não necessariamente vai criar uma causal tree, ela vai rotear entre os 27 frameworks e dado tudo que você mencionou escolher a que melhor para o seu contexto e se necessário fará perguntas, te ajudando a estruturar melhor.

No exemplo do petlove que vimos agora, a skill perceberia que aumentar adesões ao clube é uma camada intermediária e perguntaria sobre conversão, recompra, churn, desconto, frete e atendimento para devolver um output com hipótese causal por iniciativa, métricas líderes e de resultado, relações que ainda são apenas suposições, dados que precisam ser intrumentados, desenho inicial dos experimentos e itens do backlog sem conexão com o negócio.

Acesso à PM Especialista

Assinantes pagos da newsletter têm acesso imediato à skill completa, com o roteador central, os 27 arquivos de referência e os frameworks para priorização, discovery, estratégia, métricas, posicionamento, comunicação executiva, produto de IA, influência e carreira.

Neste episódio, Paulo Chiodi conversa com Isabela Chitolina, Staff Product Manager no Mercado Livre e professora de AI Product Builder na PM3, sobre os critérios que deveriam orientar qualquer iniciativa de inteligência artificial.

Isabela explica como avaliar a solução mais simples, calcular o ROI de projetos de IA e considerar o time to market antes de iniciar o desenvolvimento. Ela também conta como ajudou a reduzir um processo de dois meses para duas semanas, sem tratar IA como resposta automática para todas as etapas.

A conversa passa pela falsa confiança nos outputs dos modelos, pelo erro de medir produtividade por consumo de tokens, pela decisão entre build, buy ou partner e pelos casos em que construir um modelo proprietário custa mais do que o valor que ele entrega.

Conecte-se com Isabela Chitolina: https://www.linkedin.com/in/isabela-chitolina/?locale=pt

🎧 Assista no YouTube ou Spotify.

Você também vai entender:

• O que significa ser um Product Builder

• Como separar um problema real do hype da diretoria

• Como calcular o retorno de iniciativas de IA

• Por que consumo de tokens não representa produtividade

• Quando uma automação simples resolve melhor

• Os riscos de confiar cegamente nas respostas da IA

• Quando um modelo proprietário pode fazer sentido

• Por que a adoção deveria começar nos processos internos

Conheça as soluções mencionadas no episódio:

PM3: https://productgurus.short.gy/HBiSmt
Deel Global Badges: https://productgurus.short.gy/pPAeWy
Revelumi: https://productgurus.short.gy/miSFA2

Inscreva-se no Product Guru’s e acompanhe conversas sobre produto, inteligência artificial, tecnologia e negócios.

🔥 Indicação de conteúdo extra:

Falando parece simples, mas muitos sênior tem dificuldades de fazer isso por muitos motivos, entre eles: não saber como faz e também a falta de tempo para pensar e desenhar essa conexão de maneira clara.

A skill que eu criei consegue ajudar nisso de maneira simples, contextualizada e explicativa para que no fim você consiga entender e aprender.

O mais importante é que ela só vai fazer isso se realmente for pedido e se isso for necessário, devido ao roteador.

Exemplo: você é uma PM do Petlove que cuida do checkout e tem como objetivo aumentar pedidos pagos e mantidos, reduzindo abandono sem ampliar fraude, cancelamento ou custo operacional.

A métrica de negócio mais próxima seria poderia ser: pedidos pagos e não cancelados por sessão de checkout.

O seu backlog já conta com:

1. Recuperação de pagamento recusado.
2. Preenchimento automático de endereço.
3. Exibição antecipada de frete e prazo.
4. Checkout sem login.
5. Oferta de assinatura no checkout.

Ao pedir para a skill ajuda para conectar, ela vai pedir contexto, porque ela não vai tratar todas as iniciativas como equivalentes para gerar uma priorização e consequentemente um roadmap conectado ao negócio.

Problema do usuário —> Mudança esperada —> Métrica líder —> Outcome de produto —> Métrica de negócio —> Guardrail

Primeiro ela vai separar as features que possuem uma cadeia causal curta até o resultado das que dependem de várias

suposições intermediárias.

Exemplo do PetLove:

• Métrica de negócio: pedidos pagos e mantidos.

• Métrica líder: avanço entre etapas do checkout, taxa de aprovação do pagamento e recuperação após recusa.

A distinção principal é esta:

• Métrica líder mostra o movimento que deveria causar o resultado.

• Métrica de resultado mostra o efeito final.

Uma boa métrica líder precisa ser próxima da ação do time, mudar com rapidez e ter relação causal plausível com o resultado. O risco é tratar qualquer número intermediário como líder, é por isso que é imporante fazer sempre teste a/b. Se aumentar CTR e nada mudar em pedido, receita ou retenção, o time apenas produziu mais cliques.

Acesso à PM Especialista

Assinantes pagos da newsletter têm acesso imediato à skill completa, com o roteador central, os 27 arquivos de referência e os frameworks para priorização, discovery, estratégia, métricas, posicionamento, comunicação executiva, produto de IA, influência e carreira.

Parecia suficiente. O Claude teria acesso a RICE, Jobs to Be Done, Opportunity Solution Tree, LNO, Playing to Win, North Star, pré-mortem, posicionamento e outros métodos. Bastaria jogar uma situação ou pergunta e esperar que ele encontrasse a resposta certa por meio de algum framework.

O resultado foi confuso. Ele misturava tudo em uma resposta só.

Diante de uma dúvida sobre priorização, citava impacto no usuário, alinhamento estratégico, esforço, risco, discovery e métricas. Às vezes mencionava RICE. Em outras, sugeria Kano, valor versus esforço ou uma combinação de vários métodos. A resposta ficava longa, cuidadosa e difícil de contestar tecnicamente.

Quando tudo parece relevante, nada ajuda a decidir o próximo passo.

Esse teste me fez mudar a estrutura da skill e começar um trabalho de curadoria. Reunir bons frameworks ampliava o repertório do modelo sem melhorar necessariamente sua capacidade de decidir. Algo parecido acontece na carreira de um product manager.

Em alguns casos, o resultado piorava. Quanto mais conceitos estavam disponíveis, mais fácil ficava produzir uma resposta que abordava tudo sem escolher nada.

A PM Especialista passou a ter um roteador central e 27 arquivos de referência. Antes de responder, a skill identifica o tipo de problema, escolhe quais arquivos consultar e deixa o restante de fora.

Onde os frameworks atrapalham

Frameworks são especialmente convincentes quando faltam dados.

O RICE transforma quatro estimativas incertas em um número. Duas casas decimais depois, uma hipótese sobre alcance parece ter a mesma consistência de uma métrica observada.

A regra que tentei criar na skill é não preencher essas lacunas. Quando faltam dados sobre alcance, impacto, confiança ou esforço, ela deve pedi-los ou trabalhar com cenários explícitos. A mesma regra vale para análises de product-market fit, North Star e outros métodos.

Frameworks não corrigem uma definição ruim. Às vezes, só dão a ela um nome conhecido.

Abandonei a ideia de manter todos os frameworks disponíveis o tempo todo por um motivo simples. Uma biblioteca funciona bem para quem já sabe o que procura, mas ajuda pouco quem ainda está tentando formular o problema. Antes de aplicar um método, o modelo precisa entender qual decisão está em jogo.

Como eu usaria a skill

O uso mais direto é levar uma decisão concreta, com números e restrições.

Temos capacidade para uma iniciativa no trimestre. Compare estas três opções, escolha um método de priorização, diga quais dados estão fracos e recomende uma delas.

Também serve para analisar um documento que já parece resolvido.

Leia este PRD e me diga qual premissa sustenta o maior número de decisões e tem menos evidência. Escolha uma forma de testá-la.

Para analisar um roadmap:

Classifique os itens pelo modelo LNO e mostre onde a pressão de stakeholder foi registrada como impacto de produto.

Ou revisar um posicionamento:

Aplique o método de April Dunford e identifique qual alternativa o cliente usa hoje, mas não aparece neste documento.

A resposta ainda depende do contexto enviado, assim como no dia a dia de qualquer PM. A skill não tem acesso ao caixa da empresa, à qualidade dos dados, às promessas feitas pelo comercial ou à relação entre os executivos. Se essas informações influenciam a decisão, precisam aparecer no contexto.

Mesmo com esses cuidados, ainda existe um risco que não dá para eliminar. Depois de escolher uma direção, alguém pode procurar entre os 27 frameworks aquele que melhor serve para justificá-la.

Acesso à PM Especialista

Assinantes pagos da newsletter têm acesso imediato à skill completa, com o roteador central, os 27 arquivos de referência e os frameworks para priorização, discovery, estratégia, métricas, posicionamento, comunicação executiva, produto de IA, influência e carreira.

Subscreva agora

Ali fica claro que a IA deixa de ser o problema muito antes do que imaginamos. Conforme Claude Code, Cursor e outros agentes passam a produzir software em quantidade suficiente, o gargalo sobe de camada e vai migrando da tecnologia para a organização.

No primeiro estágio, chamado de Gated, a empresa ainda trata IA como infraestrutura. A discussão gira em torno de SSO, SCIM, gateways internos, aprovação de segurança, orçamento por token e políticas de acesso. Claude pode até existir, mas quase ninguém consegue usá-lo sem abrir chamados ou esperar autorização. O bloqueio não está no modelo, está na empresa.

Quando essas barreiras caem, o trabalho muda rapidamente de natureza.

No estágio Assisted, um engenheiro trabalha com um agente quase como faria com outro desenvolvedor. Boris descreve um cenário familiar para quem já usa Claude Code, Cursor ou GitHub Copilot diariamente: uma tarefa que antes ocupava uma tarde inteira pode ser concluída entre duas reuniões. O problema é que praticamente todo o ganho desaparece quando cada resposta precisa ser revisada antes do merge.

Achei interessante perceber que esse já é o principal comentário que escuto de equipes maduras. Quase ninguém reclama da capacidade do modelo produzir código, a reclamação mudou para “ainda preciso conferir tudo”. O gargalo deixou de ser geração e passou a ser confiança.

É justamente aí que acontece a primeira mudança de profissão.

No estágio Parallel, um engenheiro deixa de conversar com um único agente e passa a coordenar cinco ou dez deles ao mesmo tempo, cada um trabalhando em uma worktree diferente, executando testes, build, lint e revisão automática antes de apresentar qualquer resultado. O desenvolvedor continua responsável pela decisão final, mas já não acompanha cada linha escrita. Ele passa a revisar diferenças consolidadas enquanto distribui trabalho entre vários agentes em paralelo.

Existe uma frase que resume essa mudança melhor do que qualquer previsão sobre IA: o trabalho deixa de ser escrever software e passa a ser organizar produção de software.

A tabela continua subindo e leva o gargalo junto.

No estágio Supervised Autonomy, Boris escreve que a pergunta muda de “você leu esse código?” para “qual contexto faltou para o modelo produzir isso corretamente?”. Parece uma diferença pequena, mas ela muda completamente a prioridade de uma organização.

Durante anos tratamos documentação como burocracia. ADRs esquecidos, wikis incompletas, decisões espalhadas pelo Slack e convenções conhecidas apenas pelos funcionários mais antigos raramente impediam uma empresa de continuar entregando software. Agora impedem.

Quando dezenas ou centenas de agentes dependem desse conhecimento para trabalhar, documentação deixa de ser registro histórico e passa a funcionar como infraestrutura operacional. Um contexto ruim não atrasa apenas um desenvolvedor, ele atrasa centenas de agentes ao mesmo tempo.

Foi aqui que mudei minha leitura da tabela, achei que ela explicaria como a IA evolui dentro das empresas. Na verdade, ela explica como as empresas precisam evoluir para acompanhar a IA.

O último estágio, chamado AI-native, leva essa lógica ao limite. Os agentes deixam de esperar comandos humanos para iniciar tarefas, passam a abrir novos fluxos automaticamente, monitoram canais, executam rotinas recorrentes e só escalam uma decisão quando encontram uma exceção relevante. Nesse cenário, o trabalho da liderança deixa de ser distribuir atividades e passa a definir intenção, estabelecer limites e decidir quais partes do negócio merecem automação contínua.

Se você observar apenas a coluna dos gargalos, aparece uma história diferente daquela que normalmente contamos sobre inteligência artificial.

No começo, o problema é infraestrutura.
Depois, atenção humana.
Em seguida, revisão.
Mais adiante, contexto.

No fim, o desafio passa a ser escolher o que realmente vale automatizar.

O modelo continua melhorando durante toda essa trajetória, mas deixa de ser o principal fator limitante muito antes do último estágio.

Essa talvez seja a melhor frase que consegui tirar da leitura da tabela:

Toda revolução tecnológica começa acelerando máquinas. As que realmente mudam empresas acabam acelerando decisões.

Talvez seja por isso que tantas organizações anunciem grandes investimentos em IA e, alguns meses depois, continuem entregando praticamente na mesma velocidade. Elas compraram modelos melhores, mas continuam operando com processos, documentação, governança e formas de decisão que pertencem ao estágio anterior.

A IA avança em ritmo exponencial. O gargalo sobe junto. A pergunta que fica é quanto tempo as empresas vão continuar investindo na tecnologia enquanto ignoram justamente aquilo que passou a determinar a velocidade dela.

A capacidade de gerar código cresceu sem que revisão, contexto e responsabilidade ganhassem a mesma escala. Um agente pode trabalhar durante uma reunião, outro pode abrir um pull request em paralelo e um terceiro pode revisar o resultado, mas a empresa continua dependendo de uma pessoa capaz de perceber que a solução duplicou uma regra de negócio, abriu uma falha de autenticação ou alterou um serviço que ninguém lembrava estar conectado àquela tela.

Minha primeira leitura desses números foi produtividade. Hoje, acho que eles descrevem melhor uma transferência de gargalo: escrever deixou de consumir a maior parte do tempo e verificar passou a concentrar o risco.

O gargalo saiu da escrita

Durante anos, empresas de software organizaram roadmaps, contratações e prioridades em torno de uma restrição conhecida. Havia mais coisas para construir do que engenheiros disponíveis para construí-las. Cursor, Claude Code e Codex reduziram essa escassez, especialmente para tarefas que podem ser descritas, divididas e verificadas com alguma objetividade.

A revisão não recebeu a mesma compressão. Quando o tamanho médio de um pull request triplica, o revisor precisa entender mais arquivos, reconstruir mais decisões e imaginar mais formas de o sistema quebrar. A revisão feita por outro agente ajuda a localizar problemas conhecidos, mas também pode repetir a mesma leitura errada que produziu o código.

Código pode ser produzido em paralelo; confiança continua sendo construída em série.

Kent Beck resumiu essa mudança numa conversa com Orosz: “estamos acumulando código mais rápido do que acumulamos confiança”. Software exige mais do que passar nos testes disponíveis. Alguém precisa entender por que aquela mudança existe, qual parte do produto depende dela e o que acontecerá quando o próximo engenheiro pedir ao agente para modificá-la novamente.

Essa diferença aparece com mais força nos sistemas antigos, onde o conhecimento está espalhado entre código, documentação incompleta e pessoas que participaram de decisões tomadas cinco anos atrás. O agente encontra os arquivos em segundos, mas não encontra com a mesma facilidade o motivo pelo qual uma exceção foi criada para um cliente específico ou por que um fluxo aparentemente redundante continua existindo.

Quanto mais código entra, mais conhecimento implícito passa a ser tratado como detalhe técnico. É justamente esse tipo de detalhe que costuma aparecer no post-mortem.

A Uber construiu uma fila para a atenção humana

A Uber tem cerca de 3 mil engenheiros e, segundo Orosz, transformou parte da equipe de developer experience numa estrutura dedicada à experiência com IA. A empresa criou um gateway interno de MCP, o Uber Minion para rodar agentes em background e uma série de ferramentas para controlar o volume produzido.

O Code Inbox ajuda a separar mudanças que exigem atenção. Os Risk Profiles estimam quais alterações merecem uma revisão mais cuidadosa. O uReview automatiza parte da análise. Há até regras para encaminhar um pull request a outra pessoa quando o primeiro revisor não responde dentro do prazo. A Uber percebeu que colocar mais agentes para trabalhar também exige uma forma explícita de decidir onde os humanos devem parar.

A parte mais cara da adoção aparece depois da licença. Cursor, Claude Code ou Codex colocam o agente na mão do engenheiro; a empresa ainda precisa conectá-lo ao monorepo, ao sistema de experimentação, às regras de segurança e ao histórico de decisões que define o que pode chegar à produção.

Spotify tomou uma decisão diferente. O CTO da empresa contou a Orosz que a qualidade deveria permanecer no mesmo nível durante a adoção, mesmo que isso reduzisse o ganho imediato de produção. A companhia construiu controles internos e avançou mais devagar, sem registrar o mesmo salto de output exibido por empresas que priorizaram volume.

Uber e Spotify escolheram ritmos diferentes, mas partiram de uma pergunta parecida: qual resultado a empresa quer obter sem deteriorar o sistema que já opera? Essa pergunta parece óbvia, porém desaparece quando a meta interna vira quantidade de pessoas usando IA.

Distribuir uma ferramenta mede distribuição. Uma mudança operacional aparece no tempo de revisão, nos incidentes, nos rollbacks e na capacidade de alterar novamente o código seis meses depois.

Quando consumo vira desempenho

Orosz descreve uma prática que chamou de token maxing. Em empresas como Meta, Amazon e Microsoft, engenheiros teriam passado a acompanhar rankings de consumo ou percebido que uma utilização baixa poderia ser interpretada como resistência à IA. A resposta foi previsível: mais tarefas foram enviadas aos agentes, inclusive atividades que poderiam ser concluídas mais rápido sem eles.

Na Meta, segundo os relatos internos apresentados na palestra, havia classificações ligadas ao consumo de tokens e uma pressão informal para que a utilização aparecesse nas avaliações de desempenho. A empresa encerrou parte dessas iniciativas, mas o comportamento já havia ensinado uma regra aos funcionários: usar IA precisava ser visível.

Eu trataria essa parte com cautela numa publicação. Orosz atribui as informações a funcionários das empresas, e vários detalhes ainda não têm confirmação pública independente. A lógica do incentivo, porém, independe de aceitar cada relato como fato: quando a liderança mede consumo, o funcionário aprende a produzir consumo.

O mesmo problema existia quando empresas contavam linhas de código, tickets fechados ou quantidade de features lançadas. A métrica captura uma atividade fácil de registrar e deixa de fora o trabalho menos visível, como remover complexidade, impedir uma mudança perigosa ou concluir que uma feature não deveria ser construída.

Com agentes, essa distorção ganha velocidade. Um engenheiro consegue abrir vários pull requests durante o dia e acumular sinais claros de produção. O colega que passa horas revisando uma dessas mudanças, encontra um risco e pede que ela seja refeita termina o mesmo dia com menos entregas registradas.

Quem revisa perde a corrida

Orosz relata que engenheiros responsáveis por revisões cuidadosas estão ficando sobrecarregados. Eles recebem mais mudanças, encontram código duplicado, contestam decisões e devolvem pull requests que já passaram por revisores automáticos. Ao fim do ciclo, aparecem como as pessoas que dificultaram o fluxo, enquanto quem enviou mais alterações ocupa o lado positivo do dashboard.

A revisão sempre dependeu de um acordo social. O autor aceita que outra pessoa questione seu trabalho, o revisor dedica tempo a uma tarefa que não receberá seu nome e a liderança protege essa fricção porque sabe que velocidade sem contestação cobra a conta depois.

A geração automática altera esse acordo. É mais difícil pedir que alguém passe quarenta minutos entendendo uma mudança que levou quatro minutos para ser produzida, principalmente quando outras quinze já estão esperando. O custo psicológico também muda: o autor tem menos apego ao código, mas o revisor continua assumindo a responsabilidade de aprová-lo.

Empresas estão tentando resolver o volume com mais revisão automática. A decisão funciona para erros detectáveis por regras, padrões conhecidos e testes existentes. O agente encontra uma função sem cobertura ou uma biblioteca vulnerável; ele tem mais dificuldade para perceber que o comportamento tecnicamente correto contradiz uma decisão tomada pelo time de operações depois de um incidente que nunca virou documentação.

Essa é a parte em que experiência ganha valor. O engenheiro sênior reconhece o risco porque já viu uma solução parecida falhar, conhece a história do serviço ou sabe qual pergunta fazer antes de aprovar. O problema é que esse trabalho produz poucos artefatos visíveis. Ele aparece na mudança que não chegou à produção e no incidente que nunca aconteceu.

Os números de Cursor e Linear provavelmente continuarão subindo. Teremos mais código, pull requests maiores e agentes capazes de assumir partes cada vez mais longas do desenvolvimento. A atenção humana continuará limitada, embora os dashboards de adoção tenham pouca razão para registrar esse limite.

No próximo ciclo de performance, o engenheiro com vinte pull requests terá vinte entregas para apresentar. O colega que bloqueou duas delas antes que causassem um incidente terá uma semana com menos produção. O dashboard consegue contar o código que entrou; as falhas que alguém impediu continuam sem uma linha própria na planilha.

🎧Ouça o episódio no Spotify e YouTube.

Linkedin do Pablo Silva: https://www.linkedin.com/in/souopablosilva/

🔗 Patrocinadores:

🌍 A Deel criou os Global Badges para transformar essa experiência em um sinal claro no LinkedIn. A certificação é gratuita e ajuda o mercado a entender melhor sua trajetória global. Descubra qual badge combina com você em https://productgurus.short.gy/pPAeWy

📱 A ReveLumi faz pesquisa qualitativa pelo WhatsApp, organiza as respostas e ajuda seu time a chegar mais rápido no que realmente importa. Conheça em https://productgurus.short.gy/miSFA2

📘 Quer acelerar sua carreira em Produto com conteúdo aplicado ao mercado? Na PM3, você encontra cursos e formações para profissionais de diferentes níveis. Use o cupom PRODUCTGURUS e garanta 10% de desconto na sua inscrição. Escolha sua formação e comece agora: https://productgurus.short.gy/HBiSmt

🛠️ Quer melhorar o onboarding do seu produto sem depender de desenvolvimento? Com a UserGuiding, você cria tours, checklists e experiências dentro do produto de forma simples. Use o cupom PRODUCTGURUS e ganhe 20% de desconto. Acesse a UserGuiding e teste na prática: https://productgurus.short.gy/Au9oVX

Capítulos:

00:00 O papel do PM na era da IA
10:00 Por que Produto ficou tão operacional
16:00 Liderança, prioridades e trade-offs
24:50 Resultado, política e crescimento na carreira
34:50 Como lidar com frustração no trabalho
40:10 Onde a IA realmente gera valor
46:40 Por que empresas copiam frameworks
53:15 A IA pode recuperar a agilidade?
56:05 O que realmente mudou em Produto

Inscreva-se no canal e compartilhe o episódio com alguém que entrega muito, mas ainda não aprendeu a navegar a empresa onde trabalha.

Subscreva agora

A frase ganha outro peso quando vem de uma empresa com 135 milhões de clientes, mais de US$ 5 bilhões em receita trimestral, operação mexicana no breakeven e um private banker baseado em IA com 15 milhões de usuários ativos por mês. O Nubank já passou da fase em que IA cabe numa demonstração lateral ou num experimento de produtividade. Quando uma decisão chega ao aplicativo, ela pode mexer com crédito, limite, dívida, investimento ou com o dinheiro que alguém pretende usar no fim do mês.

Para o cliente, pouco importa se uma tela foi desenhada por uma pessoa, sugerida por um modelo ou implementada com ajuda de um agente de código. Ele percebe se o limite foi explicado direito, se a transferência chegou, se a cobrança faz sentido e se consegue voltar atrás quando algo deu errado. A autoria pode ser híbrida; a responsabilidade continua tendo endereço.

Essa talvez seja a parte mais útil da fala de Rivera para quem trabalha com produto. Boa parte da discussão sobre IA ainda está presa ao volume de tarefas que uma pessoa consegue produzir. Quantas especificações o PM escreve, quantos protótipos o designer monta, quantos trechos de código o engenheiro gera. O Nubank parece estar olhando para outra unidade: quanto da jornada uma pessoa consegue compreender, alterar e sustentar sem empurrar o problema para a função ao lado.

Rivera descreve uma organização mais plana e fluida, na qual líderes de produto fazem partes do trabalho de design e engenharia, enquanto designers e engenheiros atravessam áreas que antes pareciam pertencer a outras disciplinas. Segundo ele, uma pessoa ou um grupo menor passa a carregar uma jornada mais inteira, o que aumenta a chance de a experiência parecer coerente do começo ao fim.

A divisão entre PM, design e engenharia sempre serviu para organizar o trabalho, mas também para limitar a responsabilidade de cada área. O PM definia o problema, o designer cuidava da experiência e a engenharia respondia pela implementação. Na prática, essas fronteiras nunca foram tão limpas, mas ainda explicavam por que alguma coisa parava na metade. O protótipo não ficou pronto porque design estava ocupado. A hipótese não foi testada porque faltou capacidade de engenharia. O código chegou, mas o problema inicial tinha mudado durante o trimestre.

Claude, Cursor, Figma e ferramentas de prototipação com código reduzem parte desse atrito. Um PM pode sair de uma hipótese para uma interface navegável sem esperar a próxima janela do time de design. Um designer consegue testar regras e estados que antes só apareciam depois do refinamento técnico. Um engenheiro pode explorar a experiência antes que ela chegue embalada numa especificação fechada. Nenhuma dessas pessoas vira excelente nas outras disciplinas por instalar uma ferramenta, mas todas passam a ter menos razões para ignorar o que acontece fora do próprio pedaço.

A especialização permanece, mas os limites da função ficam menos rígidos.

Durante muito tempo, a carreira em produto recompensou profissionais capazes de coordenar a passagem do trabalho entre áreas. Isso fazia sentido quando cada etapa exigia tempo, ferramentas e conhecimentos pouco acessíveis às demais funções. Quando Rivera fala em líderes atravessando design, produto e engenharia, ele aponta para uma mudança no valor dessa coordenação. Se o custo de produzir um protótipo, consultar uma base, gerar uma análise ou testar uma implementação cai, transportar informação entre especialistas perde parte do valor. Responder pelo percurso completo ganha mais.

Um PM pode continuar tendo o mesmo cargo e descobrir que sua função mudou por baixo dele. Escrever uma PRD deixa de ser uma demonstração suficiente de clareza quando o próprio PM poderia ter montado uma primeira versão, observado onde o fluxo quebra e levado para a conversa algo mais concreto do que uma sequência de requisitos. O mesmo acontece com o designer cuja participação termina na entrega da tela e com o engenheiro que trata a consequência para o usuário como um assunto resolvido antes de o código começar.

A IA não transforma todos em generalistas. Ela torna caro demais continuar sabendo apenas onde o próprio trabalho termina.

Essa exigência fica ainda mais visível no Nubank porque Rivera também está pensando em uma plataforma global. Ele traz da Shopify a experiência de áreas como Shop, Shop Pay, Payments e serviços financeiros, produtos que escondem uma infraestrutura extensa atrás de poucos passos para o usuário. No Nubank, a ambição é criar fundações comuns e, sobre elas, produtos adaptados às necessidades de Brasil, México, Colômbia, Estados Unidos e futuros mercados.

Uma plataforma desse tipo depende de abstrações técnicas, mas quebra quando a abstração vira desculpa para ignorar o contexto local. Um fluxo de pagamento pode compartilhar infraestrutura entre países, enquanto a linguagem usada para explicar risco, a relação com crédito, os meios de transferência e a expectativa de suporte mudam bastante. Rivera cita voz como uma oportunidade específica para o Brasil, porque parte relevante dos usuários prefere interagir dessa forma. A camada global reduz o custo de construir; a camada local decide se alguém vai confiar no que foi construído.

Confiança, nesse caso, precisa aparecer em decisões pequenas. Rivera associa confiança ao controle do usuário, à clareza sobre o que acontece quando uma ação é tomada e ao feedback oferecido pela interface. Em um produto financeiro, isso aparece na confirmação antes de transferir, na explicação de uma alteração de limite, na possibilidade de contestar uma cobrança e na diferença visível entre uma sugestão da IA e uma decisão executada pelo banco.

Esse nível de cuidado entra em conflito com a promessa de velocidade que acompanha IA. Um time consegue gerar mais alternativas, colocar mais experimentos no ar e reduzir o tempo entre uma ideia e uma versão utilizável. Rivera insiste que a régua de qualidade permanece a mesma. Eu ainda não sei se as empresas vão conseguir manter essa combinação por muito tempo. A história recente de produto costuma mostrar que, quando a capacidade de produzir aumenta, o volume cresce antes que o julgamento acompanhe.

O risco mais provável está justamente aí. IA pode reduzir o tamanho do time necessário para levar uma jornada adiante, como Rivera sugere, mas também pode multiplicar entregas medianas com uma eficiência que antes seria impossível. Mais código não cria uma experiência coerente. Mais telas não resolvem uma decisão mal enquadrada. Mais testes só aceleram o aprendizado quando alguém sabe qual incerteza está tentando reduzir.

Por isso, a responsabilidade mencionada por Rivera não deveria ser tratada como uma nota ética no fim da conversa. Ela muda a forma de avaliar profissionais. Em vez de perguntar apenas o que cada pessoa produziu, líderes terão de observar se ela percebeu a consequência da própria decisão nas outras partes da jornada, se buscou contexto sem esperar uma cerimônia e se assumiu o problema depois que a ferramenta entregou uma resposta aparentemente pronta.

Essa mudança favorece quem já trabalhava além da descrição do cargo. O PM que prototipava para pensar, o designer que acompanhava métrica depois do lançamento e o engenheiro que discutia comportamento do usuário antes da arquitetura ganharam ferramentas para ampliar esse jeito de trabalhar. Quem construiu a própria relevância em cima da distância entre as funções terá uma adaptação mais difícil, porque parte dessa distância está ficando barata.

A IA reduz a proteção que muita gente encontrou no próprio escopo.

O Nubank ainda precisará provar que uma organização mais fluida produz experiências melhores em escala. A empresa quer combinar 135 milhões de clientes, expansão internacional, personalização individual e uma régua alta de confiança. Cada uma dessas coisas já seria difícil isoladamente. Juntas, criam um ambiente no qual a velocidade oferecida pela IA pode ajudar ou apenas permitir que erros atravessem a organização mais rápido.

Rivera chegou dizendo que a responsabilidade continua humana. O incômodo começa quando essa frase entra na avaliação de desempenho: se produto, design e engenharia conseguem atravessar mais fronteiras com IA, muita gente vai descobrir que o limite da própria função também era o ponto em que deixava de responder pelo resultado.

A história parece provar que duas pessoas conseguem construir um produto inteiro com IA. A própria fala de von Ahn coloca um limite mais interessante: a dupla criou o currículo e chegou longe no protótipo usando Cursor e outras ferramentas, mas engenheiros entraram depois para colocar a experiência dentro do aplicativo. O ganho real apareceu antes da produção, quando uma ideia recusada deixou de depender de espaço no roadmap para ser levada a sério.

Esse talvez seja o efeito mais imediato da IA sobre o trabalho de produto. Uma boa proposta escrita ainda pede que alguém imagine o produto. Um protótipo funcional permite que a discussão comece pelo que já pode ser usado, criticado e descartado.

Von Ahn contou que os product managers do Duolingo estão fazendo exatamente essa troca. Em vez de chegar com um documento explicando uma maneira melhor de ensinar espanhol, eles levam uma experiência que o CEO consegue testar. A qualidade da decisão melhora porque a conversa deixa de depender da capacidade do autor de descrever uma interface e da capacidade dos outros de reconstruí-la mentalmente.

Durante muito tempo, escrever bem uma especificação foi uma forma de compensar a distância entre quem pensava a solução e quem conseguia construí-la. O documento atravessava produto, design e engenharia, acumulando interpretação em cada passagem. O protótipo reduz essa distância, mas também expõe uma pergunta que ficava escondida pelo processo: a ideia era boa ou apenas estava bem apresentada?

O caso do xadrez começou com uma recusa. Von Ahn via o tema como um jogo, enquanto o Duolingo se definia como uma empresa de educação. A leitura mudou depois de uma conversa com a ministra da Educação da Guatemala, que considerava distribuir tabuleiros nas escolas públicas para que os alunos aprendessem raciocínio lógico. Quando os dois funcionários voltaram ao assunto, receberam autorização, mas não receberam engenheiros.

A dupla primeiro aprendeu xadrez, depois analisou as ferramentas existentes e concluiu que a experiência de aprendizado era ruim. Baixou o Cursor, começou com exercícios simples e descobriu rapidamente um limite: a IA gerava problemas de xadrez de baixa qualidade. A saída foi usar uma base online com exercícios existentes para melhorar os resultados. Depois vieram protótipos móveis sucessivos, testados por von Ahn, até que o projeto ficou bom o bastante para ganhar suporte de engenharia e entrar no aplicativo.

Essa sequência importa porque desmonta a versão preguiçosa do caso. A dupla não pediu a um modelo que “criasse um curso de xadrez” e voltou seis meses depois com 7 milhões de usuários. Houve pesquisa, aprendizado do domínio, comparação com concorrentes, descoberta de uma falha do modelo, uso de uma base externa, iteração e julgamento humano. A IA ampliou a autonomia do time, mas não tomou nenhuma das decisões que fizeram o produto avançar.

O próprio von Ahn descreve um comportamento parecido no restante da empresa. Pessoas de RH, finanças e produto participaram de um dia dedicado a construir pequenos aplicativos. Alguns PMs criaram dashboards próprios para acompanhar usuários por país. Há um canal no Slack para compartilhar boas práticas e outro chamado “AI fails”, onde os funcionários registram tentativas que deram errado.

O segundo canal talvez explique melhor a adoção do Duolingo do que o primeiro. Uma empresa aprende pouco quando só distribui exemplos bem-sucedidos. Os erros mostram em quais tarefas o modelo funciona, quando produz uma resposta convincente e errada, e onde o tempo economizado no caminho feliz reaparece multiplicado na depuração.

Von Ahn usa programação como exemplo. Há dois anos, ele lia que a IA já era melhor do que engenheiros, mas não via uma aceleração parecida dentro do Duolingo. O código podia sair rápido quando tudo funcionava. Quando falhava, ninguém entendia direito o que havia sido gerado, e o tempo gasto para encontrar o problema consumia o ganho anterior.

Ele observa a mesma distribuição na geração de conteúdo. Uma demonstração produz uma história impressionante. Quando a empresa pede cem, talvez trinta sejam boas e setenta precisem ser descartadas ou corrigidas. Por isso, todo conteúdo do Duolingo ainda passa por revisão, checagem completa ou amostragem.

A produtividade da IA aparece de forma desigual porque o trabalho também é desigual. Um engenheiro não passa oito horas escrevendo código; participa de reuniões, depende de decisões e trabalha em uma base existente que o modelo conhece mal. Uma pessoa começando um produto do zero consegue acelerar várias etapas porque não precisa negociar com uma arquitetura antiga nem atravessar tantas relações internas.

A IA comprime a construção mais rápido do que comprime a empresa.

Essa diferença ajuda a entender por que o Duolingo consegue produzir um caso extremo em uma pequena equipe e, ao mesmo tempo, não vê a companhia inteira lançando dez vezes mais funcionalidades. O protótipo de xadrez nasceu quase como uma startup interna. Já o produto principal carrega anos de código, processos, métricas, dependências e mais de 1 bilhão de exercícios respondidos por dia.

O caso também corrige uma leitura comum sobre especialização. As duas pessoas começaram sem conhecimento de xadrez e sem experiência formal em engenharia, mas uma delas tinha algum repertório técnico. Von Ahn faz questão de registrar isso. Ele ainda não viu alguém sem nenhuma compreensão de programação construir um bom aplicativo, embora já tenha visto pessoas com conhecimento básico chegarem muito longe.

Saber escrever cada linha de código pode perder valor. Entender o que é cliente, servidor, banco de dados, estado, erro e integração continua sendo necessário para perceber quando a ferramenta está produzindo uma solução frágil. A IA diminui o preço da execução, mas cobra repertório na hora de avaliar o que executou.

Eu costumava olhar para casos como esse principalmente como histórias sobre redução de time. A transcrição aponta para outra coisa: o Duolingo reduziu o custo de provar uma hipótese, não o custo total de operar um produto usado por milhões de pessoas. Essa distinção muda bastante o que gestores deveriam cobrar de seus times.

A empresa tentou medir essa mudança do jeito errado. Von Ahn chegou a anunciar que o uso de IA faria parte das avaliações de desempenho. Os funcionários começaram a perguntar se deveriam usar a tecnologia mesmo quando ela piorava o trabalho. A política foi retirada, e a empresa voltou a cobrar o resultado da função, admitindo que a ferramenta nem sempre ajudaria.

Obrigar o uso de IA produz evidência de uso. Cobrar que uma equipe chegue mais longe com menos dependências produz evidência de capacidade.

Essa diferença também aparece na política de contratação. Von Ahn afirma que o Duolingo nunca fez uma demissão em massa e continua contratando porque cada novo funcionário pode produzir mais do que antes. Na leitura dele, algumas empresas usam IA como justificativa pública para corrigir contratações excessivas feitas durante a pandemia. No Duolingo, a tecnologia aumenta o retorno esperado de cada pessoa em vez de tornar toda nova contratação desnecessária.

Ainda não dá para saber até onde essa lógica vai. O curso de xadrez nasceu dentro de uma empresa lucrativa, com mais de 100 milhões de usuários ativos, uma marca reconhecida, infraestrutura de distribuição e dados coletados em centenas de milhões de jornadas de aprendizado. Uma dupla em uma empresa desconhecida não recebe 7 milhões de usuários porque construiu um bom protótipo.

O que pode ser reproduzido é a mudança no ponto de partida. Um PM já consegue pesquisar o mercado com Gemini, desenhar telas, usar Cursor para montar uma experiência e chegar à discussão com algo executável. A engenharia continua necessária para produção, escala, segurança e manutenção, mas já não precisa ser convocada para transformar toda hipótese em uma primeira versão.

Isso desloca o gargalo. Quando construir um protótipo deixa de consumir semanas de coordenação, a demora passa a revelar onde a empresa realmente é lenta: na escolha dos problemas, na autorização para experimentar, na avaliação do que foi construído e na decisão de abandonar uma ideia ruim.

O Duolingo deu seis meses para duas pessoas e não ofereceu engenheiros. Elas voltaram com algo que convenceu o CEO a mudar de ideia e depois atraiu 7 milhões de usuários por dia. Empresas que continuam exigindo um documento, três aprovações e uma vaga no trimestre seguinte para testar uma hipótese terão dificuldade para culpar a tecnologia pela própria lentidão.

🎧 Conteúdo extra para você:

🔗 Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse: https://go.pm3.com.br/ProductGurus-AI-Specialist
Cupom de 10%: PRODUCTGURUS

🎧 Ouça o episódio no Spotify e YouTube.

A IA tornou a produção mais rápida. A pergunta agora é se as empresas estão melhorando a qualidade das decisões ou apenas aumentando o volume de trabalho.

LinkedIn Rapha: https://www.linkedin.com/in/rapha-albino/

Capítulo:
00:48 Introdução ao Gargalo do Desenvolvimento
03:05 A Visibilidade e a Escrita de Código
04:53 Validação de Hipóteses e Aprendizado
07:39 A Ilusão da Produtividade com IA
09:54 Métricas de Sucesso em Desenvolvimento
12:40 Estruturação do Problema e Pensamento Crítico
15:50 A Importância da Leitura e Aprendizado Contínuo
22:18 A Nova Mentalidade nas Equipes de Produto
27:45 Habilidades Essenciais para o Futuro do Trabalho

Parceiros do episódio:

“você está passando de fazer para dirigir, e isso significa que todo mundo vira gerente.”

A entrevista era sobre o lançamento do Gemini Spark, mas essa frase estava no meio de uma conversa sobre outra coisa e por isso ficou mais honesta do que as partes escritas por time de comunicação.

Subscreva agora

O contexto era o seguinte: no Google Labs, onde nasceram o NotebookLM, o Google Flow e o AI Studio, as equipes têm cinco ou seis pessoas, quase nenhuma reunião de aprovação, e o critério para continuar ou parar um projeto é observar se as pessoas que testam o produto têm os olhos iluminados ou recuam na cadeira. Woodward mencionou isso depois de alguém perguntar como o Google conseguia lançar uma funcionalidade de voz que foi codificada dois fins de semana antes de aparecer no palco do Google IO. A resposta não foi um processo ágil descrito em slide, foi essa coisa menos glamurosa: equipe pequena, autonomia real, vai lá mostrar pra pessoa e vê a reação dela.

Isso já seria interessante em contexto normal, mas tem uma camada específica que importa para quem está construindo produto com IA agora. Quando as ferramentas fazem a parte de execução, o que sobra para os humanos é tomar as decisões que as ferramentas não conseguem tomar sem input: o que construir, em qual ordem, para quem, com qual grau de acabamento mínimo para valer a pena mostrar. Essas decisões sempre existiram, mas eram diluídas no volume de trabalho operacional. Quando o operacional vai para o agente, as decisões ficam mais visíveis e mais frequentes.

Woodward deu um exemplo de como isso aparece na prática: o Google começou a discutir se vai precisar estender treinamento de liderança para toda a empresa, não só para quem tem subordinados diretos. Hoje, manager training é feito com uma fração do time. Se cada pessoa vai gerenciar agentes em paralelo, coordenando dezenas de tarefas rodando em máquinas virtuais no Google Cloud, a habilidade de definir o que você quer como resultado antes de saber como chegar lá vira pré-requisito para qualquer função, não diferencial de carreira.

A pergunta que isso deixa aberta para qualquer empresa é mais difícil do que parece. Porque ter uma pessoa boa em tomar decisões é diferente de ter uma pessoa boa em executar, e a maioria das estruturas de carreira e contratação ainda mede a segunda coisa. Um engenheiro sênior é sênior porque entrega código, um analista é promovido porque entrega análise, e o que acontece com esses critérios quando o código e a análise passam a ser produzidos em volume pelo agente e o humano fica responsável por dizer se aquilo era o que devia ser construído?

Esse julgamento, o de reconhecer quando a saída do agente está errada mesmo que tecnicamente correta, exige um tipo de experiência que leva tempo para formar e que não aparece no output de ninguém enquanto a maior parte do trabalho ainda é operacional.

O outro lado da entrevista, sobre como o Google decide continuar ou matar um produto em estágio inicial, conecta com isso de uma forma que Woodward não tornou explícita mas está lá. Ele disse que métricas de retenção e dashboards chegam depois, que num primeiro momento o que vale é observar se o produto faz sentido para quem está usando, e que as equipes do Labs costumam perceber antes dele se algo tem futuro ou não.

Esse tipo de avaliação qualitativa, olhar para alguém usando um produto e reconhecer se a interação está resolvendo o problema real ou apenas parecendo resolver, é o mesmo músculo que vai fazer diferença quando agentes estiverem gerando protótipos, análises e apresentações em série e alguém precisar dizer qual deles vale continuar.

O problema é que esse músculo é ruim de treinar em escala e difícil de medir. Você consegue medir quantas tarefas um agente completou. Não consegue medir facilmente o quanto a pessoa que configurou aquelas tarefas estava certa sobre o que precisava ser feito. E se a maior parte do trabalho operacional sumiu, o que vai aparecer nos registros de desempenho das pessoas é cada vez mais essa camada de julgamento, que tem menos evidência visível e mais risco de ser confundida com intuição ou, pior, com opinião.

A conversa parte de uma experiência concreta: Taynara precisou estruturar o desenvolvimento de um estagiário de Produto em um contexto real, com múltiplas tecnologias, stakeholders, prioridades concorrentes e decisões acontecendo fora da ordem bonita dos livros.

O episódio mostra por que aprender Produto não começa decorando frameworks, discovery, priorização ou Marty Cagan. Começa entendendo contexto, problema, relacionamento, métrica e decisão.

Ao longo da conversa, Taynara explica como ensinou um estagiário a sair da linguagem de curso e começar a raciocinar como alguém de Produto: olhar menos para interface, mais para dor; menos para feature, mais para problema; menos para certeza, mais para decisão responsável.

Também falamos sobre cultura de produto, fábrica de demanda, problemas analíticos versus problemas conceituais, métricas de vaidade, relacionamento com stakeholders e o papel real da liderança no desenvolvimento de pessoas iniciantes.

Se você é Product Manager, Head de Produto, GPM, liderança de tecnologia, pessoa júnior ou alguém tentando entrar em Produto, este episódio ajuda a entender uma coisa desconfortável: muitas vezes o júnior não está perdido por falta de esforço. Está perdido porque ninguém ensinou a ordem certa das coisas.

Assista até o final para entender:

• O que ensinar primeiro para um estagiário de Produto

• Por que Produto “by the book” quebra na vida real

• Como separar problema analítico de problema conceitual

• Quando parar de pesquisar e começar a decidir

• Como dizer “isso não faz sentido” para stakeholders sem virar a pessoa do não

• Qual é o papel da liderança na formação de pessoas juniores

🎧 Assista também pelo Spotify ou YouTube.

Linkedin: https://www.linkedin.com/in/taynarafranck/

Capítulo:

01:25 Quem é Taynara Franck
02:55 Como nasceu a série sobre estagiário de Produto
07:11 O que um júnior acha que Produto é
13:01 Quando o júnior começa a pensar como PM
16:20 O que não ensinar cedo demais
21:02 Cultura de Produto ou fábrica de demanda?
23:50 Problemas analíticos vs. problemas conceituais
30:52 Quando parar de pesquisar e começar a decidir
35:00 Métricas de vaidade vs. métricas de decisão
39:40 Como dizer “não” para stakeholders
44:02 PM3, UserGuiding e IA aplicada
45:35 O papel da liderança no desenvolvimento júnior
48:46 Encerramento

Parceiros do episódio:

Para um banco global, essa escolha diz mais sobre a próxima fase da IA corporativa do que qualquer anúncio de assistente interno.

O SantanderAI não tenta parecer uma vitrine para cliente final. gen-fraud-graph, ralph, mech-gov-framework e autoguardrails são nomes de infraestrutura, e a aposta mais interessante do banco está justamente nesse ponto: abrir parte do “encanamento” técnico pode influenciar como IA será testada, auditada e aceita em ambientes financeiros.

Subscreva agora

A conversa corporativa sobre IA ainda está presa a uma métrica confortável: acesso. Quantas licenças de Copilot foram distribuídas. Quantos funcionários usam ChatGPT Enterprise. Quantos times criaram assistentes internos. Quantos pilotos chegaram ao comitê executivo.

O Santander também joga esse jogo, com IA disponível para 185 mil funcionários, mas o GitHub público do banco empurra a pergunta para um lugar mais difícil: quando um agente participa de fraude, crédito, AML ou atendimento, qual mecanismo prova que aquela decisão podia ter sido tomada?

Uma demo de chatbot em reunião de diretoria mostra fluidez, velocidade e repertório. O problema começa quando o mesmo tipo de tecnologia entra em contestação de cartão, alerta de lavagem de dinheiro ou decisão que pode bloquear um cliente real. Em banco, uma falha de IA atravessa produto, jurídico, risco, auditoria e atendimento, porque o cliente não reclama de um “modelo probabilístico”; ele reclama de dinheiro retido, crédito negado ou acusação errada.

O gen-fraud-graph entra no ponto em que a ambição técnica bate no limite regulatório. Para treinar modelos melhores contra fraude e lavagem de dinheiro, um banco precisa de dados transacionais ricos, com contas, transferências, padrões suspeitos e relações que só aparecem em escala. A base real, porém, é o ativo que ninguém pode colocar em um repositório público, mesmo quando fornecedores, pesquisadores e startups teriam muito a ganhar estudando esse material.

Ao publicar um gerador de grafos sintéticos, o Santander cria uma bancada de teste para um dado que o mercado precisa estudar e não pode ver.

A ferramenta simula contas, transações e anéis de lavagem de dinheiro com ciclos de 4 a 7 saltos, podendo escalar de 1 mil a mais de 100 milhões de nós. Em vez de pedir confiança no discurso de “IA responsável”, o banco oferece um ambiente onde outras pessoas podem testar modelos sem tocar em dado de cliente.

O ralph mostra o lado menos glamouroso da autonomia. A ferramenta roda Codex, Claude, Gemini e Devin em loops sucessivos, reinicia sessões e troca fornecedor quando detecta exaustão de tokens ou falha operacional.

A premissa é quase desconfortável para quem vende agente como trabalhador digital incansável: sessões degradam, contexto se perde, API falha, quota acaba, e tarefas longas exigem memória fora do modelo.

O ralph preserva estado em registros estruturados e força a próxima iteração a retomar o trabalho a partir dali, em vez de fingir que uma janela de contexto maior resolve todo problema de continuidade.

Para uma empresa que precisa de automação em produção, essa arquitetura humilde vale mais do que uma demo impecável de cinco minutos.

O mech-gov-framework muda a conversa sobre explicabilidade porque tira a decisão de dentro da narrativa do próprio modelo.

• No R1, o modelo interpreta políticas em texto.

• No R2, a decisão passa por barreiras mecânicas, congelamento de variáveis, validações de argumento, portas de ambiguidade e etapas de auditoria.

• No R3, a validação muda conforme o risco detectado na transação.

A diferença prática aparece quando alguém precisa revisar a decisão depois: uma justificativa escrita pelo modelo pode soar convincente; um mecanismo com travas e registros precisa aguentar jurídico, risco e regulador.

Tenho menos certeza do que tinha há alguns meses sobre tratar “governança de IA” como teatro corporativo. Ainda existe muito documento bonito que não sobrevive ao primeiro fluxo real de produção, principalmente quando a aprovação acontece no fim do projeto e ninguém volta ao tema. Mas o mech-gov-framework e o autoguardrails apontam para outro tipo de governança: aquela que roda junto com a decisão, mede falha, cria registro e reduz espaço para explicação improvisada depois do dano.

O autoguardrails completa essa leitura porque parte de um arquivo declarativo de política, o policy.md, e usa testes adversariais para reduzir a taxa de sucesso de ataques sem destruir respostas benignas.

Escrever regra é barato. Descobrir onde ela quebra custa ataque, medição e ajuste. Para um banco, a pergunta incômoda não é se existe uma política de uso seguro, mas quantas vezes essa política falha antes de chegar em um cliente, em um analista de fraude ou em uma esteira de decisão automatizada.

O SantanderAI fica mais sério quando aparece a OSPO, o Open Source Programme Office do banco, porque abrir código em instituição financeira exige uma máquina de decisão por trás do GitHub. Na Fast Track, entram forks de terceiros, ferramentas genéricas, tutoriais, SDKs sem regra de negócio interna e conjuntos de dados não proprietários, com SLA inferior a 4 horas.

Na Full Track, entram modelos originais, frameworks com propriedade intelectual relevante ou código que tocou dado interno, passando por FOSS Review Board, jurídico, CISO e arquitetos corporativos, com prazo de 2 a 4 semanas.

Fast Track e Full Track mostram que código aberto, nesse caso, exige arquitetura organizacional. O Santander não está apenas publicando repositórios; ele está criando um processo para separar o que pode virar infraestrutura pública do que precisa continuar fechado.

Uma startup de devtools pode abrir um repositório em uma sexta-feira e ajustar o processo na semana seguinte.

Um banco precisa decidir se há dado sensível, segredo comercial, propriedade intelectual, risco regulatório e dependência com fluxo core. O SantanderAI parece menos um GitHub institucional quando visto por esse caminho, e mais uma esteira interna para transformar parte dos seus problemas em infraestrutura compartilhável.

A vantagem possível aparece quando uma ferramenta pública deixa de ser apenas código disponível e começa a ensinar fornecedores, pesquisadores, fintechs e reguladores a pensar com as categorias de quem publicou. Se grafos sintéticos parecidos, testes adversariais parecidos e regimes de governança parecidos virarem referência, o Santander ganha algo que uma licença de modelo não compra: familiaridade externa com a sua forma de medir risco.

Google, TensorFlow, Meta, PyTorch e Llama ajudam a entender como open source distribui influência técnica, mas a comparação fica curta quando entra regulação financeira.

Em empresa de tecnologia, um framework aberto costuma atrair desenvolvedor, talento e ecossistema. Em banco, uma ferramenta usada para testar decisão automatizada pode entrar na conversa sobre crédito, fraude, AML, auditoria e responsabilidade jurídica. A régua técnica começa a tocar a régua institucional.

O Santander parece estar chegando cedo nessa disputa por critérios. Enquanto muita empresa ainda apresenta assistente interno como prova de maturidade, o banco publica mecanismos para simular dado sensível, preservar estado de agente, testar ataque a guardrail e estruturar decisão automatizada. A força do movimento está menos na demo e mais no que passa a ser testável.

Ainda existe uma chance razoável de o SantanderAI virar apenas um conjunto de repositórios corporativos bem documentados. GitHub de empresa grande tem muito README correto, boa intenção e pouca vida real. Abrir código não garante comunidade, adoção nem padrão.

Esses projetos só viram movimento de mercado se gente de fora usar, criticar, melhorar e aplicar as ferramentas em problemas que o Santander não controla.

Mesmo com essa ressalva, o caso pressiona a pergunta que toda empresa grande usando IA vai enfrentar depois da fase das licenças. Copilot, ChatGPT Enterprise, Claude, Gemini e Devin ajudam a produzir mais coisas, mas nenhum deles responde sozinho ao jurídico depois do primeiro erro em escala: por qual mecanismo a empresa decidiu que esse agente podia decidir?

O Santander começou publicando ferramentas com nomes pouco comerciais: gen-fraud-graph, ralph, mech-gov-framework e autoguardrails. Talvez algumas fiquem no laboratório, com boa documentação e pouca adoção. Talvez outras virem referência para quem precisa operar IA em setor regulado. A pergunta incômoda para os outros bancos é que, enquanto eles ainda discutem o que é seguro abrir, alguém pode estar ensinando o mercado como segurança deve ser medida.

A frase é boa para palestra, post e thumbnail. Mas ela esconde um problema mais sério: talvez uma parte da indústria tenha reduzido design a Figma, tela bonita e gosto pessoal. Quando isso acontece, qualquer ferramenta que gera interface em segundos parece uma ameaça existencial.

Subscreva agora

Só que design nunca foi isso.

Neste episódio do Product Gurus, conversei com Natália Arsand, ex-Booking.com e founder da Eixo Design Studio, sobre o que realmente está em jogo quando falamos de design na era da IA.

A Natália tem uma trajetória rara. Começou cedo em tecnologia, passou pela Dell, ajudou a construir a disciplina de design na ThoughtWorks Brasil, trabalhou em projetos no Haiti e em sala de aula nos Estados Unidos, e depois viveu por dentro uma das culturas de experimentação mais conhecidas do mundo: a Booking.com.

A conversa começou na provocação mais óbvia: os processos de design morreram?A resposta dela foi mais interessante do que um sim ou não.

Para Natália, quando alguém experiente diz que não precisa mais de processo, muitas vezes o processo não desapareceu. Ele só ficou tão internalizado que a pessoa parou de enxergar. O problema começa quando quem ainda não domina o método tenta pular direto para a quebra da regra.

Com IA, esse risco ficou maior.

Hoje qualquer pessoa consegue pedir uma tela, um fluxo, uma copy, uma pesquisa sintética, uma persona artificial, um feedback simulado. A produção acelera. A sensação de avanço aumenta. O problema é que usuário real continua fora do prompt.

E produto sem usuário real vira uma máquina elegante de confirmar achismo.

Um dos melhores momentos do episódio veio quando Natália disse que A/B test ensina humildade. Não porque teste seja uma ferramenta mágica, mas porque ele coloca a opinião do time contra a evidência do comportamento. E, quase sempre, isso dói.

A Booking.com aparece na conversa justamente por isso. A empresa ficou famosa por experimentação, mas Natália também mostra o outro lado: quando você otimiza pequenos pedaços demais, pode perder a experiência inteira. O time mede o clique no banner, mas esquece o que acontece depois do clique.

Esse é o ponto central do episódio.

Design não morreu.

O que está morrendo é a paciência para entender problema antes de produzir solução.

Também falamos sobre a diferença entre experiência do usuário e experiência para o usuário, por que taste não pode virar desculpa para gosto pessoal, como IA pode terceirizar julgamento, o papel da autonomia em times de produto e por que método ficou mais importante quando ficou mais fácil gerar qualquer coisa.

A frase que ficou comigo foi simples:

Talvez seja isso que a IA ainda não resolveu para produto e design.

Ela aumenta a quantidade de respostas disponíveis. Mas alguém ainda precisa decidir qual pergunta merecia ser feita.

O episódio já está no ar.
Ouça no Spotify ou assista no YouTube.

A conta dos 60x chama atenção, mas ela sozinha não explica o caso. O ponto mais interessante é que o iFood encontrou um lugar onde IA genérica começa a ficar cara demais para o tipo de problema que precisa resolver: entender intenção de compra dentro de um fluxo com milhões de usuários, cardápios, histórico, horário, localização, desconto, tempo de entrega e chance real de conversão.

Subscreva agora

Quando a tarefa é essa, a melhor IA talvez seja a que sabe menos sobre o mundo e mais sobre o seu negócio.

O Large Commerce Model, ou LCM, foi apresentado pela Prosus como um modelo treinado com dados de mais de 500 milhões de usuários e mais de 10 trilhões de tokens.

No iFood, ele aparece de forma mais visível no Ailo, assistente de IA que permite pedir comida pelo WhatsApp ou pelo app a partir de frases comuns, como “quero uma comida leve que chegue em até 30 minutos” ou “quero restaurantes em promoção”. A interface parece simples, quase óbvia em 2026, mas o que está por trás dela não é um chatbot tentando soar educado. É uma tentativa de transformar linguagem natural em pedido, e pedido é uma métrica muito menos tolerante a teatro do que engajamento em conversa.

Durante os testes, segundo o iFood, mais de 70 mil pessoas usaram o Ailo, somando mais de 100 mil interações desde junho de 2025. A empresa reportou 48% mais chance de uma busca virar pedido em comparação com o fluxo tradicional do app e 33% menos tempo para finalizar um pedido no WhatsApp. A Prosus também divulgou outros resultados do LCM em produção: push notifications com 4x mais pedidos, aumento de 66% na conversão das recomendações “you may also like this” e busca em farmácia gerando 4,6% mais pedidos.

Esses números explicam por que o caso é diferente da maioria das iniciativas de IA que aparecem em produto. Um assistente genérico pode responder bem. Um assistente vertical precisa vender melhor, reduzir atrito ou aumentar frequência. Se ele conversa bonito e não muda comportamento, é decoração cara e muito cara por sinal.

A parte contraintuitiva é que o iFood não parece ter escolhido entre “usar API” e “construir tudo dentro de casa”. O próprio material da empresa diz que o Ailo usa uma arquitetura híbrida com Anthropic, OpenAI e AWS para combinar precisão, velocidade e segurança. Essa nuance importa porque a ideia não é abandonar modelos genéricos, mas parar de tratá-los como resposta universal.

Em algumas partes do fluxo, faz sentido alugar inteligência de fronteira. Em outras, especialmente quando existe volume, repetição e dados proprietários, pagar a mesma tarifa cognitiva para cada microdecisão começa a parecer desperdício operacional.

Durante um bom tempo, parecia mais sensato dizer que quase nenhuma empresa deveria treinar modelo próprio, porque OpenAI, Anthropic, Google e Meta têm mais capital, mais gente técnica e mais escala de infraestrutura. Essa leitura ainda vale para muitas empresas.

O erro seria aplicar a mesma regra para uma plataforma com mais de 60 milhões de usuários, milhões de pedidos e uma base histórica que sabe, com muito mais precisão do que qualquer modelo genérico, como um brasileiro escolhe comida numa segunda-feira à noite depois de cancelar duas entregas no último mês.

O LCM não precisa ser melhor que o Claude em escrita, melhor que o GPT-5 em raciocínio geral ou melhor que o Gemini em busca aberta. Ele precisa saber se uma pessoa com fome agora, em um bairro específico, usando WhatsApp, com determinado histórico de pedidos e certa sensibilidade a promoção, tem mais chance de comprar sushi, pizza, mercado ou farmácia. Isso é contexto e também é onde mora o dinheiro.

Essa diferença muda a conversa de produto. Quando um time adiciona um chat ao app, ele normalmente está mexendo na superfície da experiência. Quando o iFood conecta linguagem natural a busca, recomendação, push, canal e pedido, a IA começa a mexer no sistema de decisão do produto. A fronteira deixa de ser “o usuário consegue conversar?” e passa a ser “o produto consegue decidir melhor com base no que só ele sabe?”.

A Databricks chegou a uma conclusão parecida em outro domínio, com menos barulho e menos apelo para consumidor final. Para gerar documentação de tabelas e colunas no Unity Catalog, a empresa treinou um modelo sob medida gastando menos de US$ 1.000 em treinamento e experimentação, com dois engenheiros trabalhando por cerca de um mês, e reportou queda de 10x no custo de inferência.

A tarefa era pequena perto do que o iFood faz, mas o raciocínio era parecido: quando uma tarefa tem fronteira clara, volume alto e feedback rápido, chamar sempre o maior modelo disponível vira desperdício. Um modelo menor, adaptado ao contexto do produto, pode resolver melhor e custar menos.

A própria OpenAI aponta esse caminho nas docs de otimização de modelo quando trata fine-tuning e distillation como formas de criar modelos menores, mais rápidos e mais baratos para tarefas específicas. Isso torna a discussão menos ideológica, digamos assim. O fornecedor da API sabe que nem toda tarefa deveria terminar no modelo mais caro. A diferença é que, para muitas empresas, esse raciocínio ainda não chegou em quem toma decisões e alinha com os times.

O cuidado necessário no caso do iFood é a conta dos 60x. A Prosus divulgou o número, mas não abriu todos os detalhes da comparação: quais modelos entraram no benchmark, qual foi o mix de entrada e saída, como cache e batching foram tratados, quanto de engenharia entrou na conta e quais tarefas específicas definiram “melhor desempenho”. Para confiar totalmente no número, seria preciso ver a metodologia inteira. Ainda assim, mesmo que a vantagem real fosse menor, a direção do caso continuaria relevante, porque a economia aparece exatamente onde a escala torna cada centavo por requisição um problema acumulado.

Uma empresa pequena pode se iludir com a ideia de IA proprietária e gastar energia onde deveria usar API pronta. Uma plataforma grande pode se iludir no sentido oposto e pagar API genérica para tarefas que já viraram repetição estatística dentro do próprio produto. O iFood está no segundo grupo. A cada busca, push, pedido, avaliação, cancelamento e recompra, a empresa acumula sinais que não existem no dataset público de nenhum modelo generalista.

A maioria das discussões internas sobre IA ainda começa com a pergunta errada: “qual modelo vamos usar?”. Antes disso vem uma pergunta mais chata e mais útil: quais decisões do produto acontecem tantas vezes, com tanto dado próprio e tanta consequência econômica, que continuar usando modelo genérico virou uma forma elegante de desperdiçar margem?

No iFood, essa decisão aparece na busca que vira pedido, no WhatsApp que encurta o fluxo, na recomendação que aumenta conversão, no push que volta a ser relevante e no modelo que aprende com cliques, compras, cancelamentos e avaliações. A IA deixa de ser uma camada conversacional e vira memória operacional. Essa mudança é pequena na interface e enorme na conta.

Para PMs, founders e executivos, a consequência é desconfortável porque quebra duas crenças convenientes ao mesmo tempo.

1. A primeira é que basta plugar uma API boa e esperar a vantagem aparecer.

2. A segunda é que modelo próprio é sempre vaidade técnica.

O caso do iFood mostra uma região intermediária, mais difícil de explicar em reunião e mais importante para a estratégia: usar modelos genéricos onde eles são melhores, construir inteligência vertical onde o contexto proprietário muda custo, qualidade e conversão.

O próximo ciclo de IA em produto provavelmente será menos sobre quem tem o chat mais impressionante e mais sobre quem sabe onde a inteligência precisa estar. Em alguns produtos, ela vai continuar fora, alugada por chamada. Em outros, vai precisar entrar no fluxo, aprender com o comportamento real e carregar a memória que nenhum fornecedor externo tem.

A parte incômoda é que muita empresa só vai descobrir a diferença depois de transformar a própria margem em experimento, e isso já está acontecendo.

🔗 Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse: https://go.pm3.com.br/ProductGurus-AI-Specialist
Cupom de 10%: PRODUCTGURUS

Ouça o episódio sobre iFood e Inteligência Artificial aqui:

Nesse episódio a gente fala sobre o que realmente acontece quando uma empresa resolve implementar IA, por que o ganho de produtividade em código não aparece no resultado final, como a Distrito estrutura o AI Factory para atender enterprise de ponta a ponta, e o que muda nas interfaces de software nos próximos seis meses.

🎧 Ouça o episódio no Spotify ou YouTube.

Convidado:

Pedrão Oliveira: ⁠https://www.linkedin.com/in/pedro-oliveira-martins/⁠
Medium: ⁠https://poliveiram.medium.com/⁠
Distrito: ⁠https://www.distrito.me/⁠

Capítulos:

00:00 Pedrão Oliveira e o AI Factory do Distrito
04:30 O que muda quando o output é generativo
10:00 Engenharia de IA: LLM, ML e por que dados travam tudo
16:00 Quem contrata e o que pede
20:00 Transformação cognitiva: processo antes de IA
26:00 O mito da produtividade de código
31:00 A analogia do médico de 1950
35:00 O que muda até o fim de 2026

Parceiros do episódio:

A maior parte dos produtos de IA ainda está sendo construída como demonstração de tecnologia com etiqueta de preço.

Essa frase parece dura, mas ela explica boa parte da sensação estranha que o mercado tem produzido nos últimos dois anos. A tecnologia avança num ritmo quase indecente, os modelos melhoram, o custo cai, as demos impressionam, os valuations sobem. Mesmo assim, uma parte desconfortável desses produtos continua difícil de explicar em uma frase simples. O problema não está necessariamente na capacidade técnica de construí-los, mas na dificuldade de comunicar com clareza o que eles fazem e por que importam.

Tony Fadell fala disso de um jeito que desmonta um vício comum do software: o cliente enxerga o produto pela lente do marketing, não pela arquitetura que você usou para montá-lo. A frase incomoda porque ataca um hábito real do setor. Muita gente ainda trata marketing como embalagem da coisa pronta, quando em vários casos ele é o primeiro teste real de se a coisa existe de verdade.

É por isso que tantos produtos de IA parecem mais competentes do que claros. Muitos deles acumulam capacidades impressionantes e conseguem executar tarefas muito diferentes entre si, o que à primeira vista parece uma vantagem evidente.

Escrevem, resumem, programam, desenham, pesquisam, ligam ferramentas, atendem, automatizam fluxos. Mas, para o usuário, essa amplitude raramente se traduz em valor percebido. Quando um produto pode fazer de tudo, fica mais difícil entender qual problema ele resolve melhor do que os outros. E, sem essa clareza, a capacidade deixa de ser uma vantagem competitiva e vira apenas mais uma característica da categoria.

Fadell volta a esse ponto com frequência. Quando times são guiados pela tecnologia, eles falam do que o produto faz e não do motivo pelo qual ele existe. E esse “o que faz” é uma armadilha particularmente sedutora em IA, porque nunca foi tão barato produzir funcionalidades.

Você pluga um modelo poderoso, conecta algumas ferramentas, monta uma interface aceitável, gera uma lista generosa de recursos e, em poucos dias, parece que há um produto ali. O problema é que funcionalidades não formam uma narrativa, capacidades técnicas não definem um posicionamento e uma boa demonstração, por mais impressionante que seja, não cria uma categoria por si só.

Essa distinção ficou mais importante, não menos, depois dos LLMs.

Antes, quando era caro construir, a incompetência estratégica ficava escondida atrás da dificuldade técnica. Muitas ideias ruins morriam no meio do caminho simplesmente porque eram difíceis demais de executar. Agora, a execução inicial ficou barata o suficiente para permitir que muito mais gente chegue até a etapa em que o problema real aparece. E esse problema não é técnico. É entender por que aquilo existe, para quem existe e em qual momento da vida ou do trabalho de alguém ele entra com força suficiente para virar hábito.

Essa ainda é uma discussão que vários builders tratam como detalhe de growth, branding ou go-to-market, quando na verdade ela está no coração da definição de produto.

O exemplo mais útil talvez nem seja IA. Fadell costuma voltar ao iPod quando fala sobre construção de produtos, justamente porque ele ilustra uma ideia que considera fundamental: o produto não era apenas o dispositivo. Era o iPod, o iTunes e a loja de música funcionando como um sistema integrado. O mesmo vale para o iPhone. Ele não venceu porque acumulava mais features numa tabela comparativa contra o BlackBerry. Venceu porque alguém tomou decisões difíceis sobre o que aquele produto era, para quem ele fazia sentido e qual história precisava ser contada para que o mercado entendesse por que aquilo importava.

Essa dimensão costuma ser subestimada por times de produto porque parece menos nobre do que discutir tecnologia e também porque parece mais subjetiva. Mas ela é menos perfumaria do que muita sprint de fábrica de feature.

Quando Fadell diz que o cliente vê o produto pela lente do marketing, ele não está defendendo propaganda, está falando de contexto. O usuário não encontra seu produto no vácuo. Ele o encontra em um feed, numa conversa, numa landing page, numa recomendação, numa dúvida específica, dentro de um orçamento limitado e de uma rotina já congestionada. Se o produto não chega acompanhado de uma história clara o suficiente para atravessar esse ambiente, ele perde antes mesmo da experiência começar.

É por isso que tantos produtos de IA parecem promissores e intercambiáveis ao mesmo tempo.

A OpenAI ajuda a enxergar esse problema porque virou, ao mesmo tempo, referência de capacidade e exemplo de dispersão.

Para muita gente, ela é chat, código, vídeo, agente, busca, interface, plataforma e laboratório. Isso mostra ambição, mas também mostra um risco.

Quando um produto pode ser descrito de tantas maneiras, o mercado até presta atenção, mas começa a perder a clareza sobre qual papel aquele produto quer ocupar de forma dominante. Em categoria nova, amplitude demais pode parecer poder, mas também pode parecer que a empresa ainda não decidiu qual verdade quer fixar na cabeça do usuário.

Em categorias novas, a narrativa não é apenas o texto que acompanha o produto, ela é o mecanismo que organiza o produto na cabeça do usuário.

É aqui que a maioria dos builders de IA ainda parece presa a uma crença antiga do software: a ideia de que, se a tecnologia for boa o bastante, o mercado resolverá o resto.

Só que isso sempre foi apenas meia verdade, e em IA está ficando menos verdadeiro a cada trimestre. À medida que os modelos se aproximam em capacidade percebida, mais valor migra para outra camada. Valor passa a estar menos na distribuição e mais na interpretação, menos na performance e mais na legibilidade e menos na inteligência do sistema e mais na clareza da promessa.

Dito de outro jeito, a IA tornou muito mais barato construir algo suficientemente bom. Como consequência, aumentou o prêmio de construir algo memorável.

E memorável aqui não significa chamativo, significa inteligível. Um produto memorável é aquele que o usuário consegue explicar para outra pessoa sem recorrer a uma lista de funções. É aquele que cabe em uma frase simples, com sujeito, verbo e utilidade real.

Quando isso não acontece, o produto passa a depender de uma experimentação quase infinita para que o usuário descubra sozinho seu caso de uso. Isso pode funcionar durante uma fase exploratória, como modelo de negócio, porém, começa a parecer preguiça terceirizada.

A parte mais desconfortável é que muitos times sabem disso e, ainda assim, continuam operando como se a solução estivesse na próxima feature. Mais memória, mais autonomia, mais multimodalidade, mais integrações. Tudo isso pode melhorar a proposta, mas nada disso substitui a escolha central: o que exatamente estamos ajudando alguém a fazer melhor, mais rápido, com menos atrito ou com mais ambição do que antes?

Essa pergunta parece banal até você perceber quantos produtos de IA bilionários ainda têm dificuldade para respondê-la de forma convincente.

Fadell também insiste em outra ideia que vale segurar por mais tempo: o melhor marketing diz a verdade. Essa frase importa porque a verdade, em produto, não é o inventário completo de tudo o que a tecnologia consegue fazer. A verdade é a parte desse conjunto que realmente importa para o cliente certo. Contar tudo quase sempre é uma forma elegante de esconder que você ainda não escolheu o essencial.

Talvez seja exatamente nesse ponto que an era da IA comece a separar ferramentas impressionantes de empresas duráveis. As impressionantes continuam expandindo o cardápio do que conseguem fazer, as duráveis fazem uma escolha mais difícil: editam a própria ambição visível para que o mercado entenda por que aquilo merece existir.

No fim, o erro de muitos builders não é superestimar a tecnologia. É subestimar o trabalho de dar forma inteligível a ela, e essa talvez seja a inversão mais importante deste ciclo.

Durante anos, muita gente tratou narrativa como a parte cosmética do produto. Em IA, narrativa virou parte da arquitetura competitiva. Quem ainda não entendeu isso pode até lançar algo poderoso, mas continuará lançando produtos que impressionam na demo e evaporam na memória.

Subscreva agora

Nesse episódio:

- Como o LCM (Large Consumer Model) personaliza pedidos e é 60x mais barato que modelos internacionais.
- Por que o AILO foi reescrito do zero no AILO 2.0 e o que mudou no framework de decisão autônoma.
- Como o iFood orquestra múltiplos agentes de IA.
- Por que 300 deploys em 4 semanas viraram rotina e o que isso muda no trabalho do PM.
- O erro que a maioria das empresas comete ao implementar IA (plugar API sem governança de dados).
- Como o iFood controla custo de IA com seleção de modelo por tarefa e dashboard de eficiência

Isabela tem passagem por OLX e BanQlub antes de chegar ao iFood, onde lidera o time de inovação e produtos disruptivos. Ela conta como saiu do design, passou por todas as caixinhas de produto, e hoje reescreve o produto mais inovador do Brasil do zero.

Se você trabalha com produto digital, IA aplicada, ou quer entender como uma empresa de 8 mil pessoas realmente escala inteligência artificial, esse episódio é referência.

📺 Assista pelo YouTube
🎧 Ouça pelo Spotify

🔗 Teste o AILO: +55 11 91150-4025
🔗 Conecte com a Isa: https://www.linkedin.com/in/isabellapiratininga/?locale=pt

Capítulos:

00:00 Introdução
01:50 De designer a diretora de produto no iFood
04:41 Aprender errando: o projeto Serendipity na OLX
08:01 Filosofia de liderança da Isa
10:42 Como o iFood construiu cultura de IA desde 2018
17:03 AILO: desafios técnicos de um agente conversacional
20:38 Como garantir que o agente entende a intenção do usuário
23:42 AILO vs app: canibalização ou complementaridade?
28:02 Métricas de sucesso de um produto de IA
31:36 Os agentes do ecossistema iFood: Rose, Chris, Dion
35:17 LCM: o modelo próprio do iFood
39:17 Como escalar IA sem explodir o orçamento
46:19 O que muda no trabalho do PM com IA
52:49 AILO 2.0: o que foi reescrito e por quê

Parceiros do episódio:

Essa frase explica quase tudo que a discussão sobre big corp e IA acerta na superfície e erra no fundo.

A narrativa que domina o Twitter e os painéis de produto é simples: startup constrói rápido, empresa grande move devagar, empresa grande está atrasada. A narrativa faz sentido porque você lança um SaaS em duas semanas, a startup do lado lança em quatro dias, e a empresa grande leva dezoito meses para aprovar uma tela nova. O que ela ignora é o que acontece quando essa empresa grande erra, e mais especificamente o que acontece quando essa mesma empresa erra em escala.

Dentro do The Times, o time de engenharia roda sessões onde o engenheiro escreve o começo do código, pausa, deixa o modelo continuar e depois retoma em cima do output. Há um processo separado de revisão automática que aponta redundância no código, mas sem executar nada, porque AJ tem medo, palavra dele, de autorizar que a IA tome decisões sem que alguém esteja olhando.

A empresa também proíbe qualquer uso de IA para geração de texto, inclusive pelo time de design, porque o contrato implícito com o leitor é que o que está escrito ali passou por um editor que foi a uma zona de guerra cobrir o assunto. Uma matéria gerada sem supervisão encerra esse contrato.

Isso soa conservador até você comparar com o que acontece quando a aposta de velocidade dá errado. O Rabbit lançou um dispositivo com IA cedo demais, com tecnologia que não sustentava a promessa, e foi esquecido em meses. O Lovable construiu velocidade no editor de código e o OpenAI chegou depois com a própria versão porque, do ponto de vista deles, era só uma feature, e features não precisam de startup separada para existir. Para uma empresa de três pessoas, o erro custa a empresa. Para o The Times, o erro custa a credibilidade com um leitor que paga há trinta anos.

Imagine uma empresa financeira que tem 30 mil funcionários em tecnologia. Se essa empresa financeira lançar um modelo que alucina em cima de uma informação regulatória e um cliente tomar uma decisão financeira errada, a consequência é processo, regulação e perda de conta de empresa que ele bancava há vinte anos.

A mesma empresa financeira que parece dormindo faz A/B test em cada botão de aprovação de crédito porque o volume é tão grande que 0,3% de diferença em conversão significa centenas de milhões de reais por ano. A precisão que parece lentidão de fora é uma escolha que faz sentido dentro, e ainda não sei se eu discordaria dela se estivesse no lugar deles.

O que AJ chama de “aprendizado tardio e mais preciso” é exatamente isso: big corp lança menos, mas quando lança, o produto foi validado por dentro de um jeito que startup não tem capacidade de fazer. A taxa de acerto é mais alta porque o custo de errar é maior, e esse cálculo é aritmética.

O problema é que a janela em que esse cálculo funciona pode ser menor do que parece. AJ faz uma aposta que eu acho que vai acontecer antes do que a maioria está contando: quando Apple ou Google liberarem o LLM com acesso ao sistema operacional do celular, o banco vira commodity em um clique.

O modelo sabe que existe outro banco com taxa menor e oferece a transferência sem que o cliente precise abrir nenhum app. O jornal vira agregação que o modelo sintetiza de graça. A relação construída com o cliente durante décadas deixa de ser barreira de saída e vira, na melhor das hipóteses, um fator de desempate.

Quando isso acontecer, a estrutura que justificou o ritmo lento vai precisar responder a uma velocidade para a qual ela não foi desenhada, com regulação que ainda não existe, diante de clientes que terão aprendido a deixar o modelo decidir por eles, e contra concorrentes que passaram os últimos anos aprendendo exatamente o que acontece quando você erra barato.

1) Compreender, "definir" e "traduzir" os resultados financeiros para diferentes áreas da empresa

Aqui, vale um breve histórico para ilustração: em 2003, ocorreu um marco para o setor automobilístico no país, o lançamento do Ford EcoSport. O modelo basicamente popularizou os SUVs no Brasil e, durante seus primeiros anos, não tinha concorrente direto. A partir de 2012, o EcoSport (que havia sido criado para o Brasil) passou a ser globalizado e, por conta disso, passou por alterações para atender às demandas dos diferentes países (em específico, seu tamanho foi reduzido, ficando "pequeno" para o gosto brasileiro).

Subscreva agora

Como consequência, se antes a empresa havia se planejado para vender 300 mil carros para aquele ano, na realidade teve que arcar com uma dura atualização de expectativas.

2) Ser realista/pôr os pés no chão

Em 2013, a Ford se viu diante de um cenário desafiador, especialmente por conta do contexto macroeconômico, já teve que arcar com custos de carros produzidos amplamente levando em consideração um cenário mais otimista. E é aqui que o papel da área de finanças foi extremamente estratégico, orientando a tomada de decisões de negócios. Ao analisar cuidadosamente o portfólio de produtos na América do Sul, identificaram oportunidades valiosas: a Ranger e os demais modelos importados destacaram-se como altamente lucrativos.

Para chegar a essa conclusão, a equipe da área de finanças teve que levar em consideração os custos de manufatura em Camaçari/BH e São Bernardo do Campo/SP: se o modelo não se pagasse (ou seja, se o CMV não estivesse sendo atingido), significava que haviam encontrado um problema ali.

Isso se deu por conta de uma demanda restrita, bem menor, e com alta disponibilidade: ou seja, as margens acabaram ficando extremamente menores para a companhia.

Dentro desse contexto, o processo de fechamento de fábricas (que já havia sido avaliado anteriormente) foi reforçado: a estratégia de atuação da empresa, não só no Brasil mas nos países vizinhos, foi revisitada, levando a empresa a fechar algumas fábricas.

Claro, essa decisão levou anos para se consolidar: foram feitas incontáveis avaliações de diferentes cenários, considerando o padrão de downturn de vendas de automóveis da região, historicamente marcada por altos e baixos.

O que aconteceria se o dólar fosse valorizado, ou ao contrário, se caísse? E se um concorrente criasse um modelo com mais apelo ao consumidor final, aumentando seu tamanho em 10 cm? E se uma crise econômica ocorresse de alguma forma? Etc.

Vale ressaltar que grande parte desses estudos foi feito antes da pandemia, que resultaram no fechamento da fábrica de São Bernardo do Campo em 2019: durante esse período, nem a pior projeção realizada por eles foi tão ruim como durante o período de pandemia de Covid-19.

3) Decidir com a ̶c̶a̶b̶e̶ç̶a̶ bolso, não com o coração

Uma vez tomada a decisão de fechada das fábricas em território nacional, a equipe responsável passou a se deparar com diversas barreira emocionais por parte de alguns colaboradores.

O desafio, claro, era enorme: como convencer internamente a organização e a própria sede, em Chicago, a abandonar o 8% de share de mercado da época para 3%? Como lidar com a percepção de consumidores que poderiam entrar em desconfiança com a marca, acreditando que a empresa pudesse deixar de atuar no país a qualquer momento?

Foi necessário um extenso trabalho para conseguir traçar uma estratégia certeira durante esse reposicionamento.

A equipe de finanças conta que a principal estratégia adotada pela companhia foi o de “não deixar o cliente na mão”: ou seja, concentrar esforços tanto por meio da comunicação como pelos serviços prestados de que a Ford continuaria atuando no Brasil fortemente, descontinuando algumas linhas de carros, mas mantendo a assistência a cliente até 2030, e principalmente dando todo o suporte necessário para focar nos modelos que continuariam a ser comercializados.

E é aqui que outra tomada de decisão de negócios foi fundamental: a ênfase em apenas dois modelos de carros mais rentáveis, que não competiam tão fortemente pelo preço, mas sim pela qualidade dos automóveis e serviços prestados: a Ranger e carros importados, em especial o Mustang.

Esse esforço foi tremendo para uma empresa que, até então, abordava diferentes públicos-alvo por conta dos distintos modelos de automóveis comercializados: as pessoas que pensavam em comprar um carro de pequeno porte basicamente deixaram de ser atendidas, e o posicionamento da marca Ford foi redirecionado para o foco em picapes e carros premium.

O resultado

Tomar a decisão de reestruturar a operação foi um desafio significativo para a Ford, especialmente porque a estratégia de focar em linhas específicas no mercado de automóveis era pautada por projeções e tendências, além do histórico de mercado. Ainda assim, poderia ocorrer algum tipo de cenário, no qual todos esses esforços não se consolidariam.

Entretanto, não foi isso que ocorreu. Um exemplo marcante é a Ranger, que fechou o ano de 2025 com o maior volume de vendas da sua história, com mais de 34 mil emplacamentos.

Esse desempenho garantiu também a maior participação de mercado em 2025, de 29,76%, e a vice-liderança do segmento de picapes médias.

Todos os executivos da empresa, depois do sucesso do plano, passaram a considerar as premissas da área de finanças ainda mais em seu cotidiano. Isso fez com que a Ford, como um todo, passe a tomar decisões mais dosadas e organizadas internamente, seguindo premissas pré-definidas.

Depois de toda ela, a Ford na América do sul parrou ser uma espécie de start-up em comparação aos EUA: são uma empresa pequena, com risco consequentemente menor, o que os permite testar hipóteses com mais frequência.

Atuação futura da Ford

O mapeamento do processo mental do consumidor para a compra de um automóvel é, de forma simplificada, por meio do sentimento de “desejo” durante sua primeira compra. Ou seja, quando ele compra o primeiro carro, a tomada de decisão tem um quesito “emocional” considerável, buscando por autoafirmação e exaltando a conquista financeira.

Entretanto, quando avaliamos a segunda compra desse consumidor, muitas vezes o sentido racional impera: eles já tem consciência em relação as qualidades e problemas do modelo e da marca como um todo, e é aqui que a estratégia do ponto de vista de produto da Ford passou a ser mais enfática.

É aqui que o aplicativo FordPass desempenha uma função central: por meio dele, é possível monitorar determinadas informações do carro remotamente, por exemplo, avisando caso uma revisão precise ser feita.

Tutorial de uso aplicativo FordPass no Brasil.

Vale dizer que a conectividade é apenas um dos pilares quando a Ford olha para a mobilidade do futuro, cenário com o qual está comprometida, colaborando com a revolução elétrica no mundo. A Ford pretende investir U$ 50 bilhões globalmente na produção de carros elétricos e baterias.

Para se ter ideia, o faturamento anual da Ford global é de U$ 12 bilhões: ou seja, eles irão renovar todo seu portfólio de produtos por meio desse nível de investimentos.

Insights da perspectiva de produtos

Para profissionais que atuam na área de produto, é impossível não pensar no framework de tempo de vida de produto, ou seja, na estratégia usada com o intuito de divulgar e saber por quanto tempo um produto pode ser vendido sem perder o seu valor. Esse framework, claro, varia de acordo com a categoria em que será inserido.
Vale uma análise imparcial e quantitativa elaborada para que possamos entender se determinado produto deve ou não permanecer no portfólio da empresa a partir do seu posicionamento.

Em especial, a questão envolvendo o desapego emocional: muitos produtos continuam disponíveis para o mercado meramente porque “sempre foi assim”, ou porque determinado executivo que fez seu lançamento no passado, entre diversas outras justificativas.

Vale uma análise imparcial e quantitativa elaborada para que possamos entender se determinado produto apenas está “sugando” recursos da organização, ou efetivamente deve ser deixado de lado (extraindo todo seu potencial de mercado até o final, claro).

A seleção de pessoas chave dentro de diferentes áreas, uma vez que a decisão foi tomada de descontinuidade, também foi muto bem aplicada pela Ford: a busca por aliados passa não só pela capacidade profissional, mas também pelo momento de vida da pessoa: ou seja, dependendo do contexto da carreira, pode não fazer sentido adotar determinadas ações.

Por fim, vale ressaltar o acompanhamento d ciclo de vida do produto é essencial para fazer uma boa gestão financeira e comercial qualquer organização. A principal razão para isso é que esse acompanhamento possibilita a aplicação de estratégias de negócio e atuação das áreas comercial e de marketing compatíveis com a etapa de evolução do produto que está sendo comercializado no mercado.