Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Dokumentation, die immer hinterherhinkt
Das kennen wir alle: Ein Bug taucht auf, oder eine funktionale Änderung muss bearbeitet werden. Der erste Reflex ist, die Dokumentation zu konsultieren. Und meistens ist sie nicht mehr aktuell.
Eigentlich wissen wir fast im Voraus, dass sie es nicht sein wird. Das Muster ist bekannt: Eine Dokumentation wird erstellt, mit der Spezifikation übergeben, dann beginnt die Entwicklung. Unterwegs tauchen Fragen auf, Entscheidungen werden getroffen, einige Punkte ändern sich, und die Entwickler treffen manchmal Entscheidungen, ohne systematisch zum Product Manager zurückzukehren. Das ist normal. Andernfalls würde die Arbeit im Rhythmus einer permanenten Abstimmung voranschreiten. Das Ergebnis ist jedoch immer dasselbe: Dokumentation und Code driften auseinander.
Diese Divergenz liegt auch an einer sehr einfachen Einschränkung. Bei jeder Änderung, auch einer kleinen, hat niemand wirklich die Zeit, die richtige Spezifikation, das richtige Mockup, das richtige Support-Dokument oder den richtigen Changelog zu suchen und alles zu aktualisieren. Wir arbeiten an einem lebendigen Produkt, das sich kontinuierlich weiterentwickelt. In diesem Kontext wird die manuelle Pflege aller Artefakte schnell zu aufwendig im Verhältnis zur verfügbaren Zeit.
Je mehr Zeit vergeht, desto schlimmer wird das Problem. Eine Funktionalität wird heute nicht mehr einmal für alle Zeit konzipiert: Sie wird angepasst, erweitert, korrigiert — manchmal über Monate oder Jahre. Unter diesen Bedingungen ist es wenig realistisch zu erwarten, die ursprüngliche Spezifikation, die Projektgespräche, den Changelog, die Support-Dokumentation, die Sales-Dokumentation und die Mockups perfekt synchron zu halten.
Der Code als einzige Quelle der Wahrheit
Das eigentliche Lieferobjekt ist letztlich der Code. Das ist vielleicht nicht die offizielle Formel, aber er ist es, der den tatsächlichen Zustand des Produkts beschreibt. Der Rest versucht nur, ihm zu folgen. In dieser Hinsicht bleibt der Ausdruck „Code is Law" besonders treffend: https://framablog.org/2010/05/22/code-is-law-lessig/
Lange Zeit war diese Situation unvermeidlich. Die Dokumentation in natürlicher Sprache war die am wenigsten schlechte Lösung — vor allem weil die meisten Product Manager nicht direkt im Code arbeiten. Es brauchte daher eine Zwischenschicht, verständlich für alle, nutzbar in Meetings, teilbar mit Teams und ohne besondere technische Kompetenz verwendbar.
Was KI verändert
KI verändert diese Gleichung nun. Wenn der Code sauber genug und gut dokumentiert ist, lässt er sich als nutzbare Quelle einsetzen, um andere Lieferobjekte zu rekonstruieren oder zu aktualisieren. Man kann zum Beispiel vom echten Code ausgehen, um nach einer Lieferung eine Support-Dokumentation zu aktualisieren, einen verlässlicheren Changelog zu generieren oder eine funktionale Spezifikation aus dem aktuellen Zustand des Produkts heraus zu rekonstruieren — statt aus einem alten Dokument.
Der Code ist nicht mehr nur das finale Lieferobjekt: Er wird zum zentralen Element, zur Quelle der Wahrheit, um die herum die anderen Produktartefakte kreisen und neu aufgebaut werden — in einer wirklich code-centric-Logik.
Die Frage der technischen Kultur
Das wirft aber eine andere Frage auf: Wie kann ein nicht-technischer Product Manager von dieser Möglichkeit profitieren?
Die aktuellen Werkzeuge sind leistungsfähig, aber man setzt sie nicht ohne Urteilsvermögen ein. Sie können helfen, schnell zu produzieren, bestimmte Aufgaben zu automatisieren und nützliche Bausteine zu erzeugen. Sobald man jedoch Architektur, Gesamtkohärenz oder Wartbarkeit berührt, werden ihre Grenzen schnell sichtbar. Ohne ein Mindestmaß an technischer Kultur besteht die Gefahr, viele lokal effektive, aber schlecht miteinander verzahnte Werkzeuge zu häufen. Man gewinnt hier und da Zeit — und verliert sie dann wieder beim Datenaustausch, beim Umgang mit Inkohärenzen oder beim Pflegen eines Gefüges, das schwer zu überblicken geworden ist.
Die Herausforderung ist also nicht nur, schneller zu produzieren. Es geht darum, in einem kohärenten Rahmen zu produzieren. Diese Kohärenz ist es, die den Unterschied macht zwischen einer Anhäufung von Werkzeugen und einem echten Arbeitssystem.
Aus dieser Perspektive besteht wahrscheinlich bereits ein Fähigkeitsgefälle zwischen PMs mit technischem Hintergrund und denen ohne. Nicht weil die einen grundsätzlich besser wären als die anderen, sondern weil die ersten heute einen zusätzlichen Hebel haben: Sie können direkter in die eigentliche Substanz des Produkts — also den Code — eingreifen und ihn als Basis nutzen, um andere Artefakte zu erzeugen, zu prüfen oder zu hinterfragen.
Man könnte einwenden, dass SaaS zunehmend Agenten integrieren werden, die diese Aufgaben automatisieren können. Das ist wahrscheinlich und wird ein echter Fortschritt sein. Aber ich glaube nicht, dass das ausreicht, um den Unterschied zu beseitigen. Die meisten dieser Werkzeuge werden spezialisiert bleiben.
Genau da liegt die Grenze. Ein Werkzeug wie Zendesk kann wahrscheinlich helfen, eine bessere Support-Dokumentation zu erstellen. Ein Werkzeug wie Figma bleibt hervorragend für die Gestaltung von Oberflächen. Aber keines von beiden hat allein eine vollständige Sicht auf das reale Produkt — so wie es im Code existiert, sich in den Merge Requests weiterentwickelt und in seinem fachlichen Kontext verstanden werden muss.
Heute kann ich mit den richtigen Werkzeugen zum Beispiel mehrere Informationsebenen kreuzen: den Quellcode, die Änderungshistorie, die Merge Requests und die Geschäftsregeln, die ich als Product Manager angesammelt habe. Das ermöglicht nicht nur eine präzisere Dokumentation, sondern auch das Hinterfragen dessen, was bereits existiert.
Dieselbe Logik gilt für die Konzeption. Heute entwirft man eine Oberfläche in Figma und entwickelt sie dann. Aber wenn ich in der Lage bin, ein Design System aus dem echten Code zu rekonstruieren, es gemäß den Entwicklungen im Repository aktuell zu halten und die Entwicklungskonventionen des Teams hinzuzufügen, dann ändert das Mockup seinen Status. Es ist nicht mehr nur eine Darstellung: Es kann anfangen, eine erste nutzbare Grundlage für die Front-End-Entwickler zu werden.
Anders gesagt: Die Grenze zwischen Konzeption, Implementierung und Dokumentation beginnt zu verschwimmen. Das ist nicht nur eine Frage der Produktivität. Es ist eine tiefere Transformation: Der Code ist nicht mehr nur das Ergebnis der Arbeit — er wird auch zum Rohmaterial, aus dem sich der Rest neu aufbauen lässt.
Was MCP verändern wird
Ich behaupte nicht, dass dieses Modell bereits stabil ist. In einigen Monaten mag es teilweise überholt sein. MCP insbesondere kann das Gleichgewicht noch einmal verschieben. Man kann sich morgen ein Ökosystem vorstellen, in dem jeder SaaS über seine eigene Agentenschicht verfügt, die mit anderen Systemen kommunizieren kann. Figma könnte zum Beispiel Kontext aus einem GitLab-Repository beziehen, aktuelle Änderungen lesen, relevante Merge Requests verstehen und die Konzeption besser an die Realität des Produkts anpassen. Ganz so weit sind wir noch nicht, aber die Richtung wird sichtbar.
Deshalb erscheint mir MCP wichtig. Genauso wie APIs unverzichtbar wurden, als SaaS aufhörten, in geschlossenen Kreisläufen zu leben, könnten MCPs essenziell werden, wenn sich Agenten verallgemeinern. Jedes Werkzeug behält seine Spezialität, aber der echte Wert kommt von seiner Fähigkeit, mit anderen zu kommunizieren, Kontext zu beziehen und in einem größeren Ökosystem als dem eigenen Bereich zu handeln.
Die beste Haltung ist im Moment wohl ernsthaftes Experimentieren. Nicht um einem Trend zu folgen, sondern um zu verstehen, was bereits konkret Wert schafft. Denn der laufende Wandel ist nicht nur technologischer Natur. Er berührt die eigentliche Natur der Produktlieferobjekte, ihre Quelle der Wahrheit und die Rolle des Product Managers bei ihrer Entstehung.
Weiterführendes
Ein Sitzungsgedächtnis wie in OpenClaw einrichten In 8 Tagen habe ich verstanden, dass sich der Beruf des Product Managers von Grund auf verändern wird Qualität gehört denen, die liefern Die Produktfrage muss vom Quellcode ausgehen