IA no fluxo de trabalho do gerente de produto: onde ajuda, onde quebra

Toda ferramenta de PM agora tem um botão de "IA". O Notion AI rascunha seu PRD. O Linear resume seu sprint. O Productboard extrai temas do feedback. O Jira escreve critérios de aceitação. O botão está em todo lugar, e a maior parte do que sai dele é lixo. Specs lixo que os engenheiros param de ler na terceira semana. Resumos de pesquisa lixo que achatam aquela única citação estranha que era, na verdade, o insight. Priorização lixo que ranqueia com confiança funcionalidades que ninguém pediu.

O PM que copia e cola o rascunho de PRD do Notion AI no Jira é o PM cujo time de engenharia silenciosamente para de ler PRDs. Vi isso acontecer em três times no último ano. O padrão é idêntico: o PM fica mais rápido, o time de engenharia fica mais quieto, e seis semanas depois alguém entrega a coisa errada porque a spec foi escrita por um modelo que nunca conheceu um cliente.

Então este é o enquadramento honesto. A IA é uma ferramenta de alavancagem para o meio chato do seu fluxo de trabalho. Ela não substitui as duas coisas pelas quais você é de fato pago para fazer: julgamento e verdade do cliente. O resto deste artigo é a visão de um PM em atividade sobre onde a IA vale o investimento, onde ela definitivamente não vale, os padrões de fluxo de trabalho que se sustentam sob pressão, e um plano de 30 dias para desenvolver a habilidade.

Onde a IA ajuda (use diariamente)

O meio chato é real. São os 60% do trabalho de PM que são síntese mecânica, rascunho, varredura e verificação de padrões. A IA é ótima nisso quando você a mantém na coleira curta.

Síntese de transcrições de entrevistas. Este é o lugar de maior ROI para começar. Pegue uma transcrição do Gong ou do Grain, cole o texto completo no Claude (não um resumo, o texto completo) e peça citações literais agrupadas por um tema específico. A estrutura de prompt que funciona: "Extraia citações literais sobre objeções de preço desta transcrição. Agrupe por persona se houver vários interlocutores. Não parafraseie. Se um interlocutor titubear, inclua a hesitação." Essa última frase importa porque os modelos tendem a resumos confiantes e você perde a textura.

Rascunhos de spec. Primeiro rascunho de user stories, casos extremos, critérios de aceitação, a partir de um briefing estruturado que você mesmo escreveu. O briefing é o trabalho. O rascunho é só digitação. Se você alimentá-lo com sua declaração de problema, suas suposições de modelo de dados e seus três casos extremos conhecidos, ele vai cuspir um esqueleto utilizável. Você ainda vai reescrever metade dele. Tudo bem. Você economizou a metade que não reescreveu.

Varreduras competitivas. Jogue oito changelogs de concorrentes num modelo, peça um diff contra seu roadmap. Pergunte qual dos lançamentos deles atinge um segmento de cliente que você também atende. Isso é trabalho braçal que costumava consumir metade de uma sexta-feira. Agora consome 20 minutos e você gasta o resto do tempo decidindo o que fazer a respeito, que é o trabalho de verdade.

Cópia de variantes para porta falsa. Gerar seis manchetes de landing page para um A/B test? Tudo bem. Gerar a estratégia por trás de qual porta falsa rodar? Não está bem. O modelo é bom na superfície, ruim na escolha. Use-o para a superfície.

Verificação de sanidade de análise de coorte. Cole uma tabela de resultado de SQL, pergunte "o que está faltando aqui, o que um cientista de dados cético contestaria?" Você não está pedindo análise. Está pedindo um segundo par de olhos sobre se sua coorte está contaminada, sua janela de tempo está estranha ou seu filtro está excluindo a população que importa. Ele pega coisas bobas. Isso vale a pena.

Onde a IA quebra (faça você mesmo, toda vez)

Esta é a parte que a maioria dos artigos de "IA para PMs" pula porque ela não vende ferramentas. Mas esta é a parte que determina se você mantém seu emprego daqui a dois anos.

Enquadramento do problema. A única frase que diz "o que estamos de fato resolvendo e para quem" é o seu trabalho. Sempre. Um modelo vai produzir um enquadramento de som fluente que soa como todos os outros enquadramentos que ele já leu. O seu precisa ser específico para seus clientes, seus dados, seu momento no mercado. Se o seu enquadramento parece que poderia se aplicar a qualquer empresa da sua categoria, você terceirizou a frase mais importante da spec.

