Fundador de empresa tecnológica e ex-vice-presidente de Produto afirma que a IA está a tornar as equipas de produto piores — não melhores

Adam Root ocupou cargos de vice-presidente de Produto em várias empresas tecnológicas. Atualmente, é o fundador da Root Ventures, onde desenvolve produtos SaaS orientados por fluxos de trabalho.

Conversámos com Adam para perceber como a IA está a mudar o ciclo de vida dos produtos — e como, ao longo do processo, está efetivamente a tornar algumas equipas piores. Eis o que nos disse.

A IA está a tornar as equipas de produto piores

A IA está a tornar a maioria das equipas de produto piores, não melhores — porque elimina a fricção que antes protegia as equipas de más decisões.

Ao longo dos últimos 17+ anos, escalei plataformas SaaS, liderei iniciativas impulsionadas por IA e obtive resultados mensuráveis, incluindo o crescimento da receita de $20k para $400k MRR e a concretização de um impacto à escala empresarial. No início da minha carreira, acreditava que a parte mais difícil era desenvolver, lançar funcionalidades, escalar equipas e executar um roteiro. O que aprendi, especialmente nos últimos anos, é que o verdadeiro desafio consiste em transformar a ambiguidade em convicção. A IA tornou impossível ignorar essa distinção. 

Hoje, qualquer pessoa pode gerar um protótipo ou lançar rapidamente um produto utilizando ferramentas de IA, mas a maioria das equipas continua a ter dificuldade em transformar isso numa tração real. Vejo consistentemente equipas técnicas fortes a desenvolver mais depressa, mas sem uma tese de produto clara. Acrescentam IA a fluxos de trabalho que nunca foram concebidos para ter sucesso. O resultado é mais produção, mas não mais impacto.

Essa perceção mudou fundamentalmente a forma como encaro a liderança de produto. Agora trato cada produto como um sistema de verdade, em vez de um conjunto de funcionalidades. Tudo começa por compreender profundamente o problema, validá-lo com evidências e sequenciar as decisões de forma a criar alavancagem. Só então a IA se torna um verdadeiro multiplicador. Sem essa base, limita-se a acelerar o ruído.

Por isso, atualmente, o meu foco está menos nas ferramentas e mais na criação de clareza, alinhando as equipas em torno do que importa, da razão pela qual importa e da forma como impulsiona resultados. Porque, quando o sistema está correto, a execução acumula-se.

Construir um portefólio nativo de IA

Atualmente, estou a construir um pequeno portefólio de produtos SaaS nativos de IA e orientados por fluxos de trabalho em diferentes áreas, cada um concebido para ocupar o centro de comportamentos reais dos utilizadores, em vez de simplesmente acrescentar funcionalidades.

A Sotia é um sistema de inteligência baseado em dados comportamentais, começando pelo Slack, que ajuda a liderança a compreender o estado da execução em tempo real. Traduz padrões de comunicação em sinais sobre alinhamento, velocidade de decisão e risco, criando efetivamente uma nova camada entre a atividade bruta e a perceção dos executivos.

Em paralelo, estou a desenvolver a VowVista, uma plataforma de mercado no setor dos espaços para casamentos, focada em resolver o problema da confiança na tomada de decisões por parte dos compradores da Geração Z. Aborda uma compra fragmentada e emocional através da combinação de transparência, dados estruturados e fluxos de trabalho orientados, ajudando os utilizadores a passar da exploração ao compromisso.

Além disso, continuo a desenvolver plataformas nativas de IA para a construção e as operações no terreno, onde captamos dados multimodais, como voz, fotografias e vídeo, diretamente no terreno e transformamo-los em informação estruturada e acionável para operadores e executivos.

Em tudo isto, o elemento comum é desenvolver produtos que funcionam como sistemas de registo e sistemas de inteligência, concebidos para fluxos de trabalho reais, com um modelo de entrega que combina iteração rápida com fiabilidade de nível de produção.

Porque devem os líderes de produto concentrar-se no sistema e não na IA

A IA não é o produto. O sistema à sua volta é.

