Como a IA está a levar os gestores de produto para além da sua função

O percurso até à gestão de produto

Sou gestor de produto há mais de 15 anos. No início da minha carreira, fiz tudo o que pude, incluindo design, vendas, consultoria, marketing e até programação, na época do PHP — que horror.

Entrei na gestão de produto porque gostava realmente de alternar entre vários temas e de interagir com utilizadores, programadores, executivos, etc. Também tinha um bom olho para o design e um bom sentido para avaliar produtos. Depois de muita pesquisa, descobri que existia uma função que se adequava muito bem a esse perfil — Gestão de Produto. Candidatei-me, por isso, à minha primeira função de PM e foi assim que aqui cheguei.

Trabalhei em todo o tipo de setores: B2B, B2B2C, retalho e software para consumidores. Comecei a ensinar gestão de produto na General Assembly há mais de uma década e, depois disso, lancei os meus próprios cursos online de forma independente, na Udemy e, mais tarde, no LinkedIn Learning. Atualmente, tenho mais de 1,6 milhões de alunos no total nas duas plataformas. Também participei em muitas conferências sobre gestão de produto e de projetos, incluindo uma colaboração com a Google para ensinar um curso de produto em Kiev, na Ucrânia.

Atualmente, trabalho com a Probably.dev, uma aplicação de agente de dados determinístico financiada pela a16z. Somos uma equipa pequena, por isso não sou apenas PM, mas também engenheiro, comercial, designer, etc.

A nossa aplicação é uma aplicação nativa para computador que realiza ciência de dados determinística ao nível de um doutoramento, com visualizações de apoio, para responder diretamente a qualquer consulta em linguagem natural, sem que os dados sensíveis saiam do seu computador. Pode pensar nela como um "copiloto de dados". Trabalhamos diretamente sobre esquemas de armazéns de dados (por exemplo, BigQuery, Snowflake, Clickhouse, etc.), bem como com ficheiros locais como CSV, JSON e Parquet. Todas as respostas fornecidas pelo nosso agente são rastreáveis e reproduzíveis por uma pessoa, pelo que as alucinações típicas dos LLM não são um problema. Não somos apenas mais um agente gerador de SQL e conseguimos lidar com milhares de milhões de linhas/colunas e esquemas complexos com dezenas de milhares de tabelas.

You should also read

• Gestor de Projetos e Educador com IA Partilha um Fluxo de Trabalho Simples com IA que Altera Fundamentalmente a Forma como os Projetos Funcionam

• Os fluxos de trabalho de IA do mundo real utilizados pelo Diretor de Entregas de uma agência de implementação do Asana

Como a IA ajuda as equipas a fazer mais por pessoa

A IA teve um grande impacto no meu trabalho. Antes era "apenas um PM". Isto parece disparatado, porque os PM fazem imensas coisas, mas agora consigo contribuir também noutras áreas, como engenharia e vendas. E isso ajuda a acelerar o trabalho da equipa. À medida que a IA transforma a gestão de projetos, os limites tradicionais das funções tornam-se mais fluidos.

Tarefas demoradas, como a pesquisa e a análise, são muito mais rápidas, e o tempo poupado permite ter muito mais contacto direto e comunicação com as partes interessadas. Também permite tomar decisões mais rapidamente.

Grande parte do trabalho de um PM consiste em garantir que todas as outras pessoas conseguem desempenhar as suas funções de forma eficaz. Assim, como consigo fazer ainda mais por mim próprio, conseguimos realizar muito mais por pessoa. Esta abordagem híbrida entre pessoas e IA está a tornar-se essencial para as equipas modernas de entrega.

Porque é que uma compreensão profunda da IA permite aos gestores de produto fazer quase tudo

Quanto mais me envolvo nesta área, mais percebo como é elevada a curva de aprendizagem para utilizar a IA/LLM de forma eficaz e eficiente, bem como a subcompetência de a adaptar aos fluxos de trabalho que as pessoas à nossa volta ou nas nossas equipas preferem. Isto reforça ainda mais a minha convicção de que todas as pessoas numa empresa devem estar profundamente familiarizadas não só com os LLM em geral e com os modelos disponíveis, mas também com a multiplicidade de ferramentas do ecossistema que os rodeiam, como os MCP, modalidades como CLI e GUI e, mais importante ainda, a arquitetura transformer. Para quem pretende aprofundar os seus conhecimentos, explorar livros sobre gestão de projetos de IA pode fornecer informações valiosas sobre a implementação eficaz destas tecnologias.

