Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Fast täglich bekomme ich auf Slack die Produktfrage.
Keine abstrakte Frage. Keine große Reflexion über die Fünfjahresvision. Eine echte Frage aus der Praxis.
Kann man das machen?
Was passiert, wenn der Kunde das Produkt so konfiguriert?
Was ist die Grenze?
Gilt diese Regel auch in diesem Fall?
Warum blockiert das Produkt hier?
Kann man dem Kunden das versprechen?
Manche dieser Fragen sind strategisch. Sie erfordern, den Markt zu verstehen, den Kunden, die Positionierung, die Richtung, die man einschlagen will. In diesen Fällen braucht man einen Product Manager. Man braucht ein Urteil. Manchmal muss man Nein sagen, manchmal abwägen, manchmal eine Orientierung verantworten.
Aber viele Fragen sind nicht dieser Art.
Sie betreffen das tatsächliche Verhalten des Produkts.
Eine Regel. Eine Grenze. Eine Ausnahme. Eine Beschränkung. Ein Anwendungsfall. Eine Konfiguration. Eine Interaktion zwischen zwei Funktionalitäten.
Und da sollte die Antwort theoretisch einfach sein.
Das Problem: Sie ist es nicht immer.
Die versteckten Kosten der Produktfrage
Wenn die Frage präzise ist, reicht es nicht immer, die Dokumentation zu öffnen.
Erstens, weil die Dokumentation nicht immer existiert.
Dann, weil sie manchmal existiert, man aber nicht weiß, ob sie noch aktuell ist.
Schließlich, weil die echte Frage oft einen Grenzfall betrifft, den niemand explizit dokumentiert hat.
Also tut man, was alle PM, CSM, Support-Mitarbeiter oder Entwickler tun, wenn sie einen Zweifel haben: man testet.
Man öffnet eine Testumgebung.
Man bereitet einen Datensatz vor.
Man wiederholt das Szenario.
Man prüft, ob das Produkt blockiert, akzeptiert, berechnet, anzeigt, verbirgt, auslöst, sendet, verweigert.
Und eine halbe Stunde ist vergangen.
Manchmal eine Stunde.
Manchmal mehr.
Diese Zeit erscheint nirgendwo. Nicht in Jira. Nicht in der Roadmap. Nicht in den Schätzungen. Sie wird einfach vom normalen Funktionieren der Organisation absorbiert.
Es gibt auch einen anderen Kostenfaktor, noch unsichtbarer: den Kontextwechsel.
Die Frage kommt selten zum richtigen Zeitpunkt. Sie kommt, weil ein Kunde wartet. Weil ein Vertriebsmitarbeiter in einem Termin ist. Weil ein CSM einen Punkt vorbereitet. Weil der Support vor Ende des Tages antworten muss.
Also unterbricht man, was man gerade tat. Man taucht in ein Thema ein. Man testet. Man antwortet. Dann versucht man, zu dem zurückzukehren, was man vorher tat.
Das ist nicht nur Zeitverlust. Es ist Verlust intellektueller Kontinuität.
Und genau diese Art von Aufgabe sollte die KI absorbieren.
Das Problem ist nicht die Frage. Es ist die Quelle.
Man könnte antworten: Es reicht, eine bessere Dokumentation zu haben.
Theoretisch, ja.
In der Praxis, nein.
Eine Produktdokumentation hinkt fast immer hinter dem echten Produkt her. Das ist kein Problem individueller Disziplin. Es liegt nicht nur daran, dass jemand vergessen hat, eine Seite zu aktualisieren.
Es ist struktureller.
Eine Spec beschreibt eine Absicht. Ein PRD beschreibt ein Ziel, erwartete Regeln, Szenarien. Ein Mockup beschreibt eine gewünschte Oberfläche. Aber zwischen dieser Absicht und der Produktion passiert immer etwas.
Kompromisse werden gemacht.
Details werden angepasst.
Grenzfälle tauchen auf.
Entscheidungen werden während der Entwicklung getroffen.
Technische Beschränkungen zwingen zu leichten Verhaltensänderungen.
Austausche finden in einem Pull Request oder einer Merge Request statt.
Abwägungen finden nicht immer ihren Weg zurück in die ursprüngliche Dokumentation.
Das ist nicht unbedingt schlimm. Es ist sogar ziemlich normal. Ein lebendes Produkt baut sich nicht wie ein starres Dokument.
Aber das schafft eine einfache Konsequenz: Die Spec ist nicht die Wahrheit des Produkts.
Sie ist eine nützliche Annäherung zu einem bestimmten Zeitpunkt.
Die Wahrheit ist das, was läuft.
Und was läuft, ist der Code.
Der Code als Produkt-Wahrheitsquelle
Die Produktion ist die Realität.
Nicht die Spec.
Nicht das PRD.
Nicht die Notion-Seite.
Nicht die Erinnerung des PM.
Nicht die Slack-Diskussion von vor drei Wochen.
Um zu wissen, wie das Produkt sich wirklich verhält, muss man schauen, was geliefert wird. Und was geliefert wird, steckt im Quellcode.
So gesagt kann das brutal klingen. Man könnte glauben, das komme darauf hinaus zu sagen: „Werft die gesamte Dokumentation weg."
Das ist nicht die Idee.
Die richtige Unterscheidung liegt nicht zwischen „Code" und „Dokumentation".
Die richtige Unterscheidung liegt zwischen dem, was erklärt, und dem, was beschreibt.
Man behält, was erklärt.
Man regeneriert, was beschreibt.
Kontexte müssen bewahrt werden. Sie enthalten die Diskussionen, die Quellen, die Überlegungen, die Ideen, die es ermöglicht haben, zu einer Wahl zu gelangen. Das sind wiederverwendbare Bausteine.
Entscheidungen müssen bewahrt werden. Wenn ein Unternehmen eine Richtung wählt, muss man das Warum bewahren. Warum diese Wahl? Welche Alternativen wurden verworfen? Warum ersetzt diese Entscheidung eine frühere?
Das ist die Rolle der Product Decision Records, der PDR. Ich habe bereits darüber geschrieben: Ein PDR beschreibt keine Feature, er zeichnet eine strukturierende Produktentscheidung nach.
Bestimmte Beschränkungen müssen auch zugänglich bleiben: vertragliche, regulatorische Beschränkungen, externe Dokumente, spezifische Zusagen. Nicht alles lässt sich aus dem Code ableiten.
Aber die Dokumentation, die das Produktverhalten beschreibt, sollte so weit wie möglich aus dem Code regeneriert werden.
Weil der Code die Wahrheit des implementierten Verhaltens ist.
Was die KI ermöglicht
Bisher hatte diese Idee eine offensichtliche Grenze.
Code ist Code.
Er ist nicht immer lesbar für den Support. Nicht immer lesbar für den Vertrieb. Nicht immer lesbar für eine Führungsebene. Er ist nicht einmal immer leicht lesbar für einen PM, besonders wenn er keinen technischen Hintergrund hat.
Lange Zeit brauchte man daher eine Zwischenschicht. Specs. Support-Dokumente. Produktseiten. Changelogs. Tabellen. Schaubilder.
Die KI verändert diese Gleichung.
Sie kann zur Schnittstelle zwischen einer Fachfrage und dem Quellcode werden.
Ein Support-Mitarbeiter kann fragen: „Was passiert, wenn der Kunde diesen Artikel nach der Validierung storniert?"
Ein CSM kann fragen: „Unter welchen Bedingungen blockiert dieser Workflow?"
Ein Vertriebsmitarbeiter kann fragen: „Können wir diese Konfiguration diesem Interessenten versprechen?"
Ein PM kann fragen: „Wo ist diese Regel implementiert und welche Fälle sind nicht abgedeckt?"
Und die KI kann im Code suchen, in der Git-Historie, in den Merge Requests, in den Feature Flags, in den Fachkontexten, dann eine verständliche Antwort produzieren.
Keine magische Antwort.
Eine verankerte Antwort.
Eine gute Produktantwort muss ihre Belege zeigen
Der Schlüsselpunkt liegt hier.
Wenn die KI ohne Belege antwortet, wird sie zu einer neuen approximativen Dokumentation. Schneller, eleganter, aber nicht unbedingt zuverlässiger.
Man muss die KI also zwingen, ihre Antwort zu verankern.
Wenn sie behauptet, eine Regel existiere, muss sie sagen, warum.
Nicht nur: „Das Produkt funktioniert so."
Sondern: „Das Produkt funktioniert so, weil diese Funktion diese Regel anwendet, weil diese Ausnahme diesen Fall blockiert, weil diese Merge Request dieses Verhalten eingeführt hat, weil dieser Test dieses Szenario abdeckt."
Die Belege müssen nicht unbedingt im Mittelpunkt der Antwort stehen. Für den Support oder den Vertrieb können sie unten im Dokument stehen. Nicht jeder muss die technischen Details lesen.
Aber sie müssen existieren.
Ihre Anwesenheit verändert das Verhalten der KI. Sie kann nicht mehr nur nach Plausibilität antworten. Sie muss ihre Behauptungen an faktischen Elementen festmachen.
Das ist dieselbe Logik wie bei einer Textanalyse. Wenn ich eine KI bitte, ein Korpus zu analysieren, bevorzuge ich, dass sie mir für jede Schlussfolgerung den Satz oder den Absatz angibt, auf den sie sich stützt. Das begrenzt Halluzinationen stark.
Für eine Produktfrage ist es genauso.
Der Beleg kann eine Datei sein.
Eine Funktion.
Eine Ausnahme.
Ein Test.
Ein Commit.
Eine Merge Request.
Eine Pull Request.
Ein Feature Flag.
Eine Produktentscheidung.
Eine Fachquelle.
Ohne das verschiebt man nur das Problem. Man ersetzt das unvollkommene Gedächtnis des PM durch das probabilistische Gedächtnis eines Modells.
Das reicht nicht.
Man muss auch sagen, was man nicht weiß
Eine gute Produktantwort muss nicht nur antworten.
Sie muss auch sagen, wo sie blockiert.
Das ist eine wesentliche Direktive.
Die KI muss schreiben können:
„Ich habe keinen Test gefunden, der diesen Fall abdeckt."
„Der Code zeigt je nach Feature-Flag-Zustand zwei mögliche Verhaltensweisen."
„Ich kann das genaue Verhalten für diesen Kunden nicht bestimmen, ohne Zugriff auf seine Konfiguration zu haben."
„Der PDR gibt eine Regel an, aber der Code scheint etwas anderes zu implementieren."
„Die aktuelle Support-Dokumentation widerspricht dem im Code beobachteten Verhalten."
Das ist unbequem, aber wertvoll.
Ein ernsthafter Mensch macht dasselbe. Wenn er es nicht weiß, sagt er es. Wenn er einen Zweifel hat, signalisiert er ihn. Wenn er testen muss, testet er.
Das Ziel ist nicht zu glauben machen, dass die KI alles weiß.
Das Ziel ist, die Recherchekosten zu senken und gleichzeitig die Nachvollziehbarkeit zu erhöhen.
Nicht alle Lesenden brauchen dieselbe Lektüre
Eine Produktfrage kann mehrere Fachbereiche interessieren.
Der Support will oft eine beim Kunden verwertbare Antwort.
Der CSM will die Nutzung und die Auswirkungen verstehen.
Der Vertrieb will wissen, was er versprechen kann, und welchen Wert er hervorheben kann.
Der PM will die Regel, die Grenze, die Ausnahme prüfen.
Die Führungsebene will vielleicht den strategischen Einsatz verstehen.
Man könnte also für jeden Fachbereich eine andere Antwort vorstellen.
Aber das ist nicht unbedingt notwendig.
Eine einzige Antwort kann in mehrere Winkel strukturiert werden. Ein kurzer Teil, der die Frage beantwortet. Ein Support-Teil. Ein Nutzungsteil. Ein Wertteil. Ein Grenzenteil. Ein Belegteil.
Jeder liest, was er braucht.
Und manchmal ist es gerade nützlich, dass ein Vertriebsmitarbeiter eine Produktgrenze sieht oder ein CSM den technischen Ursprung eines Verhaltens versteht. Das hängt von der Unternehmenskultur ab. Manche Organisationen ziehen es vor, Informationen zu beschränken. Andere gewinnen an Reife, indem sie sie teilen.
Das ist keine rein technische Frage.
Es ist eine Frage der Kultur.
Die notwendigen Bausteine
Technisch reicht es nicht, ein LLM an ein Git-Repository anzuschließen und zu hoffen, dass alles funktioniert.
Mehrere Werkzeuge sind komplementär.
RAG ermöglicht es, die richtigen Fragmente zu finden. Es ist oft sehr effizient darin, relevante Stücke aus einer großen Dokumentenmasse oder einem umfangreichen Code hervorzubringen.
Aber RAG reicht nicht immer. Es findet. Es reist nicht unbedingt.
Ein semantischer Graph kann helfen, nahe liegende Elemente zu erkunden: verwandte Konzepte, benachbarte Module, verbundene Regeln, Ereignisse, die andere Ereignisse auslösen.
Das Durchlaufen des Filesystems bleibt auch unverzichtbar. Wenn man eine Zone identifiziert hat, muss man manchmal das Verzeichnis lesen, die nahe liegenden Dateien öffnen, die lokale Struktur verstehen. Das ist weniger elegant als eine Vektorsuche, aber oft sehr effizient.
Git bringt eine weitere Dimension: die Zeit.
Der aktuelle Code sagt, was existiert. Die Historie sagt, wie man dahin gelangt ist. Commits, Pull Requests oder Merge Requests können die Absicht, die Diskussionen, die Kompromisse, die Korrekturen enthüllen.
Feature Flags fügen noch eine Nuance hinzu. Der Code kann mehrere mögliche Verhaltensweisen enthalten. Das tatsächliche Verhalten hängt dann vom Zustand des Flags ab.
Wenn die KI keinen Zugang zu diesem Zustand hat, muss sie bedingt antworten: Wenn das Flag aktiviert ist, ist das Verhalten dieses; andernfalls ist es anders.
Wenn sie Zugang zur Umgebung hat, kann sie weiter gehen: Für diesen bestimmten Kunden, in dieser bestimmten Konfiguration, ist das aktive Verhalten dieses.
Dieser Übergang ist wichtig. Die Produktfrage betrifft nicht immer den abstrakten Code. Sie betrifft manchmal das Produkt, so wie ein bestimmter Kunde es erlebt.
Die Bedingung: Code, der Fachsprache spricht
Es gibt jedoch eine Grundbedingung.
Der Code muss den Fachbereich repräsentieren.
Wenn der Code ein Spaghetti-Durcheinander ist, wenn die Fachkonzepte hinter technischen Namen versteckt sind, wenn die Regeln verstreut sind, wenn die Ausnahmen nicht das Vokabular der Domäne tragen, dann wird die KI Schwierigkeiten haben.
Aber das ist keine neue Grenze.
Ein menschlicher Entwickler wird auch Schwierigkeiten haben.
Ein technisch versierter PM wird auch Schwierigkeiten haben.
Ein Team, das das Produkt weiterentwickeln will, wird auch Schwierigkeiten haben.
Code, der den Fachbereich nicht repräsentiert, ist kein guter Code. Er zwingt permanent zu einer Übersetzung zwischen dem Fachbedarf und der Software-Mechanik. Jede Weiterentwicklung erfordert, diese Verbindung gedanklich neu aufzubauen. Jedes Debugging wird teurer. Jede Regel wird schwerer zu finden.
Genau dafür gibt es seit langem Ansätze wie DDD. Die Idee entstand nicht mit der KI.
Die KI macht diese Anforderung schlicht sichtbarer.
Wenn man den Code als Produkt-Wahrheitsquelle befragen will, muss der Code die Sprache des Produkts sprechen.
Die Entitäten müssen die Namen des Fachbereichs tragen.
Die Aktionen müssen lesbar sein.
Die Ereignisse müssen erzählen, was passiert ist.
Die Ausnahmen müssen Regeln ausdrücken, nicht nur technische Fehler.
Die Richtlinien müssen die Kaskadenreaktionen sichtbar machen.
Die Module müssen eine vorhersehbare Struktur haben.
Eine Ausnahme wie GenehmigterArtikelNichtÄnderbar ist nicht nur eine Fehlermeldung. Es ist eine Geschäftsregel, in Code geschrieben.
Das ist die Art Code, der befragbar wird.
Nicht weil die KI magisch ist.
Sondern weil der Fachbereich bereits in dem Material vorhanden ist, das sie liest.
Von der punktuellen Antwort zur regenerierten Dokumentation
Eine Slack-Frage zu beantworten ist der erste Anwendungsfall.
Aber nicht der einzige.
Wenn man eine Produktfrage aus dem Code beantworten kann, kann man auch einen Teil der Produktdokumentation regenerieren.
Man kann eine Support-FAQ produzieren.
Einen lebenden Artikel über eine Funktionalität aktualisieren.
Einen Changelog generieren.
Aus dem aktuellen Produktzustand eine Spec rekonstruieren.
Eine zuverlässigere kommerzielle Dokumentation darüber produzieren, was versprochen werden kann oder nicht.
Die Logik ist immer dieselbe: Artefakte, die das tatsächliche Verhalten beschreiben, nicht manuell pflegen, wenn dieses Verhalten aus der Wahrheitsquelle rekonstruiert werden kann.
Specs verschwinden nicht vollständig.
Ihr Status ändert sich.
Vor der Produktion dienen sie dem Dialog.
Sie ermöglichen, zu diskutieren, zu erkunden, zu rahmen, zu entscheiden.
Nach der Produktion dürfen sie nicht mehr beanspruchen, die dauerhafte Wahrheit des Produkts zu sein.
Sie werden regenerierbar.
Das ist keine religiöse Regel
Man muss natürlich etwas Pragmatismus bewahren.
Nicht alle Unternehmen können das bis ins letzte Detail anwenden.
Manche haben eine schwere Dokumentationshistorie.
Manche haben ein schwieriges Legacy.
Manche haben starke regulatorische Beschränkungen.
Manche haben noch keine ausreichende technische Kultur.
Manche haben schlecht nachvollzogene Produktentscheidungen.
Manche können nicht dieselben Informationen allen Fachbereichen zugänglich machen.
Es geht also nicht darum zu sagen: Morgen früh, löscht eure gesamte Dokumentation.
Das wäre absurd.
Es geht darum, den Schwerpunkt zu verschieben.
Aufzuhören, die beschreibende Dokumentation als Wahrheitsquelle zu betrachten.
Aufzuhören, den PM zu bitten, manuell, immer wieder zu überprüfen, was das Produkt bereits tut.
Aufzuhören, Artefakte manuell zu pflegen, die mechanisch auseinanderdriften.
Und damit zu beginnen, ein System aufzubauen, wo Code, Entscheidungen, Kontexte und Quellen in Dialog treten.
Mehr als eine Produktmethode
Im Grunde ist die Produktfrage nur ein besonderer Fall.
Sie enthüllt eine umfassendere Transformation.
Lange Zeit bestand das Informationssystem des Unternehmens aus Datenbanken, Dokumentenbanken, Wikis, Tickets, Tabellen, Ordnern, Dokumenten.
Man suchte.
Man las.
Man kopierte.
Man aktualisierte.
Man vergaß.
Mit der KI kann man anfangen, etwas anderes zu tun.
Man kann mit dem Informationssystem in Dialog treten.
Man kann eine Frage stellen.
Man kann einen Beleg verlangen.
Man kann die nahe liegenden Ideen erkunden.
Man kann die Geschichte zurückverfolgen.
Man kann einen Widerspruch erkennen.
Man kann ein Artefakt regenerieren.
Die Produktfrage ist ein guter Einstiegspunkt, weil sie konkret ist. Sie kostet täglich Zeit. Sie unterbricht die Arbeit. Sie enthüllt die Divergenz zwischen Dokumentation und Produktion.
Aber dahinter liegt ein tieferes Thema.
Es geht nicht nur darum, den Support zu helfen, schneller zu antworten.
Es geht darum, das Unternehmen von seinen echten Quellen aus befragbar zu machen.
Und im Fall des Produkts ist die echte Quelle des Verhaltens der Code.
Weiterführendes
Code centric Product Decision Record: Produktentscheidungen dokumentieren, die das Unternehmen strukturieren KI-Wiki: warum ich eine KI-gepflegte Wissensbasis aufgebaut habe