A maioria das equipas começa por se concentrar no modelo, na funcionalidade ou na capacidade. Mas, na prática, o modelo é o elemento menos diferenciado e, muitas vezes, a parte mais fácil. O verdadeiro trabalho está em tudo o que o rodeia: os dados, a integração com os fluxos de trabalho, a UX, o modelo de confiança e a forma como o resultado impulsiona uma decisão ou ação real.

Se fizer isso mal, a IA fará com que o seu produto pareça impressionante sem o tornar útil. Lançará funcionalidades que funcionam bem numa demonstração, mas que não são adotadas, porque não estão integradas na forma como os utilizadores trabalham ou tomam decisões.

Se fizer isso bem, a IA torna-se um multiplicador. Transforma dados de entrada desorganizados em informação estruturada, reduz a fricção nos fluxos de trabalho reais e cria alavancagem em todo o sistema.

Se eu soubesse disso mais cedo, teria evitado investir demasiado na «inteligência» antes de validar o fluxo de trabalho. Em alguns casos, criámos capacidades impressionantes que funcionavam tecnicamente, mas não alteravam o comportamento dos utilizadores porque não estavam integradas na forma como o trabalho era realmente feito. Tivemos de voltar atrás e redesenhar em torno do fluxo de trabalho, não do modelo.

Como os sistemas baseados em evidências podem melhorar a execução

Passei de criar funcionalidades a criar sistemas baseados em evidências antes de escrever código — utilizando a IA como camada de síntese e validação numa fase inicial do processo.

No passado, mesmo as equipas fortes passavam relativamente depressa da descoberta para as especificações. Esse modelo falha num mundo aumentado pela IA porque o custo de criar diminuiu imenso. É possível gerar e lançar soluções mais depressa do que validar se elas devem existir. O que isto cria é um novo modo de falha: as equipas escalam as ideias erradas a uma velocidade incrível.

A descoberta precisa agora de se tornar uma função contínua e orientada por sistemas, não uma fase. Isso significa:

• Agregar sinais reais à escala, incluindo o comportamento dos utilizadores, dados de suporte, análises de ganhos e perdas e contributos qualitativos
• Utilizar a IA para sintetizar padrões entre esses contributos, e não apenas para os resumir
• Mapear explicitamente os problemas para os fluxos de trabalho e medir se o produto está realmente a resolvê-los
• Revalidar continuamente os pressupostos à medida que chegam novos dados

Por exemplo, utilizo instruções estruturadas em várias fontes de dados para identificar problemas recorrentes, mapeá-los para fluxos de trabalho e testar explicitamente se o produto está realmente a resolvê-los. Este processo invalida frequentemente as ideias iniciais ou reformula-as de forma significativa antes de chegarem às fases de design ou engenharia.

O que mudou, como resultado, foi a qualidade da convicção. Criamos menos coisas, mas as coisas que criamos estão muito mais alinhadas com problemas reais. Isto também altera a forma como as equipas trabalham. Em vez de debater opiniões, reagimos a evidências sintetizadas. Por isso, para mim, a IA tem menos que ver com acelerar a execução e mais com aumentar a precisão daquilo que escolhemos executar.

Como a IA está a condensar todo o fluxo de trabalho, desde os sinais até ao lançamento

Eis um fluxo de trabalho completo, baseado em IA, que utilizo para passar de sinais brutos dos utilizadores para um ciclo de produto lançado e validado.

Começa com a agregação de sinais. Reúno dados qualitativos e comportamentais, incluindo entrevistas com casais, discussões no Reddit, avaliações de locais, pontos de abandono no funil e perguntas recebidas. Em vez de analisar cada elemento individualmente, utilizo a IA para sintetizar todas as fontes e identificar problemas recorrentes, a frequência com que surgem e os pontos onde os utilizadores ficam bloqueados no processo de decisão.

A partir daí, passo à estruturação dos problemas. A IA ajuda a agrupar esses sinais em formulações claras de problemas, associadas a momentos específicos do fluxo de trabalho. Depois, submeto esses problemas a uma análise rigorosa, perguntando: «É frequente, doloroso e solucionável pelo produto?»

Segue-se a definição da solução. Utilizo a IA para explorar rapidamente diferentes formas de resolver o problema, não apenas através de funcionalidades, mas também de alterações ao fluxo de trabalho. A chave está em gerar rapidamente várias abordagens e, depois, restringi-las com base na que melhor se adapta ao comportamento dos utilizadores.

