Wissen, wonach man als Nächstes sucht – und vor allem, wann man aufhört. Statt vorab 30 oder 50 Quellen festzulegen, startet man mit einem kleinen, kuratierten Korpus, zieht daraus strukturiertes Wissen und lässt das, was es weiß und was es nicht weiß, die nächste Suche bestimmen. Das Ergebnis: weniger Redundanz, sichtbare blinde Flecken und ein prüfbares Abbruchkriterium.
LesenWohin mit einem Dokument, das nichts erzeugt, aber alles regiert, was danach erzeugt wird? Das gewohnte Kriterium — die Änderungsgeschwindigkeit — reicht nicht. Ein Funktionskriterium ersetzt es: Erzeugt diese Datei ein Ergebnis, bewahrt sie Wissen, beschreibt sie einen Stand, oder regiert sie künftige Handlungen? Anwendbar auf jedes Objekt, das die Architektur nicht vorgesehen hat.
Wie findet man heraus, ob die Methode, an der man monatelang gebaut hat, anderswo längst existiert — unter einem anderen Namen? Das Vorgehen besteht aus wenigen Schritten: die Idee in Mechanismen zerlegen, nach der Funktion statt nach dem Vokabular suchen, das eigene Fachgebiet und das Englische verlassen, und vorab festlegen, was ein Fund verändern muss, um zu zählen.
Schnell produzieren mit KI verdrängt am Ende die Zeit, in der man denkt. Hier ist ein konkretes Verfahren, das sie schützt: ein begrenzter Kern von Karten, durch verteilte Wiederholung gepflegt und dann auf einem Tisch ausgelegt, um eine neue Idee mit den eigenen Überzeugungen zu konfrontieren. Du bekommst die Aufnahmekriterien, die Wiederholungsrhythmen und den Weg zum Anfang.
Mit einem Kontext arbeiten, ohne von einem irgendwo eingeschalteten Mac abzuhängen. Der Aufbau besteht aus drei Bausteinen: ChatGPT denkt, die Projekt-Direktiven definieren die Engine, Google Sheets erinnert sich. Konkretes Ergebnis: auf einer Messe ein Gespräch im Gehen diktieren, es persistieren, einspeisen und dann das System fragen, welche Fragen vor dem Verlassen der Halle noch offen sind.
Ein Großkunde blockiert deinen Verkauf, weil er seine Daten in seinem Azure will, sein IAM, seine Schlüssel, seinen LLM-Vertrag. Dieser Text gibt dir ein Raster, um solche Anfragen zu sortieren: was deinen Wert wirklich trägt, was ihn nur kaufbar macht, und wo die Grenze zwischen der Kontrolle des Kunden und deiner Fähigkeit verläuft, das Produkt weiterzuentwickeln.
Fünf Tage später findest du den einen Absatz, auf den es ankam, in einem langen ChatGPT-Gespräch kaum wieder. Dieser Bericht zeigt, wie sich ein genauer Ausschnitt auf Zuruf aus dem Fluss herausholen lässt — mit einer schlichten eigenen Direktive und einem Google Sheet als Postausgang. Mit blockierter API, misslungenem Umweg, einer Lösung, die von 50 Sekunden auf zwei kommt, und einer Prüfung nach jedem Schreibvorgang.
Deine besten Artikelideen sterben zwischen dem Moment, in dem sie auftauchen, und dem Moment, in dem du dich endlich zum Schreiben hinsetzt. Der Aufbau, der sie heiß erfasst: die Stimme, um den Kopf zu leeren, ohne zu ordnen; eine Sitzungsquelle, die das Rohe bewahrt; die KI, die die Lücken in zehn Sekunden sichtbar macht statt erst in zwei Tagen.
Jedes neue Format fühlt sich an wie ein Neuanfang: Du öffnest das letzte Dokument, kopierst, formulierst um, und irgendwann driften zwei Versionen auseinander. Schuld sind nicht die fehlenden Werkzeuge, sondern die Gewohnheit, ein Deliverable als Quelle der Wahrheit zu nehmen. Wie sich zwischen Quellen und Dokumente eine wiederverwendbare Schicht einziehen lässt — und was die KI davon hat.
Du spürst, dass ein Text oder eine Entscheidung noch nicht sitzt, kannst aber nicht sagen, warum. Genau hier bringt eine KI wirklich etwas: Sie macht aus einem vagen Unbehagen konkrete Ansatzpunkte — ein blinder Fleck, eine schwache Annahme, ein unbehandelter Einwand. Welche Fragen Spannung statt Produktion erzeugen, und warum menschliche Urteilskraft dadurch wichtiger wird und nicht unwichtiger.
Dein Team baut dasselbe Produktmodell bei jeder Frage neu zusammen, bei jedem Bug, bei jeder Ausschreibung. So schreibst du es einmal auf: mehrere Dutzend Objekte, einige Hundert Regeln, weniger als sechs Stunden. Und vor allem: woran du erkennst, dass du fertig bist — die drei Abschlusskriterien, die Vollständigkeit zu beweisen scheinen und nichts beweisen, und das eine, das hält.
Du stellst einen PO ein, damit er das Backlog pflegt und die Schnittstelle zu den Entwicklern bildet? Dann optimierst du einen Kreislauf, der längst überholt ist. Dieser Text nimmt die Trennung zwischen denen, die das Produkt denken, und denen, die es ausführen, auseinander: warum sie die Qualität senkt, warum das Backlog keinen Beruf tragen kann und warum die KI die letzte Ausrede nimmt, damit zu leben.
Die KI erhöht die Produktionsfähigkeit — nicht die Entscheidungsfähigkeit. Entwickler rücken ans Produkt heran, PM rücken an den Bau heran. Diese Verschiebung lässt die Rollen verschwimmen, ohne die Verantwortung aufzulösen. Ein vollständiger Rundgang: was die KI im Product Management zur Selbstverständlichkeit macht, was schwer bleibt, und ein Katalog der entstehenden Rollen samt ihrer realen Risiken.
Vier Tage lang ein echtes Produkt mit Claude Code gebaut — 180 Commits, bei null angefangen. Was dabei sichtbar wird: ein Tempo, das berauscht, Fallen, die die KI von allein aufstellt, was Tests verändern, wenn man den Code nicht selbst schreibt, und wie weit ein PM gehen kann, ohne seinen Zuständigkeitsbereich zu verlassen. Ein Bericht aus der Praxis, keine Lehrmeinung.
Schneller Code zu produzieren genügt nicht, wenn niemand versteht, was gebaut wurde. Die KI automatisiert genau die Aufgaben, die Junior-Entwickler hervorbrachten, und ein Fehler, der zu spät auftritt, lehrt nichts mehr, sobald das System zu komplex geworden ist. Ein paar konkrete Orientierungspunkte, um die Kontrolle zu behalten: klare Verträge zwischen den APIs, Tests, die an die Fachlichkeit gebunden sind, Rekonstruierbarkeit als Qualitätskriterium statt bloßer Auslieferungsgeschwindigkeit.
Deine Dokumente sagen nicht alles: Das differenzierte Verständnis der Praxis bleibt im Kopf des PM. Sitzungsquellen bieten einen Kanal, um dieses informelle Wissen in einen Kontext einzuspeisen — einen Satz im Flur, eine Nuance beim Kunden, eine aufkeimende Spannung — und aus der Ansammlung von Mikrosignalen besser formulierte Notizen, Annahmen und Entscheidungen zu machen.
Deine Tools legen Informationen sauber ab, bauen aber nichts aus dem auf, was diese Informationen dich lehren. Dieser Text erklärt, warum die Zukunft des Informationssystems kein besseres, KI-gestütztes Formular ist, sondern ein Umschwenken auf Kontexte: übertragbare, geregelte Gedächtniseinheiten, die Quellen, Entscheidungen und Denkarbeit miteinander verknüpfen, statt sie nur abzulegen.
Du verlierst eine halbe Stunde in einer Testumgebung, nur um auf Slack eine Produktfrage zu beantworten? Diese versteckten Kosten fallen weg, sobald die KI den Quellcode befragt — die eigentliche Wahrheit über das Verhalten. Antworten, die in Belegen verankert sind — Funktion, Test, Commit — statt in veralteter Dokumentation. Vorausgesetzt, der Code spricht die Fachsprache.
Du verlierst den Faden, sobald du eine Unterhaltung mit einer KI zu einem länger laufenden Thema wieder öffnest? Dieser Artikel öffnet die Haube eines strukturierten Gedächtnissystems: der Unterschied zwischen Ziel und Aufmerksamkeit, die Direktiven, die Offline-Warteschlange, die drei Gedächtnisarten (Tagebuch, Zusammenfassung, Checkpoints) und der Ablauf einer Sitzung. Genug, um zu verstehen, wie sich eine KI wirklich an eine Mission erinnern kann.
Du glaubst, ein Markt öffnet sich, indem du dein Produkt übersetzt? Brasilien beweist das Gegenteil. An der banalsten Szene überhaupt — dem Bezahlen an der Kasse — verstehst du, warum Alltagskredit, Steuernummer, Pix und informelle Wirtschaft eine kulturelle Infrastruktur bilden, die keine Übersetzung nachbaut. Genug, um einen teuren strategischen Fehler im Auslandsgeschäft zu vermeiden.
Eine ausgezeichnete Notizenbasis reicht nicht, wenn die Ideen nicht wirklich verinnerlicht sind. Die Flash Card ist keine kleine atomare Notiz: Sie ist ein persönlicher Denkpfeiler, frisch an seiner Resonanz erkannt und mit der Zeit durch Erfahrungen und neue Quellen erprobt. Selten per Definition, strukturiert sie das, was man wirklich in sich haben will.
Man häuft Tabs an, Links, schnelle Notizen — und liest sie nie wieder. Das Problem ist nicht die Menge an Information, sondern dass niemand entscheidet, was daraus wird. Dieser Artikel unterscheidet Erfassen vom Wissensaufbau und schlägt einen einfachen Rhythmus vor, um aus seinen Erfassungen Wissen zu machen, ohne darin unterzugehen.
Dieselben Wörter kursieren zwischen Produkt, Marketing, Sales und Geschäftsführung — ohne dass alle ihnen denselben Sinn geben. Das Glossar ist keine Sammlung schulbuchhafter Definitionen: Es ist ein Werkzeug kollektiver Präzision. Es schreibt die Begriffe fest, die Entscheidungen tragen, schützt die Verknüpfungen zwischen Notizen und senkt die Kosten von Gesprächen, in denen alle mit demselben Vokabular eine jeweils andere Idee verteidigen.
„Eine Idee pro Notiz“ — die Formel ist bekannt, führt aber oft in die Irre. Eine atomare Notiz ist keine kurze Notiz: Sie hat einen einzigen begrifflichen Schwerpunkt. Wer diesen Unterschied verstanden hat, erfasst, formuliert, betitelt und verknüpft seine Notizen anders. Und am Ende schreibt er auch anders.
Die thematische Notiz ist das Bindeglied zwischen dem Notizsystem und dem Schreiben. Sie häuft nicht alles an, was ein Thema berührt — sie wählt einen Blickwinkel und führt mehrere atomare Notizen zusammen, um ein Muster, eine Spannung oder eine Argumentationslinie sichtbar zu machen. Weder Ordner noch Enzyklopädie, sondern eine vorübergehend stabile Sicht auf ein Denknetz.
Die meisten Organisationen können Dokumente produzieren. Das Denken dahinter zu Kapital zu machen, können sie nicht. Bei jeder Entscheidung fangen sie fast bei null an. Der PM als Architekt des Kontexts verwandelt verstreutes Kundenwissen — Transkripte, Einwände, Abwägungen, schwache Signale — in einen wiederverwendbaren Vermögenswert. Das Ergebnis: schnellere und robustere Entscheidungen und ein Wettbewerbsvorteil, den die Konkurrenz nicht sofort kopieren kann.
Eine Null-Bug-Politik reduziert den Bestand bekannter Defekte. Aber wenn das Team Bugs schneller behebt, ohne die Art der Produktion zu ändern, bleibt es in einer Reparaturschleife. Das eigentliche Thema liegt vorher: die Verantwortung bei denen verankern, die liefern — zu vage Specs ablehnen, früher testen, QA eine Rolle als Qualitätspolitik statt als Sicherheitsnetz geben. Qualität lässt sich nicht nachträglich delegieren — sie gehört denen, die liefern.
In vielen Organisationen ist das Backlog zu einem sauberen Mülleimer geworden: Man wirft alles rein, um nichts zu vergessen. Ein paar Monate später: 500 Zeilen, die niemand mehr versteht. Ein Backlog sollte kein Ideenspeicher, keine Kundensignal-Datenbank und kein Friedhof unbehandelter Bugs sein. Es dient dazu, Informationen zu organisieren, die reif genug sind, damit mehrere Personen zusammenarbeiten können. Es kommt ins Spiel, wenn die Arbeit aufhört, individuell zu sein.
Bestimmte Produktentscheidungen tauchen überall auf: im Roadmap-Komitee, im Vertrieb, in den Spezifikationen, bei jedem großen Kunden. Ohne Aufzeichnung trifft das Unternehmen sie immer wieder, oft mit weniger Kontext. Der PDR — inspiriert von technischen ADRs — dokumentiert diese übergreifenden Entscheidungsregeln. Selten, kurz, unveränderlich: Er sagt nicht, was zu bauen ist, sondern warum das Unternehmen eine Regel gewählt hat. Er beseitigt Dutzende unnötiger Diskussionen.
Ein Produktteam kann Studien, Workshops und Analysen anhäufen, ohne dass das Unternehmen weiß, was Priorität hat. Die NNL-Roadmap beantwortet dieses Problem: nicht durch Terminplanung, sondern indem sie Verpflichtungen, ernsthafte Richtungen und Möglichkeiten — und vor allem, was nicht gemacht wird — sichtbar macht. Ihre Stärke liegt in der Kapazitätsbeschränkung und im impliziten Nein.
Das eigentliche Problem bei Bugs ist nicht ihr Auftreten, sondern dass sich die Organisation daran gewöhnt, sie zu behalten. Man priorisiert sie, schiebt sie auf, bespricht sie im Komitee — bis ein Kunde eskaliert. Eine Zero-Bug-Policy zielt auf etwas anderes: null bekannte Bugs ohne Entscheidung. Entweder wird behoben, oder man stellt fest, dass es kein Defekt ist. Was diese Politik ablehnt, ist der dritte Zustand: zu wissen, dass ein Bug existiert, und ihn für später in einer Liste zu pflegen.
Deine Teams verlassen das Meeting ausgerichtet — und jedes geht mit einer anderen Version der Entscheidung nach Hause. Das Problem ist nicht zu wenige Meetings, sondern das Fehlen gemeinsamer Objekte. Glossar, One-Pager, PR/FAQ, hierarchisierte Kennzahlen, Entscheidungsprotokoll, Eskalationsregeln: Diese Werkzeuge erzeugen keine Ausrichtung, sie zwingen Meinungsverschiedenheiten dazu, sichtbar zu werden, bevor sie Kosten verursachen.
Du verlässt das Meeting mit einem Aktionsplan, aber nichts wurde wirklich entschieden. Das nenne ich eine weiche Entscheidung: eine Nicht-Entscheidung, verkleidet als Konsens. Organisationen ziehen sie oft einer echten Abwägung vor, weil sie den Anschein von Einigkeit wahrt, ohne den Verlust sichtbar zu machen. Dieser Text untersucht, warum dieser Mechanismus kurzfristig rational ist — und warum er bei der Umsetzung so teuer wird.
Zu beobachten, was Wettbewerber veröffentlichen, bedeutet, Outputs zu lesen ohne die Überlegungen dahinter zu verstehen. Eine nützliche Wettbewerbsbeobachtung beginnt beim Zielkunden: seinen Bedürfnissen, seinen Auswahlkriterien, seinen Alternativen. Wettbewerber werden erst interessant, weil sie zeigen, wie ein Markt auf diese Bedürfnisse reagiert. Eine Reaktion zu kopieren ohne die dahinterliegende Logik zu verstehen, heißt eine Antwort zu reproduzieren, ohne die richtige Frage gestellt zu haben.
Klassisches RAG fängt bei jeder Frage von vorne an. Ein KI-Wiki — ein persistentes Wiki, das ein LLM pflegt — sichert Fachwissen ein für alle Mal. Atomare Notizen, Verknüpfungen zwischen Konzepten, Erkennung von Widersprüchen: das Wissen wird kompiliert, nicht wiederentdeckt. Erfahrungsbericht mit 950 Notizen aus Quellen der Industriewartung, mit Erkenntnissen zur Kalibrierung und konkreten Anwendungsfällen.
Produktchancen in einem grenzenlosen Notizennetzwerk zu verwalten bedeutet Kontrollverlust: Fehler breiten sich unbemerkt aus, das Kontextfenster der KI explodiert, und Widersprüche sowie Entscheidungen sind nicht mehr auffindbar. Der Bounded Context — entlehnt aus dem DDD — bietet eine bessere Alternative: jede Opportunität in ihrem eigenen abgegrenzten Bereich, überprüfbar, mit strukturiertem Gedächtnis.
Du ertränkst in E-Mails und verlierst den Faden der laufenden Themen? Indem ich die Strukturierung an Claude delegierte — eine Datei, ein paar Direktiven, dann eine schrittweise Aufteilung — habe ich 500 Hausverwaltungs-E-Mails in eine abfragbare Wissensbasis verwandelt. Sieben Schritte, von der vagen Direktive zum Mehrfachdatei-System, ohne je ein komplexes Framework zu brauchen.
Dokumentation folgt dem Code nie wirklich. Das wissen wir, wir akzeptieren es — und trotzdem kostet es bei jeder Änderung Zeit. KI verändert die Gleichung: Wenn der Code sauber ist, wird er zur Quelle der Wahrheit, aus der sich andere Artefakte neu generieren lassen — Specs, Changelogs, Support-Dokumentation. Dieser code-centric-Ansatz erfordert ein Mindestmaß an technischer Kultur, eröffnet aber einen echten Hebel für Product Manager, die ihn beherrschen.
Zu viele Insight-Systeme scheitern, weil sie alles auf einer einzigen Achse klassifizieren: Features oder Ziele. Taktisches Feedback geht verloren, strategische Signale verdampfen. Ein Rahmen mit 4 Ebenen — Geschäftsziel, Anwendungsfall, Produktfähigkeit, Reibungspunkt — ermöglicht es, alles zu erfassen ohne unnötige Komplexität, und jedes Signal der richtigen Entscheidungsebene zuzuordnen.
Ein verschwenderischer Skill blockiert dich nach 3-4 Ausführungen statt nach 8-10. Entdecke die 5 stillen Fallen, die dein Kontingent sättigen, wie du in 3 einfachen Phasen auditierst und 40% Kapazität gewinnst — ohne das Modell zu wechseln. Produktivität zurückgewonnen.
Deine Arbeitstage als PM werden von Aufgaben aufgefressen, die nichts Strategisches an sich haben. In acht Tagen mit Claude Code habe ich meine Wettbewerbsbeobachtung automatisiert — Sammlung, Organisation, Aktualisierung. Gewonnene Zeit zum Analysieren, Verstehen, Entscheiden. Dieser Erfahrungsbericht zeigt konkret, warum sich der Schwerpunkt des Product-Manager-Berufs verschiebt: weniger Zwischenartefakte, mehr echte Strategie.
Software zu produzieren ist keine Seltenheit mehr. Die Cloud hat das normalisiert, KI wird diese Entwicklung weiter beschleunigen. Wenn alle schnell und gut bauen können, reicht es nicht mehr, Features am laufenden Band zu liefern. Der echte Wettbewerbsvorteil verlagert sich zum Verstehen des Kontexts: die Branche, die Nutzer, die Kunden, der Wettbewerb, die Normen. Besser verstehen als die anderen — bevor man baut.
Schluss damit, den Kontext in jeder Sitzung neu erklären zu müssen. Claude merkt sich automatisch, was du gemacht hast, welche Entscheidungen getroffen wurden, welche Probleme aufgetaucht sind — pro Projekt, in deinem Git-Repo, ohne Datenbank. Portabel, versionierbar, weniger als 1 $/Monat. So richtest du das System in unter einer Stunde ein.