Pesos de priorização. Números de RICE e ICE de um LLM são achismo. O número de alcance vem de uma conversa real com marketing sobre qual segmento eles vão mirar no próximo trimestre. O número de esforço vem de uma conversa de 10 minutos com seu tech lead. O número de confiança vem de com quantos clientes você de fato conversou sobre isso. Nenhum desses números existe nos dados de treinamento de um modelo para o seu roadmap específico. Se você deixar a IA gerar as pontuações, você automatizou a parte menos valiosa da priorização (a matemática) e pulou a parte mais valiosa (as conversas de trade-off que produziram os insumos).

Verdade do cliente. Nunca deixe a IA resumir 12 entrevistas em 3 temas sem que você leia as transcrições brutas. Os modelos comprimem em direção à mediana. O insight de verdade quase sempre é o outlier: o único cliente que disse algo que ninguém mais disse, de um jeito que reenquadrou sua suposição. A compressão mata os outliers. Leia as transcrições. Use a IA para extrair citações, não para extrair conclusões.

Decisões de julgamento sobre cortes de escopo. Um modelo pode listar todas as opções para cortar escopo antes de um prazo. Ele não consegue conduzir a sala quando a engenharia está cansada, o design está na defensiva e o GM quer o compromisso original. Isso não é um problema de prompt. É um problema de "você precisa estar de fato ali".

Padrões de fluxo de trabalho que realmente funcionam

Alguns padrões que rodo semanalmente. Nenhum deles é engenhoso. O ponto é que são chatos e repetíveis.

Gong/Grain mais Claude para síntese de entrevistas. O padrão exato: grave a chamada (Gong se for uma call de descoberta atrelada a vendas, Grain se for pesquisa pura). Pegue a transcrição completa. Cole numa conversa nova do Claude. Use um prompt de extração apertado, não um prompt de resumo. Verifique lendo a transcrição original para as duas ou três principais citações que o modelo trouxe à tona. Se o modelo parafraseou qualquer coisa relevante, jogue o resultado fora e refaça o prompt com linguagem mais rígida. A etapa de verificação é o trabalho. Pule-a e você vai citar um cliente dizendo algo que ele não disse, o que é uma jogada que encerra carreira numa apresentação para stakeholders.

Um prompt que vale o investimento, na íntegra:

Você está extraindo citações de uma transcrição de entrevista com cliente. Vou colar a transcrição abaixo. Sua tarefa: puxe toda citação direta em que o interlocutor menciona preço, orçamento ou aquisição. Não parafraseie. Não resuma. Preserve exatamente as hesitações, vícios de linguagem e contradições do interlocutor. Retorne como uma lista com marcadores, com timestamp se disponível. Se não houver citações relevantes, diga "nenhuma citação encontrada", e não invente.

A linha "não invente" importa. Sem ela, os modelos alucinam citações que soam plausíveis.

Cursor como acelerador de spec. Útil apenas quando seu time de engenharia também o usa. O Cursor (ou qualquer ferramenta de programação em par com IA que o time adotou) significa que os engenheiros estão lendo sua spec enquanto rascunham o código no mesmo editor. Se eles estão usando e você não, sua spec se distancia de como o código de fato é escrito. Se nenhum de vocês usa, tudo bem, escreva specs do jeito antigo. A armadilha é o PM usar sozinho e supor que o time de engenharia vivencia a spec do mesmo jeito que você. Pergunte. Acompanhe o fluxo de trabalho deles.

A armadilha do "PRD escrito por IA". Os engenheiros identificam um PRD falso instantaneamente. Os sinais: casos extremos genéricos ("lidar com falhas de rede de forma elegante"), critérios de aceitação que soam certos mas erram o modelo de dados real ("o usuário pode salvar suas preferências") e uma ausência suspeita das especificidades bagunçadas que vêm de de fato usar o produto. O teste de cheiro: se você não consegue defender cada linha da spec na standup, apague-a antes da standup.

Uma checklist de teste de cheiro de PRD que vale rodar antes de você entregar o documento:

Consigo nomear o cliente que pediu isso, e citá-lo?
Consigo desenhar o modelo de dados num quadro branco sem anotações?
Meus casos extremos referenciam nossos estados de erro reais, e não genéricos?
Listei pelo menos uma coisa que explicitamente não vamos construir, e por quê?
Meu tech lead leria esta spec e aprenderia algo que já não sabia?

Se qualquer resposta for não, a spec está fina demais. A IA não te ajudou. Ela te ajudou a entregar um rascunho que você não consegue defender.

