Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Einleitung
Das KI-gestützte „zweite Gehirn" ist gerade überall. Das Prinzip: Du gibst einer KI deine Quellen, sie erzeugt Dutzende atomarer Notizen (eine Idee pro Notiz) und verknüpft sie miteinander, um ein vernetztes Wissensnetz voller Bedeutung zu schaffen.
Auf dem Papier klingt das verlockend. In der Praxis halte ich diesen Ansatz für das Opportunitätsmanagement im Product Management für falsch.
Die Welt ist komplex
Um zu verstehen warum, muss man sich zunächst vorstellen, wie ein Netzwerk atomarer Notizen zu einem echten Thema aussieht.
Hier ist ein kleiner Ausschnitt meiner Notizen über Pierre Bourdieu aus meinem Soziologiestudium:
Sobald man beginnt, mit einem anderen Soziologen zu vergleichen — hier Niklas Luhmann, dem Vater des Zettelkasten — explodiert die Komplexität:
Und selbst beim Versuch, nach Großkonzepten zu vereinfachen, bleiben die Verbindungen dicht. Implikationen, Antagonismen, schwache Verbindungen, indirekte Beziehungen... Alles hängt zusammen, aber nicht auf dieselbe Weise.
Die Welt ist komplex. Und das Product Management macht da keine Ausnahme.
Warum das im Product Management nicht funktioniert
Ich lehne diesen Ansatz aus zwei Gründen ab.
Die Fehlerausbreitung ist unkontrollierbar
Wenn man mit einer KI arbeitet, muss man immer in der Lage sein, das zu überprüfen, was sie produziert. In einem Notizennetzwerk, wo alles verknüpft ist, kann sich ein Fehler in einer einzigen Notiz still und leise über die Verbindungen ausbreiten. Man verteidigt am Ende eine Opportunität, die auf falschen Informationen basiert — ohne es zu wissen.
Mit einer begrenzten Anzahl von Dateien — 30, 40 Dateien in einem Verzeichnis, das einer Opportunität gewidmet ist — hat man die menschliche Fähigkeit zu prüfen und zu auditieren. In einem Graphen aus Hunderten vernetzter Notizen ist das eine Illusion.
Das Kontextfenster explodiert
Das zweite Problem ist technischer Natur. Wenn du eine Opportunität untersuchst, musst du die KI fokussiert halten: die Missionsdatei, die gesicherten Fakten, die nächsten zu validierenden Schritte. Das ist ein leichter, beherrschbarer Kontext.
Konfrontierst du dieselbe KI mit einem grenzenlosen Notizennetzwerk, springt sie von Verbindung zu Verbindung, lässt ihr Kontextfenster wachsen und sucht die „richtige" Information in einem Meer von Verknüpfungen. Zu viel Information tötet die Information.
Ein Notizennetzwerk verwaltet sich nicht von selbst
Und es gibt ein noch tieferes Problem. Ein Netzwerk miteinander verknüpfter Notizen hält sich nicht durch Zauberei aufrecht. Sobald das Volumen wächst, tauchen neue Fragen auf:
- Widersprüche: Zwei Notizen widersprechen sich. Welche gilt? Ohne einen expliziten Mechanismus zum Nachverfolgen von Widersprüchen baut die KI (und du) auf instabilen Fundamenten.
- Lücken: Ein ganzer Bereich des Themas ist nicht dokumentiert. Aber wie soll man das in einem Graphen aus Hunderten von Notizen erkennen? Eine unsichtbare Lücke ist gefährlicher als eine identifizierte.
- Entscheidungen: Du hast vor drei Wochen zwischen zwei Optionen abgewogen. Wo steht das? Ist die Entscheidung noch gültig? Wer hat sie getroffen?
Eine flache Datei oder ein Notizennetzwerk beantwortet diese Fragen nicht. Es braucht eine dedizierte Gedächtnisstruktur — mit Dateien, die explizit Widersprüche, den Vollständigkeitsstatus, Entscheidungen und deren Begründungen nachverfolgen.
Ich habe diesen Ansatz in einem früheren Artikel ausführlich beschrieben: Von der Einzeldatei zum Kontextsystem — warum das Gedächtnis eines LLM nicht in ein einziges Dokument passt. Das Prinzip: Jede Mission hat ihren eigenen strukturierten Bereich — Mission, aktueller Stand, Quellen, Notizen, kumulatives Gedächtnis, Lieferobjekte — mit expliziten Mechanismen, um zu verwalten, was das Notizennetzwerk im toten Winkel lässt.
Wenn man sich entscheidet, eine Opportunität zu untersuchen, wettet man auf eine Thematik, eine Feature, einen Impact. Man reduziert den Scope bewusst. Das Notizsystem sollte diese Reduktion widerspiegeln, nicht dagegen ankämpfen.
Die Alternative: der Bounded Context
Deshalb bevorzuge ich einen Ansatz, bei dem jede Opportunität in ihrem eigenen abgegrenzten Bereich mit eigenen Dateien lebt. Wenn ich Informationen aus einem anderen Domäne brauche, erstelle ich keinen Verweis auf die Originalquelle — ich kopiere und passe diese Informationen an den Kontext meiner Opportunität an.
Dieser Ansatz greift genau das Konzept des Bounded Context aus dem Domain-Driven Design auf.
Nehmen wir ein konkretes Beispiel. Ein Gehaltsabrechnungssystem muss wissen, wie viele Urlaubstage die Angestellten diesen Monat genommen haben. Statt einen direkten Link zum Urlaubsverwaltungssystem zu erstellen, integriert man diese Daten in die Domäne „Gehaltsabrechnungsvariablen". So erhält man Urlaubsdaten, die kohärent mit der Gehaltsabrechnungsdomäne sind, anstatt ein Konzept mit seinem gesamten Ursprungskontext in eine andere Domäne zu pressen.
Für das Product Management gilt dieselbe Logik. Jede Opportunität hat ihren eigenen Kontext, eigene Dateien, ihre eigene lokale Wahrheit. Externe Informationen werden importiert und angepasst, nicht dynamisch verlinkt.
Nahe — oder sogar an — Entwicklungsmethoden zu bleiben vermeidet Abstraktionsschichten zwischen Entwicklung und Product. Man verbiegt die Konzepte nicht mehr bei jedem Übergang von einem Kontext in einen anderen.
Fazit
Das zentralisierte zweite Gehirn ohne Grenzen zwischen den Opportunitäten eignet sich nicht für das Product Management. Die Komplexität, die es aufzeigt, ist real — aber die Antwort liegt nicht darin, alles zu verknüpfen, sondern intelligent abzugrenzen.
Dedizierte, überprüfbare Bereiche, in denen die KI innerhalb eines beherrschbaren Perimeters arbeitet: Das ist es, was ermöglicht, die Kontrolle darüber zu behalten, was man aufbaut und was man verteidigt.
Für welche Bereiche funktioniert das zweite Gehirn wirklich gut? Dazu werde ich in einem nächsten Artikel schreiben.
Mehr dazu
Von der einzelnen Datei zum Kontextsystem: Warum das Gedächtnis eines LLM nicht in ein einziges Dokument passt Werkzeuge für organisationale Kohärenz Der PM als Kontext-Architekt Was ist eine atomare Notiz?
Quellen
- Zettelkasten-Methode: https://en.wikipedia.org/wiki/Zettelkasten
- Domain-Driven Design — Bounded Context: https://martinfowler.com/bliki/BoundedContext.html
- Von der Einzeldatei zum Kontextsystem: 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