Depois, passamos à criação e instrumentação. Com ferramentas de desenvolvimento assistido por IA, passamos rapidamente do conceito para uma versão funcional, mas com a instrumentação integrada desde o início. Acompanhamos se os utilizadores interagem com o novo fluxo de trabalho, onde o abandonam e se este melhora a confiança na decisão ou a progressão.

A partir daí, transforma-se num ciclo de aprendizagem. A IA analisa padrões de utilização, feedback qualitativo e casos-limite para identificar o que está a funcionar e o que não está. Observamos se a alteração modificou efetivamente o comportamento, e não apenas se os utilizadores interagiram com ela.

Por fim, os resultados alimentam a iteração ou a remoção. Se o fluxo de trabalho melhorar os resultados, expandimo-lo. Se não melhorar, aperfeiçoamo-lo ou removemo-lo rapidamente.

O Claude, ligado aos dados do meu produto e aos sinais dos utilizadores, trata da maior parte deste fluxo de trabalho.

Como a IA pode criar uma falsa sensação de confiança

O melhor resultado da IA que tenho observado é um aumento significativo da rapidez com que se alcança clareza. A IA condensou em horas trabalho que costumava demorar dias, especialmente na descoberta, na síntese e na definição inicial do produto. Posso analisar muito mais contributos, identificar padrões mais rapidamente e submeter ideias a uma análise rigorosa antes de a equipa comprometer recursos. Em termos qualitativos, isto conduziu a uma melhor formulação inicial, a menos ideias fracas a chegarem às discussões sobre o roteiro e a um alinhamento mais claro entre produto, design e engenharia.

Também melhorou o ritmo de produção no próprio processo de criação de produtos. No último ano, utilizei fluxos de trabalho assistidos por IA para passar do conceito a um produto funcional de forma muito mais rápida do que os ciclos tradicionais permitiriam. Isto inclui passar da formulação do problema para a arquitetura, os PRD e software utilizável numa fração do tempo habitual. O benefício não é apenas a velocidade. É a capacidade de testar fluxos de trabalho reais mais cedo, o que melhora a velocidade de aprendizagem.

Contudo, nem tudo é positivo. A IA pode criar uma falsa sensação de confiança. As equipas podem confundir um resultado polido com qualidade do produto. Um protótipo parece convincente, a especificação parece completa e todos sentem que está a haver progresso, mesmo quando o fluxo de trabalho subjacente, o modelo de confiança ou a necessidade do utilizador continuam por resolver. Também já vi a IA aumentar o ruído quando é utilizada sem uma tese de produto sólida. Pode gerar mais ideias, mais textos, mais tarefas e mais artefactos do que uma equipa consegue avaliar realisticamente, o que pode, na verdade, tornar a priorização pior.

Adam partilha

O melhor resultado da IA que estou a observar é um aumento significativo da rapidez com que se alcança clareza. A IA reduziu trabalhos que antes demoravam dias a apenas algumas horas, sobretudo na descoberta, na síntese e na definição inicial do produto.

Onde a IA fica aquém no produto

O maior fracasso da IA foi, claramente, não ter proporcionado as melhorias significativas que eu esperava no discernimento de produto e no impacto sustentado do produto.

Inicialmente, pensei que a IA iria melhorar significativamente a priorização e a qualidade do roteiro do produto, ao tornar os padrões evidentes. Ajuda, de facto, a revelar padrões, mas não resolve aquilo que realmente importa. A parte difícil continua a ser interpretar compromissos, compreender efeitos de segunda ordem e assumir uma direção perante a incerteza. A IA informa esse processo, mas não o substitui. Não a vi produzir consistentemente melhores decisões de produto por si só.

Também ficou aquém no impulsionamento da adoção real. As funcionalidades de IA costumam ser excelentes em demonstrações, mas isso não se traduz em utilização repetida, a menos que estejam profundamente integradas nos fluxos de trabalho reais. Já vi equipas lançar funcionalidades de IA impressionantes que os utilizadores experimentam uma vez, mas às quais não regressam, porque o produto não alterou comportamentos nem passou a fazer parte da forma como o trabalho é realizado.