Trabalhar bem com IA no vasto mar de conteúdo e ferramentas de baixa qualidade gerados por IA que existe atualmente é uma competência que temos de aperfeiçoar, e isso só se consegue com experiência. É necessário compreender como funcionam os LLM e aquilo que conseguem ou não fazer bem, para tirar o máximo partido deles e obter um desempenho ideal.

Muitos produtos e ferramentas SaaS "revolucionários" que existem por aí parecem ser boas soluções — para criar PRD, por exemplo —, mas descobri que 99% de tudo o que é necessário fazer pode ser feito por nós próprios, de forma mais barata, rápida, personalizada e muito melhor. Isto é, desde que se tenha uma compreensão dos conceitos acima referidos e as competências necessárias para utilizar os LLM de forma eficaz.

É como aqueles anúncios televisivos em que aparece uma pessoa a fazer algo simples e, depois, mostram como é "difícil" e tentam vender-lhe um dispositivo completo para resolver esse caso de utilização minúsculo. Em vez de cortar uma banana em pedaços com uma faca, como uma pessoa normal, querem vender-lhe um cortador em forma de banana que corta todos os pedaços de uma só vez...

A faca é um LLM e o cortador de bananas é uma aplicação de nicho inútil. Aprenda a usar a maldita faca. Compre uma de boa qualidade, use-a, aprenda a utilizá-la e deixe de comprar coisas estúpidas só porque o Twitter tecnológico lhe diz que alguma aplicação SaaS aleatória acabou de «tornar os designers obsoletos» ou «matar a programação».

Basicamente, não há quase nada que não possa fazer com um LLM numa CLI, num navegador Web e, ocasionalmente, com uma ferramenta de automatização aberta e independente da tarefa, como o n8n.

Poupe o seu dinheiro e aprenda a construir coisas que reflitam a sabedoria das suas experiências adquiridas, em vez de aceitar o resultado de uma aplicação SaaS que apareceu de um dia para o outro.

A única situação em que isto não se aplicaria seria no caso de ferramentas de finalidade única, especificamente centradas na resolução de problemas relativamente aos quais a arquitetura transformadora dos modelos de fronteira comuns (ou seja, não ajustados) apresenta falhas inerentes. Por exemplo, ciência de dados ou matemática em grande escala.

Como começar a aprender sobre IA enquanto gestor de produto

A melhor parte dos LLM é poder perguntar-lhes como aprender sobre eles. Se for um aprendiz visual como eu, o YouTube é a cereja no topo do bolo; há imensos recursos bons sobre IA e LLM nesse serviço.

Se estivesse a começar de novo, abordaria a aprendizagem desta forma: diga a um LLM que quer aprender tudo sobre a área da IA/LLM, adaptado ao seu nível de compreensão técnica. Pode até instruí-lo a fazer-lhe perguntas progressivamente mais técnicas para compreender o seu nível atual de competência em qualquer área relacionada com IA/LLM, começando pelos fundamentos. E, quando chegar a um ponto que ultrapasse os seus conhecimentos, pode pedir-lhe que recomende tópicos para aprender, desde os conceitos básicos da arquitetura transformadora até ao funcionamento de uma aplicação como o ChatGPT.

A ideia é obter uma lista de tópicos para aprender e, depois, pesquisar cada um deles no YouTube para encontrar um vídeo que ajude a compreender cada tópico.

Eis um exemplo de instrução:

Atua como o meu avaliador do «ponto de partida» em IA/LLM.

Faz-me até 12 perguntas (uma combinação de perguntas fáceis e técnicas) para avaliar:

• o meu à-vontade técnico geral (programação, dados, APIs)
• a minha compreensão do funcionamento dos LLM (modalidades de modelos, como CLI e interfaces gráficas, bem como tokens, contexto, alucinações, etc.)
• a minha familiaridade com padrões modernos de aplicações de LLM (RAG/incorporações, agentes/utilização de ferramentas)
• a minha capacidade para avaliar a qualidade (avaliações, verificação)
• o meu conhecimento dos riscos (privacidade, injeção de instruções, etc.)
• o meu conhecimento das limitações da IA (bons e maus casos de utilização para LLM, exatidão, natureza incontrolável dos resultados dos LLM, etc.)

Depois de eu responder, apresenta APENAS:

• 5–10 tópicos do YouTube com maior impacto que eu deva aprender a seguir, ordenados por prioridade. Cada item deve ser uma expressão de pesquisa no YouTube (não uma frase) + uma explicação de 5–10 palavras sobre a sua importância.

Começa já com as tuas perguntas.

Que competências de IA devem os gestores de produto aprender primeiro

Na minha opinião, é importante compreender onde e como pode utilizar LLM. Com isto, refiro-me a compreender que estes podem estar numa aplicação, no terminal do seu computador ou em código a operar numa automatização através de MCP ou APIs.

Em segundo lugar, tem mesmo de compreender que eles são:

1. Não determinísticos, incontroláveis e propensos a cometer erros
2. Nunca devem ser usados como fonte fiável de informação exata, especialmente em decisões críticas
3. Passíveis de ser automatizados de forma criativa para reduzir os efeitos dos dois pontos anteriores, dependendo do seu caso de utilização

O exemplo clássico que dou é nunca utilizar um LLM para escrever um ensaio inteiro por si, mas não há qualquer problema em pedir-lhe que apresente algumas ideias de caminhos a seguir se estiver bloqueado e não souber o que escrever a seguir. Por outras palavras, os LLM são excelentes complementos para a mente humana, mas é perigoso enveredar pelo caminho de tentar fazê-los pensar em tudo em vez da mente humana.

A última coisa que mencionarei aqui é que, enquanto aprende os conceitos acima, tem de tentar aplicar essas coisas por si próprio. Se estiver, por exemplo, a aprender como funciona a engenharia de instruções, deve fazer a mesma pergunta a um LLM, formulada de duas maneiras diferentes, para ver a diferença no resultado. Nunca aprenda sem praticar simultaneamente aquilo que está a aprender.

Porque não deve automatizar as interações de elevado valor com os clientes através de IA

Depois de aprender o que precisa de saber, pode fazer praticamente tudo. Mas isso não significa que deva fazê-lo.

Para uma empresa em fase inicial com um produto premium, a interação com os clientes e as vendas «parecem» ser as áreas mais propícias à IA e à automatização. Mas, na prática, descobri que o contacto humano é absolutamente necessário. Pessoalmente, considero que a interação com os utilizadores ou potenciais clientes acrescenta muito valor para ambas as partes e nem sequer quero tentar automatizá-la.

Enquanto PM, estaria a prestar um mau serviço a si próprio se se afastasse, fosse de que forma fosse, do contacto com os utilizadores. Quanto mais falar pessoalmente com eles, usando a sua própria voz, mais informação obtém e mais confiança inspira.

Porque é difícil — mas possível — os gestores de produto contribuírem para o código

Por isso, sou cauteloso relativamente àquilo para que uso a IA, mas uso-a bastante.

Por exemplo, imediatamente antes de uma versão ser lançada em produção, há sempre uma verdadeira azáfama de correcção de erros. Normalmente, numa empresa de maior dimensão, seriam os engenheiros e a equipa de QA a tratar destes retoques finais. Naturalmente, a pessoa sénior responsável pelo produto estaria a par, mas também estaria a planear os passos seguintes e as estratégias para monitorizar essa versão, a recolher feedback dos utilizadores, a preparar vários ciclos de avanço ou a recolher métricas depois de a funcionalidade ou o produto ser lançado.

Como estou actualmente numa empresa mais pequena, algo que mudou completamente o jogo para mim foi a possibilidade de ajudar a eliminar erros juntamente com os engenheiros, e só consegui fazê-lo através da utilização de AI/LLMs.

Sempre estive envolvido em QA de produtos e funcionalidades ao longo da minha carreira, mas raramente tive a possibilidade de entrar no terreno e corrigir um erro que envolvesse alterações de código em toda a stack.

Os profissionais experientes de tecnologia compreenderão que os engenheiros são muito rigorosos relativamente às suas bases de código e aos padrões de programação. Assim, mesmo que saiba tecnicamente como corrigir um determinado erro, também precisa de conhecer o contexto dos padrões de programação e das personalidades da equipa de engenharia, bem como de compreender os engenheiros que trabalharam em cada parte do código. Por isso, corrigir alguns erros está vários níveis afastado de ser fácil, mesmo quando sabe como fazê-lo, e a maioria dos engenheiros desdenharia o seu pedido de integração para essa correcção.

Graças à IA, contudo, consegui não só contribuir directamente para o código, enviando alterações para main, como também resolver os factores culturais secundários envolvidos.

