Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Introducción
El "segundo cerebro" potenciado con IA está por todas partes en este momento. El principio: das tus fuentes a una IA, genera decenas de notas atómicas (una idea por nota) y luego las enlaza entre sí para crear una red de conocimiento conectada, llena de sentido.
Sobre el papel, es atractivo. En la práctica, para la gestión de oportunidades en product management, creo que es un mal enfoque.
El mundo es complejo
Para entender por qué, hay que visualizar primero qué aspecto tiene una red de notas atómicas sobre un tema real.
Aquí tienes una pequeña parte de mis notas sobre Pierre Bourdieu, procedentes de mis estudios de sociología:
Cuando empezamos a comparar con otro sociólogo —aquí Niklas Luhmann, el padre del Zettelkasten—, la complejidad se dispara:
E incluso intentando simplificar por grandes conceptos, los vínculos siguen siendo densos. Implicaciones, antagonismos, vínculos débiles, relaciones indirectas... Todo está conectado, pero no de la misma manera.
El mundo es complejo. Y el product management no es una excepción.
Por qué no funciona para el product management
Me opongo a este enfoque por dos razones.
La propagación de errores es incontrolable
Cuando se trabaja con una IA, siempre hay que poder verificar lo que produce. En una red de notas donde todo está enlazado, un error en una sola nota puede propagarse silenciosamente a través de las conexiones. Puedes acabar defendiendo una oportunidad basada en información falsa sin ni siquiera saberlo.
Con un conjunto limitado de archivos —30, 40 archivos en un directorio dedicado a una oportunidad— tienes la capacidad humana de verificar, de auditar. En un grafo de cientos de notas interconectadas, eso es una ilusión.
La ventana de contexto explota
El otro problema es técnico. Cuando estudias una oportunidad, necesitas que la IA se mantenga concentrada: el archivo de misión, los hechos confirmados, los próximos pasos a validar. Es un contexto ligero y manejable.
Enfrenta a esa misma IA a una red de notas sin fronteras: saltará de conexión en conexión, hará crecer su ventana de contexto, buscará la "buena" información en un océano de vínculos. Demasiada información mata la información.
Una red de notas no se gestiona sola
Y hay un problema aún más profundo. Una red de notas enlazadas entre sí no se mantiene por arte de magia. En cuanto el volumen crece, aparecen nuevas preguntas:
- Las incoherencias: dos notas se contradicen. ¿Cuál prevalece? Sin un mecanismo explícito para rastrear las contradicciones, la IA (y tú) vais a construir sobre cimientos inestables.
- Los vacíos: toda una zona del tema no está documentada. ¿Pero cómo saberlo en un grafo de cientos de notas? Un hueco invisible es más peligroso que uno identificado.
- Las decisiones: elegiste entre dos opciones hace tres semanas. ¿Dónde está anotado? ¿Sigue siendo válida la decisión? ¿Quién la tomó?
Un archivo plano o una red de notas no responden a estas preguntas. Se necesita una estructura de memoria dedicada —con archivos que rastreen explícitamente las contradicciones, el estado de completitud, las decisiones y sus justificaciones.
He detallado este enfoque en un artículo anterior: Del archivo único al sistema de contextos — por qué la memoria de un LLM no cabe en un solo documento. El principio: cada misión tiene su propio espacio estructurado —misión, estado actual, fuentes, notas, memoria acumulada, entregables— con mecanismos explícitos para gestionar lo que la red de notas deja en el ángulo muerto.
Ahora bien, cuando decidimos estudiar una oportunidad, hacemos una apuesta sobre una temática, una feature, un impacto. Reducimos el scope voluntariamente. El sistema de notas debería reflejar esa reducción, no combatirla.
La alternativa: el bounded context
Por eso prefiero un enfoque donde cada oportunidad vive en su propio espacio acotado, con sus propios archivos. Si necesito información proveniente de otro dominio, no creo un enlace hacia la fuente original —copio y adapto esa información al contexto de mi oportunidad.
Este enfoque retoma exactamente el concepto de bounded context del Domain-Driven Design.
Tomemos un ejemplo concreto. Un sistema de nóminas necesita conocer los días de vacaciones tomados por los empleados ese mes. En lugar de crear un enlace directo hacia el sistema de gestión de vacaciones, se integran esos datos en el dominio "variables de nómina". Se obtienen así unas vacaciones coherentes con el dominio de la nómina, en lugar de intentar meter un concepto con todo su contexto de origen en otro dominio.
Para el product management, la lógica es la misma. Cada oportunidad tiene su propio contexto, sus propios archivos, su propia verdad local. La información externa se importa y adapta, no se enlaza dinámicamente.
Estar próximo —o incluso calcado— a los métodos de desarrollo evita las capas de abstracción entre dev y product. Ya no se tuercen los conceptos en cada paso de un contexto a otro.
Conclusión
El segundo cerebro centralizado, sin fronteras entre las oportunidades, no es adecuado para el product management. La complejidad que expone es real, pero la respuesta no es conectar todo —es acotar de forma inteligente.
Espacios dedicados, auditables, donde la IA trabaja sobre un perímetro manejable: eso es lo que permite mantener el control sobre lo que construimos y lo que defendemos.
¿Para qué dominios funciona realmente bien el segundo cerebro? Lo trataré en un próximo artículo.
Para saber más
Del archivo único al sistema de contextos: por qué la memoria de un LLM no cabe en un solo documento Las herramientas de coherencia organizacional El PM como arquitecto del Contexto ¿Qué es una nota atómica?
Fuentes
- Método Zettelkasten: https://en.wikipedia.org/wiki/Zettelkasten
- Domain-Driven Design — Bounded Context: https://martinfowler.com/bliki/BoundedContext.html
- Del archivo único al 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