Introduction

The AI-powered "second brain" is everywhere right now. The idea: you feed your sources to an AI, it generates dozens of atomic notes (one idea per note), then links them together to create a connected, meaningful knowledge network.

On paper, it's appealing. In practice, for managing opportunities in product management, I think it's the wrong approach.

The world is complex

To understand why, we first need to picture what a network of atomic notes actually looks like on a real subject.

Here is a small portion of my notes on Pierre Bourdieu, from my sociology studies:

When you start comparing him with another sociologist — here Niklas Luhmann, the father of the Zettelkasten — the complexity explodes:

And even when you try to simplify things down to broad concepts, the connections remain dense. Implications, antagonisms, weak links, indirect relationships... Everything is connected, but not in the same way.

The world is complex. And product management is no exception.

Why it doesn't work for product management

I'm opposed to this approach for two reasons.

Error propagation is uncontrollable

When you work with an AI, you always need to be able to verify what it produces. In a network of notes where everything is linked, an error in a single note can propagate silently across the connections. You can end up defending an opportunity based on false information without even knowing it.

With a limited set of files — 30, 40 files in a directory dedicated to one opportunity — you have the human capacity to verify, to audit. In a graph of hundreds of interconnected notes, that's an illusion.

The context window explodes

The other problem is technical. When you study an opportunity, you need the AI to stay focused: the mission file, the established facts, the next steps to validate. That's a light, controlled context.

Now confront that same AI with a borderless network of notes: it will wander from connection to connection, inflate its context window, hunt for the "right" information in an ocean of links. Too much information kills information.

A network of notes doesn't manage itself

And there's an even deeper problem. A network of interlinked notes doesn't maintain itself by magic. As soon as the volume grows, new questions emerge:

• Inconsistencies: two notes contradict each other. Which one holds? Without an explicit mechanism for tracking contradictions, the AI (and you) will build on unstable foundations.
• Gaps: an entire area of the subject is undocumented. But how would you know that in a graph of hundreds of notes? An invisible hole is more dangerous than an identified one.
• Decisions: you settled on one of two options three weeks ago. Where is that written down? Is the decision still valid? Who made it?

A flat file or a network of notes doesn't answer these questions. You need a dedicated memory structure — with files that explicitly track contradictions, the state of completeness, decisions and their justifications.

I detailed this approach in an earlier article: From the single file to a system of contexts — why an LLM's memory doesn't fit in one document. The principle: each mission has its own structured space — mission, current state, sources, notes, accumulated memory, deliverables — with explicit mechanisms to handle what a network of notes leaves in the blind spot.

Yet when you decide to study an opportunity, you're making a bet on a theme, a feature, an impact. You deliberately narrow the scope. The note system should reflect that narrowing, not fight it.

The alternative: the bounded context

That's why I prefer an approach where each opportunity lives in its own bounded space, with its own files. If I need information coming from another domain, I don't create a link back to the original source — I copy that information and adapt it to the context of my opportunity.

This approach takes up exactly the concept of the bounded context from Domain-Driven Design.

Let's take a concrete example. A payroll system needs to know the leave taken by employees this month. Rather than creating a direct link to the leave-management system, you integrate that data into the "payroll variables" domain. You end up with leave that is consistent with the payroll domain, instead of trying to force a concept, along with all its original context, into another domain.

For product management, it's the same logic. Each opportunity has its own context, its own files, its own local truth. Outside information is imported and adapted, not dynamically linked.

Staying close to — even modeled on — development methods avoids layers of abstraction between dev and product. You stop bending concepts every time you move from one context to another.

Conclusion

The centralized second brain, with no boundaries between opportunities, isn't suited to product management. The complexity it exposes is real, but the answer isn't to connect everything — it's to draw boundaries intelligently.

Dedicated, auditable spaces where the AI works on a controlled perimeter: that's what lets you keep control over what you build and what you defend.

For which domains does the second brain actually work well? I'll cover that in a future article.

Pour en savoir plus

From the Single File to a System of Contexts: Why an LLM's Memory Won't Fit in One Document The Tools of Organizational Coherence The PM as Architect of Context What Is an Atomic Note?

Sources

• Zettelkasten method: https://en.wikipedia.org/wiki/Zettelkasten
• Domain-Driven Design — Bounded Context: https://martinfowler.com/bliki/BoundedContext.html
• From the single file to a system of contexts: 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