# Por que o PM precisa aprender a usar IA

> Leitura complementar ao módulo **M0** do SpecContext PM.  
> A apresentação resume; este texto aprofunda e cita **fontes externas** de autores e organizações gabaritadas.

## 1. O problema não é “falta de ferramenta”
A maior transformação em Product Management **não** é simplesmente usar IA para escrever User Stories ou resumir reuniões. O diferencial é a **engenharia de contexto**: fornecer à IA o conhecimento necessário para raciocinar como um PM experiente — enquanto o PM permanece dono da decisão.

A maioria dos PMs e POs já experimentou ChatGPT, Copilot ou similares. O padrão típico:

1. Cola um pedido vago (“escreve user stories do onboarding” / “Crie uma User Story”)
2. Recebe texto genérico e confiante
3. Gasta tempo reescrevendo — ou, pior, leva o texto genérico ao refining

Isso não prova que “IA não serve para produto”. Prova que **a entrada estava pobre**. Em sistemas de IA generativa, a qualidade da saída acompanha a qualidade do que o modelo **vê** no momento da resposta — não só a frase do pedido.

Um PM moderno tende a evoluir de papel operacional para **orquestrador de inteligência**: usa IA para ampliar capacidade analítica, estratégica e operacional — sem abdicar do julgamento.

A Anthropic formula isso de modo direto: o desafio deixa de ser só “o prompt perfeito” e passa a ser **curar o conjunto de tokens de alto sinal** que entra na janela de contexto ([Anthropic — Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)).

## 2. Por que isso importa especificamente para PM/PO
Marty Cagan (SVPG) argumenta que, com GenAI, o papel do PM **fica mais essencial e mais difícil**, não menos — tanto no produto que você constrói quanto na forma como você trabalha ([SVPG — AI Product Management 2 Years In](https://www.svpg.com/ai-product-management-2-years-in/)).

O trabalho do PM é, em grande parte, **empacotar entendimento**: stakeholders, evidências, trade-offs, critérios de sucesso, riscos. Isso é exatamente o tipo de material que uma IA precisa para ser útil — e que o time de engenharia precisa para entregar valor sem retrabalho.

| Ganho | Como a IA ajuda (se o contexto for bom) | Risco se o contexto for ruim |
|-------|------------------------------------------|------------------------------|
| Velocidade | Rascunhos de stories, AC, perguntas de entrevista | Inventa requisitos |
| Cobertura | Sugere cenários de erro e bordas esquecidas | Lista genérica sem evidência |
| Qualidade | Critica lacunas e aponta ambiguidades | “Melhora” a story inventando fatos |
| Alinhamento | Resume pacote para stakeholders | Distorce prioridade ou outcome |

Em outras palavras: a IA **amplifica** o método do PM. Se o método for “chute + Slack”, a IA escala o chute. Se o método for discovery + especificação clara, a IA escala clareza.

## 3. Prompt sozinho tem teto; contexto compõe
Enquanto a **engenharia de prompt** foca em “o que perguntar”, a **engenharia de contexto** foca em “como construir um ambiente de conhecimento para que a IA tome decisões de qualidade”.

**Prompt engineering** melhora *como* você pede (objetivo, contexto no texto, restrições, formato, critérios, exemplos). Continua essencial — e este curso ensina a estrutura. A documentação oficial da OpenAI cobre bem essa camada ([OpenAI — Prompt engineering](https://platform.openai.com/docs/guides/prompt-engineering)).

**Engenharia de contexto** melhora *o que* o modelo sabe antes e durante o pedido: brief, personas, restrições, exemplos bons, o que é fato vs hipótese, e o **repositório vivo** do produto. Redis resume: prompt é sobre instruir; context engineering é sobre **o que o modelo sabe quando responde** ([Redis](https://redis.io/en/blog/context-engineering-vs-prompt-engineering/)).

Exemplo frágil:
```text
Crie uma User Story.
```

Exemplo com engenharia de contexto (esqueleto):
```text
Você é um Product Manager sênior.
Contexto: [empresa, produto, persona, jornada, restrições, KPIs…]
Objetivo: criar User Stories do galho X.
Considere: LGPD, escalabilidade, auditoria, integrações existentes.
Retorne: Epic → Features → Stories → Acceptance Criteria.
Restrição: não invente APIs nem fatos fora do contexto; marque hipóteses.
```

Falhas típicas que o PM vê o tempo todo (vocabulário alinhado à prática de contexto descrita por Anthropic/Neo4j):

1. **Contexto velho** — colar PRD/exemplo antigo; o produto mudou  
2. **Contexto espalhado** — esquecer quotes de cliente, notas de design, restrições  
3. **Contexto diluído** — sessão longa ou dump enorme em que o sinal se perde (*context rot* — [Neo4j](https://neo4j.com/blog/genai/context-engineering-vs-prompt-engineering/))

Nenhuma dessas se resolve “escrevendo o prompt de outro jeito”.

## 4. Vantagem estrutural do PM
Guias de produto sobre context engineering (ex.: [Aakash Gupta](https://www.news.aakashg.com/p/context-engineering), citando a formulação popularizada por Andrej Karpathy) argumentam que o problema é de **priorização, arquitetura de conhecimento e qualidade** — músculos de PM — mais do que só pipeline de dados.

Tradução prática: você não precisa treinar o modelo. Precisa decidir:

- O que entra no pacote (e o que fica de fora)
- O que é evidência vs opinião
- Com que frescor os dados precisam estar
- Como o time valida a saída antes de virar backlog

## 5. O que este curso pede de você
Não é “virar engenheiro de ML”. É:

1. Parar de tratar IA como oráculo  
2. Dominar o mínimo de LLM (limites, alucinações, janela) — leitura `07`  
3. Tratar cada pedido como um **pacote de contexto** (não só prompt)  
4. Rotular fato / hipótese / invenção  
5. Usar a IA para **criticar e perguntar**, não só para redigir  
6. Manter um **contexto vivo** e aplicar o método no ciclo todo (mapa na leitura `08`)

Na próxima leitura: definição formal de engenharia de contexto e como difere de prompt engineering.

## Fontes usadas neste texto
1. Anthropic. *Effective context engineering for AI agents*. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents  
2. Marty Cagan. *AI Product Management 2 Years In* (SVPG). https://www.svpg.com/ai-product-management-2-years-in/  
3. OpenAI. *Prompt engineering*. https://platform.openai.com/docs/guides/prompt-engineering  
4. Redis. *Context engineering vs prompt engineering*. https://redis.io/en/blog/context-engineering-vs-prompt-engineering/  
5. Neo4j. *Why AI teams are moving from prompt engineering to context engineering*. https://neo4j.com/blog/genai/context-engineering-vs-prompt-engineering/  
6. Aakash Gupta. *The Ultimate Guide to Context Engineering for PMs*. https://www.news.aakashg.com/p/context-engineering