Como criar um agente de IA que possa contribuir em segurança para a sua base de código

A minha abordagem inicial consistiu em criar um documento Markdown com os padrões de programação, fazendo com que um enxame de agentes no Claude Code explorasse todo o repositório dos seis meses anteriores e assimilasse o estilo de programação, o ficheiro Claude.md do repositório e, sobretudo, todos os comentários sobre diffs do GitHub, resoluções de conflitos, commits e edições feitas em PRs.

A partir daí, passei a ter um documento bastante sólido sobre os padrões de programação, que ampliei transformando-o num conjunto de competências e comandos no Claude Code. Estes analisariam qualquer código que eu gerasse para corrigir um erro e ajustá-lo-iam aos padrões de programação que a equipa já tinha implementado na base de código. Depois, criei outro subagente que utilizaria ganchos com o GitHub e que eu também poderia activar manualmente para analisar o código que tinha escrito, bem como os comentários ou correcções, e depois assimilar tudo isso numa adição ao documento de padrões de programação.

Por fim, após apenas alguns PRs, o código que eu gerava para uma determinada correcção podia ser facilmente convertido no tipo de código que gostamos de ver na base de código através de um simples documento Markdown que era, essencialmente, um guia de estilo de programação continuamente melhorado e autodidacta, accionado por várias tarefas cron e automações com o Claude Code.

O agente é agora tão bom que consigo integrar directamente na main.

Como as pequenas equipas de produto podem aumentar a agilidade

Este é um bom exemplo de como vou além do papel tradicional de PM. Mas ir além dos papéis tradicionais exige bons processos.

Temos uma lista de pendências bem organizada e etiquetada no Linear, e realizamos reuniões obrigatórias às segundas, quartas e sextas-feiras de manhã. Nos dias sem reunião de sincronização, mantemo-nos actualizados através de uma verificação diária no Slack. Todas as outras questões de priorização e discussão acontecem em tempo real através do Slack.

Esta pode não ser a melhor solução para empresas de maior dimensão, mas ficaria surpreendido com a eficácia com que funciona neste caso de utilização e com a agilidade que nos permite manter. Antes utilizava o Google Drive, folhas de cálculo, documentos, apresentações e um milhão de outras aplicações. Agora, enquanto equipa pequena, conseguimos trabalhar com o GSuite, o Slack, o Linear e o GitHub.

Métodos de PM leves são importantes neste espaço de AI/LLM em constante evolução. Pode acontecer qualquer coisa em qualquer dia da semana, seja feedback dos utilizadores ou lançamentos de potenciais concorrentes, e teremos de acompanhar tudo e definir prioridades rapidamente.

Como a IA está a obrigar as equipas de produto a repensar os rituais

No que diz respeito aos rituais, a maior mudança de perspectiva é que agora se trata verdadeiramente de um ritual circular e interminável, em vez de algo composto por documentos estagnados que temos continuamente de criar e consultar.

O âmbito começa como uma tarefa concisa no Linear, com diferentes níveis de detalhe, e depois uso a IA para o testar relativamente a ambiguidades, casos-limite e opções de sequenciação, aperfeiçoando-o até poder ser lançado na menor parcela possível.

Para nós, enquanto pequena equipa remota, o alinhamento é sobretudo assíncrono — uma breve conversa no Slack que termina numa decisão clara e nas acções seguintes, com reuniões diárias leves geridas pelo Geekbot. No entanto, continua a existir um enorme valor em três ou quatro reuniões de equipa por semana para trocarmos ideias em conjunto e reforçarmos o espírito de equipa.

É na validação que me tornei mais rigoroso, e não menos. Os LLMs geram normalmente lixo convincente se não soubermos utilizá-los correctamente, por isso cada alteração a uma funcionalidade ou aplicação recebe um pequeno sistema de avaliação — dados de entrada realistas, resultados esperados e casos adversariais — que a IA pode ajudar a preparar, mas que eu seleccionarei e testarei.

A execução resume-se então ao Linear + Claude Code + análise do Posthog alojada por nós. Lançar, observar, ajustar e manter o ciclo rápido, porque o mercado tecnológico está a mudar a um ritmo que, hoje em dia, parece ser de hora a hora.

Porque é melhor ter uma pilha de ferramentas minimalista e orientada para a IA

Por isso, esta é a minha pilha básica de gestão de projetos:

