Dein Team baut bei jeder Frage, jedem Bug, jeder Ausschreibung dasselbe Produktmodell neu auf. Hier steht, wie du es einmal aufschreibst: 52 Objekte, 250 Regeln, unter sechs Stunden. Und vor allem, wie du weißt, dass du fertig bist — die drei Abbruchkriterien, die nach Vollständigkeit aussehen und nichts beweisen, plus das einzige, das hält.
LesenDu stellst einen PO ein, der das Backlog pflegt und zwischen Fachbereich und Entwicklern vermittelt? Dann optimierst du einen längst überholten Ablauf. 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 ein Backlog keinen Beruf tragen kann, und warum die KI die letzte Ausrede dafür wegnimmt.
KI steigert die Produktionsfähigkeit — nicht die Entscheidungsfähigkeit. Entwickler steigen zum Produkt auf, PMs steigen zur Konstruktion ab. Diese Verschiebung verschwimmt die Rollen, ohne die Verantwortlichkeiten aufzulösen. Ein vollständiger Überblick darüber, was KI im Product Management banaliert, was schwer bleibt, und ein Katalog der entstehenden Rollen mit ihren echten Risiken.
Vier Tage, um ein echtes Produkt mit Claude Code zu bauen — 180 Commits, von null gestartet. Was das enthüllt: die berauschende Geschwindigkeit, die Fallstricke, die die KI allein erzeugt, was Tests verändern, wenn man nicht selbst kodiert, und wie weit ein PM gehen kann, ohne seinen Bereich zu verlassen. Ein Praxisbericht, keine Doktrin.
Code schneller zu produzieren reicht nicht, wenn niemand versteht, was gebaut wurde. KI automatisiert genau die Aufgaben, die Junior-Entwickler formten, und der verzögerte Fehler lehrt nichts mehr, sobald das System zu komplex geworden ist. Einige konkrete Orientierungspunkte, um die Kontrolle zu behalten: klare Verträge zwischen APIs, Tests, die mit dem Funktionalen verbunden sind, Rekonstruierbarkeit als Qualitätskriterium statt bloßer Liefergeschwindigkeit.
Deine Dokumente sagen nicht alles: das feine Verständnis des Felds bleibt im Kopf des PMs. Sitzungsquellen bieten einen Kanal, um dieses informelle Wissen in einen KI-Kontext einzubringen — ein Satz aus dem Flur, eine Kundennuance, eine aufkeimende Spannung — und die Ansammlung von Mikrosignalen in besser formulierte Notizen, Hypothesen und Entscheidungen zu verwandeln.
Deine Tools ordnen Informationen gut ein, aber sie kapitalisieren nicht, was diese Informationen dich lehren. Dieser Text erklärt, warum die Zukunft des Informationssystems nicht ein besseres KI-gestütztes Formular ist, sondern eine strukturelle Verschiebung hin zu Kontexten — portablen, gouvernierten Gedächtniseinheiten, die Quellen, Entscheidungen und Überlegungen verknüpfen, statt sie nur zu speichern.
Du verlierst eine halbe Stunde damit, in einer Testumgebung zu testen, um eine Produktfrage auf Slack zu beantworten? Diese versteckten Kosten verschwinden, wenn die KI den Quellcode befragt — die echte Wahrheit des Verhaltens. Antworten verankert in Belegen — Funktionen, Tests, Commits — statt in veralteter Dokumentation. Vorausgesetzt, der Code spricht die Sprache des Fachbereichs.
Du verlierst den Faden, sobald du ein KI-Gespräch zu einem 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ächtnisse (Tagebuch, Zusammenfassung, Checkpoints) und der Ablauf einer Sitzung. Um zu verstehen, wie eine KI sich wirklich an eine Mission erinnern kann.
Du glaubst, ein Markt öffnet sich durch die Übersetzung deines Produkts? Brasilien beweist das Gegenteil. Durch die banalste Szene — an der Kasse bezahlen — wird klar, warum Alltagskredit, Steuernummer, Pix und Schattenwirtschaft eine kulturelle Infrastruktur bilden, die keine Übersetzung reproduziert. Das bewahrt vor einem kostspieligen strategischen Fehler im Auslandsgeschäft.
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 versammelt mehrere atomare Notizen, um ein Muster, eine Spannung oder eine Argumentationslinie sichtbar zu machen. Weder Ordner noch Enzyklopädie: eine vorübergehend stabile Sicht auf ein Denknetzwerk.
„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 konzeptuellen Schwerpunkt. Wer diesen Unterschied versteht, verändert die Art, wie er Ideen festhält, umformuliert, betitelt und verknüpft — und letztlich die Art, wie er schreibt.
Dieselben Begriffe kursieren zwischen Produkt, Marketing, Vertrieb und Geschäftsführung — ohne dass jeder Bereich ihnen dieselbe Bedeutung gibt. Ein Glossar ist keine Sammlung schulischer Definitionen: Es ist ein Werkzeug kollektiver Präzision. Es stabilisiert die Begriffe, die Entscheidungen tragen, schützt die Verbindungen zwischen Notizen und senkt den Aufwand für Gespräche, in denen jeder mit demselben Vokabular eine andere Idee verteidigt.
Wir sammeln Tabs, Links, schnelle Notizen — und lesen sie nie wieder. Das Problem ist nicht die Menge an Informationen, sondern das Fehlen einer Entscheidung darüber, was damit werden soll. Dieser Artikel unterscheidet Erfassen von Kapitalisieren und schlägt einen einfachen Rhythmus vor, um Erfassungen in Wissen zu verwandeln, ohne darin zu versinken.
Eine ausgezeichnete Notizenbasis zu haben reicht nicht, wenn die Ideen nicht wirklich verinnerlicht sind. Die Flash Card ist keine kleine atomare Notiz: Sie ist ein persönlicher Denkpfeiler, der im Moment durch seine Resonanz erkannt und mit der Zeit durch Erfahrungen und neue Quellen erprobt wird. Selten per Definition, strukturiert sie das, was du wirklich in dir haben möchtest.
Die meisten Organisationen wissen, wie man Dokumente produziert. Was sie nicht wissen: wie man das dahinterliegende Denken kapitalisiert. Bei jeder Entscheidung fangen sie fast von vorne an. Der PM als Kontext-Architekt verwandelt verstreutes Kundenwissen — Transkripte, Einwände, Abwägungen, schwache Signale — in ein wiederverwendbares Asset. Das Ergebnis: schnellere, robustere Entscheidungen und ein Wettbewerbsvorteil, den Konkurrenten nicht sofort kopieren können.
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.
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.
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.
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.
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.
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.
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.
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.
Klassisches RAG fängt bei jeder Frage von vorne an. Ein KI-Wiki — ein persistentes Wiki, das ein LLM pflegt — kapitalisiert 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.
4 weitere Artikel im Archiv.