Outra lacuna está na redução da complexidade. Esperava que a IA simplificasse a forma como os produtos são desenvolvidos e operados, mas, em muitos casos, introduz novas camadas, incluindo lógica de instruções, casos-limite, desafios de avaliação e considerações relacionadas com a confiança. Em vez de eliminar trabalho, transfere-o para novas áreas que continuam a exigir uma forte disciplina de produto e de engenharia.

Porque é que a responsabilidade tem de continuar a ser humana

Utilizo intensivamente a IA sempre que a escala e o reconhecimento de padrões são importantes, e mantenho os seres humanos envolvidos sempre que o discernimento, o risco ou o bom gosto determinam o resultado.

Do lado da IA, recorro sobretudo a ela na descoberta e na síntese. Introduzo transcrições, pedidos de suporte, dados de ganhos e perdas e sinais comportamentais para identificar problemas recorrentes, quantificar a frequência e associar esses problemas aos fluxos de trabalho. Também é útil na priorização inicial, não para tomar decisões, mas para testar a robustez das premissas, mostrando compromissos, efeitos de segunda ordem e formulações alternativas que talvez não tivesse considerado. Na experimentação, a IA ajuda a gerar hipóteses, preparar variantes e analisar rapidamente os resultados, sobretudo quando se lida com grandes volumes de feedback qualitativo.

As áreas que mantenho explicitamente sob responsabilidade humana são a convicção e o compromisso. As decisões finais de priorização, a sequência do roteiro e aquilo que escolhemos não desenvolver continuam a caber à equipa de liderança e a mim. O mesmo se aplica às decisões de UX que exigem bom gosto, confiança e contexto emocional. As decisões técnicas também são lideradas por pessoas, porque envolvem pensamento sistémico a longo prazo, tolerância ao risco e restrições organizacionais que a IA não consegue interiorizar completamente.

A razão é simples: a IA é excelente a condensar informação e a expandir o espaço de soluções, mas não assume as consequências. A liderança de produto resume-se, em última análise, a tomar decisões irreversíveis ou dispendiosas perante a incerteza. Essa responsabilidade tem de continuar a ser humana.

Porque é que os líderes de produto têm de estar atentos à falsa confiança em grande escala

Os líderes de produto subestimam frequentemente o risco de uma falsa confiança em grande escala.

Os sistemas de IA são muito bons a produzir resultados que parecem corretos, mesmo quando não o são. O perigo não está numa falha evidente. Está na exatidão plausível. Algo que parece correto, soa confiante e está errado de formas que não são imediatamente detetáveis.

Em pequena escala, um utilizador pode detetá-lo. À escala de um produto, esse mesmo erro é repetido em milhares de interações, moldando silenciosamente decisões, fluxos de trabalho e resultados.

Tenho visto isto surgir em áreas como a interpretação de documentos, as recomendações e a automatização de fluxos de trabalho. O sistema tem um desempenho suficientemente bom na maior parte do tempo para que os utilizadores comecem a confiar nele, mas é nos casos extremos que reside o verdadeiro risco. E esses casos extremos acarretam frequentemente as consequências mais graves.

O que torna isto especialmente perigoso é o facto de os instintos tradicionais de desenvolvimento de produtos não o detetarem. Não se vê uma quebra na utilização nem uma falha. Vê-se envolvimento. O produto “funciona”. Até deixar de funcionar.

A mitigação não passa apenas por modelos melhores. Passa por conceber tendo em vista a confiança e a verificação:

Adam Partilha

Os líderes de produto subestimam frequentemente o risco de uma confiança falsa à escala…O que torna isto especialmente perigoso é o facto de os instintos tradicionais de desenvolvimento de produtos não o detetarem. Não se vê uma quebra na utilização nem uma falha. Vê-se envolvimento. O produto “funciona.” Até deixar de funcionar.

• Mostrar provas, não apenas respostas
• Expor o grau de confiança e a incerteza
• Criar pontos de verificação claros com intervenção humana
• Instrumentar o sistema para detetar quando está errado, não apenas quando é utilizado

O risco está em presumir que a precisão aumenta linearmente com a utilização. Na realidade, o risco acumula-se mais rapidamente do que a precisão.

