product-management

Der PO ist kein Beruf, sondern eine Funktion — und die KI ändert daran nichts, sie beschleunigt es

Du 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.

PM, Entwickler und KI: Die Rollen verschwimmen, die Verantwortlichkeiten bleiben

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.

Die Produktfrage muss vom Quellcode ausgehen

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.

Unter der Haube meiner Kontext-Engine: wie eine KI sich an eine Mission erinnert

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.

Ein Produkt erschließt einen Markt nicht über die Sprache, sondern über die Gewohnheiten

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.

Der PM als Kontext-Architekt

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.

Zero Bugs: Hör auf, Defekt-Bestände zu verwalten

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.

Roadmap NNL: ausrichten ohne zu verzetteln

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.

Product Decision Record: Produktentscheidungen dokumentieren, die das Unternehmen strukturieren

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.

Das Backlog ist kein Mülleimer: Es ist ein Werkzeug zum Handeln

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.

Qualität gehört denen, die liefern

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.

Das zweite Gehirn ist eine Sackgasse für das Product Management

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.

Code centric

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.

Warum eine einzige Klassifikation nicht ausreicht, um Kundenfeedback zu strukturieren

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.

Im Software-Bereich wird der Vorteil nicht mehr die Technologie sein. Es wird das Verstehen des Kontexts sein.

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.

In 8 Tagen habe ich verstanden, dass sich der Beruf des Product Managers von Grund auf verändern wird

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.