A lente do ACE Framework (opcional)

Se você ler decks de estratégia suficientes, vai esbarrar no ACE Framework: Ingest, Analyze, Predict, Generate, Execute. Os PMs ficam mais próximos de Analyze e Generate (síntese e rascunho). É exatamente onde mora a alavancagem deste artigo. Ingest (encanamento de dados, ETL, pipelines de embedding) costuma pertencer à engenharia de dados. Execute (a automação de workflow que roda sem um humano no circuito) costuma pertencer a ops ou à plataforma.

Você não precisa decorar isso. Mas vale conhecer o vocabulário porque, no momento em que funcionalidades de IA caírem no seu roadmap, seus líderes de engenharia e seu time de dados vão usar essas palavras. Você economiza uma reunião se já souber qual capacidade está comprando versus construindo.

Seu plano de 30 dias para desenvolver a habilidade

Quatro semanas. Um fluxo de trabalho de cada vez. Sem proliferação de ferramentas. O objetivo é construir um pequeno conjunto de movimentos repetíveis em que você confie sob pressão de prazo.

Semana 1: escolha um fluxo de trabalho e rode-o duas vezes. A síntese de transcrições é o lugar de maior ROI para começar. Escolha uma entrevista com cliente desta semana. Sintetize-a manualmente primeiro. Leia a transcrição, anote as três coisas que te surpreenderam, liste as citações literais que as sustentam. Depois rode a mesma transcrição pelo Claude com um prompt de extração. Compare. Você vai aprender duas coisas: onde o modelo agrega velocidade, e o que ele silenciosamente descarta. Ambos importam.

Semana 2: escreva sua própria biblioteca de prompts. Quatro a seis prompts, versionados num documento compartilhado. Um para extração de transcrições. Um para esqueleto de spec a partir de um briefing. Um para varredura competitiva. Um para verificação de sanidade de SQL. Talvez um para variantes de cópia de porta falsa. É isso. Se você tiver mais de seis prompts, está colecionando ferramentas em vez de usá-las. Cada prompt deve ter um formato de entrada claro, um formato de saída claro e uma nota de uma linha sobre o que verificar antes de confiar no resultado.

Semana 3: mostre a um colega. Entregue seus prompts a outro PM ou ao seu tech lead. Peça que usem um numa tarefa real. Se eles não conseguem replicar seu resultado sem você ficar por perto, o prompt está frágil demais. Prompts frágeis são um ponto único de falha. No dia em que você ficar doente, seu fluxo de trabalho para. Aperte o prompt até ele ser transferível.

Semana 4: auditoria. Duas colunas. Coluna esquerda: o que a IA te economizou neste mês (horas, decisões aceleradas, rascunhos que você não precisou digitar). Coluna direita: o que ela te custou em confiança com a engenharia, com os clientes, com o seu próprio julgamento. Seja honesto. Se um prompt produziu uma spec que a engenharia contestou, anote. Se uma síntese perdeu um outlier que você pegou depois, anote. Corte o que não conquistou seu lugar. Mantenha o que conquistou. Agora você tem um fluxo de trabalho, não um achismo.

Tentei uma versão disso num ciclo de descoberta no trimestre passado. Na semana 1, eu estava desconfiado. Na semana 3, eu havia cortado meu tempo de síntese de entrevistas mais ou menos pela metade, mas me peguei quase entregando um resumo de tema que eu não tinha verificado contra as transcrições brutas. Na auditoria da semana 4, o prompt de síntese ficou. O prompt de "resumir 12 entrevistas em temas" foi apagado. É essa a habilidade.

O argumento de encerramento silencioso

Os PMs que vão vencer nos próximos dois anos não são os que usam mais IA. Não são os que têm a stack de ferramentas mais longa ou a biblioteca de prompts mais favoritada no Notion. São os que sabem exatamente onde a IA para de funcionar e protegem essas partes do trabalho. Enquadramento do problema. Pesos de priorização. Verdade do cliente. Decisões de julgamento sob pressão de prazo.

Todo o resto é território livre. Use as ferramentas. Economize o tempo. Mas gaste o tempo que você economiza nas partes do trabalho que um modelo não consegue fazer: sentar com um cliente até você de fato entender o que ele está dizendo, lutar pelo corte de escopo certo na sala, escrever a única frase no topo da spec que torna coerentes as próximas 12 semanas do time.

É esse o trabalho. A IA é uma alavanca, não um substituto.

Playbooks para Product Manager