Como o discernimento da IA pode enfraquecer

A IA tem tido mais dificuldades nos casos em que o produto precisa de compreender o que está em jogo para as pessoas, a ambiguidade e o custo de estar errado — e não apenas de gerar uma resposta plausível.

Um bom exemplo encontra-se nos fluxos de trabalho orientados para a conformidade ou de elevada confiança. Trabalhei em conceitos de produto em que a IA consegue extrair informações de documentos, assinalar problemas e recomendar as ações seguintes. À primeira vista, isto parece um caso de utilização perfeito para a IA. Na prática, o problema é que o modelo pode produzir uma resposta que parece muito confiante, mas que ignora um contexto importante, interpreta erradamente uma cláusula ou não compreende por que razão uma exceção é mais importante do que outra.

Isto cria imediatamente um problema de confiança. O utilizador não está a perguntar: “Este resultado foi impressionante?” Está a perguntar: “Posso confiar nisto sem criar riscos a jusante?”

O que aprendi foi que a IA é frequentemente fraca no discernimento quando:

• O contexto é parcial
• As consequências do erro são assimétricas
• O utilizador precisa de uma explicação, não apenas de um resultado

Como a IA está a reestruturar as equipas

A IA alterou a configuração das minhas equipas de produto, que passaram de silos organizados por funções para equipas mais pequenas, integradas e orientadas para sistemas.

No passado, as equipas estruturavam-se em torno de passagens de testemunho claras: o produto define, o design concebe, a engenharia desenvolve e os dados são analisados. Esse modelo deixa de funcionar quando a IA comprime a execução e introduz sistemas probabilísticos que exigem ciclos de feedback estreitos.

Agora, tendo a privilegiar menos pessoas capazes de atuar entre diferentes áreas. Espera-se que os gestores de produto se aprofundem mais nos dados, na conceção de instruções e na lógica dos fluxos de trabalho. Os engenheiros estão mais próximos do problema e do contexto do utilizador, e não apenas da implementação. O design diz menos respeito a ecrãs estáticos e mais a padrões de interação, confiança e à forma como o sistema se comporta quando está incerto ou errado.

Também assisti ao surgimento de novas responsabilidades, em vez de funções inteiramente novas. Por exemplo:

• Assumir a responsabilidade pelo “comportamento do sistema” em todos os casos extremos, e não apenas pelo percurso ideal
• Definir limiares de confiança e momentos de intervenção humana
• Gerir a qualidade dos dados e os ciclos de feedback como preocupações de produto de primeira ordem

Como os líderes de produto devem utilizar a IA

O meu conselho é simples: não utilize a IA para avançar mais depressa. Utilize-a para acertar mais vezes.

Atualmente, a maioria das equipas está concentrada na velocidade, em mais funcionalidades, em ciclos mais rápidos e em resultados mais céleres. Esse é o benefício óbvio. Mas a velocidade sem clareza apenas amplia os erros.

O Conselho de Adam

O meu conselho é simples: não utilize a IA para avançar mais depressa. Utilize-a para acertar mais vezes…A verdadeira mudança é esta: desenvolver deixou de ser o fator limitador. O discernimento é que o é.

A verdadeira mudança é esta: desenvolver deixou de ser o fator limitador. O discernimento é que o é.

Por isso, enquanto líder de produto, o seu papel passa menos por conduzir a execução e mais por:

• Definir os problemas certos
• Sequenciar decisões
• Garantir que aquilo que é construído altera efetivamente o comportamento dos utilizadores

Utilize a IA para expandir o seu pensamento, sintetizar sinais e testar ideias sob pressão. Mas não abdique das decisões difíceis. É aí que está o valor.

Além disso, reformule a forma como a sua equipa trabalha:

• Trate a descoberta como um processo contínuo, não como uma fase.
• Conceba para criar confiança, não apenas funcionalidade.
• Construa sistemas, não funcionalidades.

E, acima de tudo, resista à tentação de evitar o pensamento difícil.

Acompanhe

Pode acompanhar Adam Root no LinkedIn enquanto continua a desenvolver a Sotia, a VowVista e os outros produtos SaaS do seu portefólio.

Haverá mais entrevistas com especialistas no Clube CPO!