• GSuite
• Slack
• O bot Geekbot do Slack (para reuniões diárias)
• Linear
• VSCode
• LLM baseado na linha de comandos (no nosso caso, Claude Code)

Porquê o Linear? Tem apenas o essencial. É suficientemente poderoso para responder a quase todas as exigências de que uma equipa de projeto possa necessitar, mas suficientemente simples para ser acessível. É o anti-JIRA. E, mais importante ainda, integra-se facilmente com o GitHub e o Slack, que são as ferramentas onde os engenheiros trabalham desde o início. É simples, leve e acrescenta o mínimo de atrito adicional para que os engenheiros acompanhem as tarefas ou as atualizem. Também é extremamente extensível, por isso pode fazer coisas interessantes, como ter o seu LLM na linha de comandos a tentar automaticamente corrigir um erro quando este é comunicado num pedido de alteração em rascunho — antes mesmo de um ser humano começar a analisá-lo.

Não é necessário mais nada. Qualquer tipo de trabalho que seja necessário fazer fora disto pode ser realizado com ferramentas de código aberto no terminal.

A ferramenta de IA favorita do Cole para a produtividade pessoal

A nível pessoal, fora do trabalho em equipa, sou absolutamente obcecado pelo Raycast para produtividade. É a aplicação definitiva de acesso rápido, totalmente personalizável e ultraleve, que substitui a terrível aplicação "Spotlight" do Mac ou a tecla "Windows" no Windows. Reduzirá em 75% a utilização do rato na maioria das tarefas. Pode integrar praticamente qualquer aplicação através das integrações existentes ou criar facilmente as suas próprias — basta pedir ao Claude Code que crie uma extensão por si!

Se quiser colocar na minha área de transferência o texto de uma imagem que estou a ver, carrego nos botões de atalho do Raycast, escrevo "OCR" e carrego em Enter. Isso aciona a ferramenta de captura de ecrã OCR do cleanshotX e fico com o texto de qualquer imagem em menos de cinco segundos. Da mesma forma, posso utilizar o atalho, escrever "Ask Spotify" e, em seguida, escrever uma frase em linguagem natural, como "dá-me música boa para programar, com muita energia", que interpreta a minha frase através de um LLM, pesquisa etiquetas e propriedades musicais na API do Spotify e inicia imediatamente, no Spotify, uma lista de reprodução com o tipo de música que acabei de pedir.

Os casos de utilização são intermináveis. Basta descarregar a aplicação, ativar a IA através das suas próprias chaves de API ou da subscrição do serviço e percorrer as principais extensões no respetivo site para encontrar coisas que possam ser úteis para si. Uma verdadeira mudança de paradigma.

Porque é que a gestão de produto e a engenharia estão a começar a sobrepor-se

Em breve, a maioria dos engenheiros de funcionalidades será obrigada a começar a pensar e a tomar decisões como gestores de produto, e os gestores de produto terão de aprender o suficiente sobre aprendizagem automática, redes neuronais, LLMs e várias arquiteturas para se aproximarem tanto quanto possível de um engenheiro que utiliza LLMs, sem o serem realmente. Esta transformação reflete abordagens arrojadas à integração da IA que estão a reformular os papéis tradicionais.

Obviamente, existem muitas ressalvas e áreas às quais isto não se aplica, mas, em geral, o diagrama de Venn de todos os papéis anteriores numa empresa, das vendas ao marketing, passando pelo produto e pela engenharia, irá inevitavelmente aproximar-se, e muito poucas competências serão exclusivas de uma função específica.

Como evitar a inevitável crise existencial à medida que a IA transforma o trabalho de produto

Eis o meu conselho: tente evitar a inevitável crise existencial que poderá sentir à medida que esta era tecnológica continua a evoluir.

Em vez disso, concentre-se nas competências mentais que desenvolveu através da experiência. Os LLMs conseguem gerar conteúdo, mas são realmente péssimos a ter bom gosto.

Atualmente, as respostas existem em abundância, por isso, fazer perguntas únicas e específicas da experiência à IA é agora uma competência. Além disso, descobrir na sua própria mente qual é a pergunta certa a fazer constitui o verdadeiro trabalho intelectual.

Acompanhe o trabalho

Pode acompanhar o Cole no X e no seu site pessoal, enquanto continua a desafiar os limites do que é possível para os gestores de produto. E não deixe de consultar o Probably.dev!

Em breve, haverá mais entrevistas com especialistas no The Digital Project Manager!