Introdução

O "segundo cérebro" turbinado por IA está em todo lugar neste momento. O princípio: você entrega suas fontes a uma IA, ela gera dezenas de notas atômicas (uma ideia por nota) e depois as conecta entre si para criar uma rede de conhecimento conectada, cheia de sentido.

No papel, é sedutor. Na prática, para a gestão de oportunidades em product management, eu acho que é uma abordagem ruim.

O mundo é complexo

Para entender por quê, primeiro precisamos visualizar o que uma rede de notas atômicas produz sobre um tema real.

Aqui aparece uma pequena parte das minhas notas em torno de Pierre Bourdieu, vindas dos meus estudos de sociologia:

Quando começamos a comparar com outro sociólogo — aqui Niklas Luhmann, o pai do Zettelkasten — a complexidade explode:

E mesmo tentando simplificar por grandes conceitos, as ligações continuam densas. Implicações, antagonismos, ligações fracas, relações indiretas... Tudo está conectado, mas não da mesma maneira.

O mundo é complexo. E o product management não escapa disso.

Por que isso não funciona para o product management

Eu sou contra essa abordagem por duas razões.

A propagação de erros é incontrolável

Quando trabalhamos com uma IA, precisamos sempre conseguir verificar o que ela produz. Numa rede de notas onde tudo está conectado, um erro em uma única nota pode se propagar em silêncio através das conexões. Você pode acabar defendendo uma oportunidade baseada em uma informação falsa, sem nem saber.

Com um conjunto limitado de arquivos — 30, 40 arquivos numa pasta dedicada a uma oportunidade — você tem a capacidade humana de verificar, de auditar. Num grafo de centenas de notas interconectadas, isso é ilusório.

A janela de contexto explode

O outro problema é técnico. Quando você estuda uma oportunidade, você precisa que a IA fique focada: o arquivo de missão, os fatos já estabelecidos, os próximos passos a validar. É um contexto leve e controlado.

Coloque essa mesma IA diante de uma rede de notas sem fronteiras: ela vai passear de conexão em conexão, inflar sua janela de contexto, procurar a informação "certa" num oceano de links. Informação demais mata a informação.

Uma rede de notas não se mantém sozinha

E há um problema ainda mais profundo. Uma rede de notas conectadas entre si não se mantém por mágica. Assim que o volume cresce, novas perguntas aparecem:

• As incoerências: duas notas se contradizem. Qual delas vale? Sem um mecanismo explícito de acompanhamento das contradições, a IA (e você) vão construir sobre bases instáveis.
• As lacunas: uma área inteira do tema não está documentada. Mas como saber disso num grafo de centenas de notas? Um buraco invisível é mais perigoso do que um buraco identificado.
• As decisões: você decidiu entre duas opções três semanas atrás. Onde isso está anotado? A decisão ainda vale? Quem a tomou?

Um arquivo plano ou uma rede de notas não respondem a essas perguntas. É preciso uma estrutura de memória dedicada — com arquivos que registrem explicitamente as contradições, o grau de completude, as decisões e suas justificativas.

Eu detalhei essa abordagem em um artigo anterior: Do arquivo único ao sistema de contextos — por que a memória de um LLM não cabe em um só documento. O princípio: cada missão tem seu próprio espaço estruturado — missão, estado atual, fontes, notas, memória acumulada, entregáveis — com mecanismos explícitos para lidar com o que a rede de notas deixa no ponto cego.

Ora, quando decidimos estudar uma oportunidade, fazemos uma aposta em um tema, uma feature, um impacto. Reduzimos o escopo de propósito. O sistema de notas deveria refletir essa redução, não combatê-la.

A alternativa: o bounded context

Por isso eu prefiro uma abordagem em que cada oportunidade vive no seu próprio espaço delimitado, com seus próprios arquivos. Se eu preciso de informações vindas de outro domínio, eu não crio uma ligação para a fonte original — eu copio e adapto essas informações ao contexto da minha oportunidade.

Essa abordagem retoma exatamente o conceito de bounded context do Domain-Driven Design.

Vamos a um exemplo concreto. Um sistema de folha de pagamento precisa saber quais férias os funcionários tiraram neste mês. Em vez de criar um link direto para o sistema de gestão de férias, integramos esses dados ao domínio "variáveis da folha de pagamento". Assim obtemos férias que são coerentes com o domínio da folha, em vez de tentar encaixar um conceito com todo o seu contexto de origem dentro de outro domínio.

Para o product management, a lógica é a mesma. Cada oportunidade tem seu contexto próprio, seus próprios arquivos, sua própria verdade local. As informações externas são importadas e adaptadas, não conectadas dinamicamente.

Estar próximo — ou até calcado — dos métodos de desenvolvimento evita as camadas de abstração entre dev e produto. Não torcemos mais os conceitos a cada passagem de um contexto para outro.

Conclusão

O segundo cérebro centralizado, sem fronteiras entre as oportunidades, não serve para o product management. A complexidade que ele expõe é real, mas a resposta não é conectar tudo — é delimitar de forma inteligente.

Espaços dedicados, auditáveis, onde a IA trabalha sobre um perímetro controlado: é isso que permite manter o controle sobre o que construímos e o que defendemos.

Para quais domínios o segundo cérebro funciona realmente bem? Vou falar disso em um próximo artigo.

Para saber mais

Do arquivo único ao sistema de contextos: por que a memória de um LLM não cabe em um só documento As ferramentas de coerência organizacional O PM como arquiteto do Contexto O que é uma nota atômica?

Fontes

• Método Zettelkasten: https://en.wikipedia.org/wiki/Zettelkasten
• Domain-Driven Design — Bounded Context: https://martinfowler.com/bliki/BoundedContext.html
• Do arquivo único ao sistema de contextos: https://malorean.net/articles/2026-04-21-du-fichier-unique-au-systeme-de-contextes-pourquoi-la-memoire-dun-llm-ne-tient-pas-dans-un-seul-document.html