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