Fast jeden Tag bekomme ich auf Slack die Produktfrage gestellt.

Keine abstrakte Frage. Kein großes Nachdenken über die Vision der nächsten fünf Jahre. Eine echte Frage aus der Praxis.

Geht das?

Was passiert, wenn der Kunde das Produkt so einstellt?

Wo liegt die Grenze?

Gilt diese Regel auch in diesem Fall?

Warum blockiert das Produkt an dieser Stelle?

Können wir dem Kunden das zusagen?

Ein Teil dieser Fragen ist strategisch. Sie verlangen ein Verständnis des Marktes, des Kunden, der Positionierung, der Richtung, die wir einschlagen wollen. Dann braucht es einen Product Manager. Dann braucht es Urteilsvermögen. Dann muss man manchmal nein sagen, manchmal abwägen, manchmal eine Richtung verantworten.

Viele Fragen sind aber von ganz anderer Art.

Sie betreffen das tatsächliche Verhalten des Produkts.

Eine Regel. Eine Grenze. Eine Ausnahme. Eine Einschränkung. Ein Anwendungsfall. Eine Konfiguration. Ein Zusammenspiel zweier Funktionen.

Und da müsste die Antwort eigentlich einfach sein.

Das Problem ist: Sie ist es nicht immer.

Die versteckten Kosten der Produktfrage

Wenn die Frage in die Tiefe geht, reicht es nicht, einfach die Dokumentation aufzuschlagen.

Erstens, weil es die Dokumentation nicht immer gibt.

Zweitens, weil es sie manchmal gibt, man aber nicht weiß, ob sie noch aktuell ist.

Und drittens, weil die eigentliche Frage oft einen Grenzfall betrifft, den niemand ausdrücklich festgehalten hat.

Also macht man das, was jeder PM, jeder CSM, jede Person im Support und jeder Entwickler im Zweifel macht: Man probiert es aus.

Man öffnet eine Testumgebung.

Man stellt sich Testdaten zusammen.

Man spielt das Szenario nach.

Man prüft, was das Produkt damit macht: blockieren, akzeptieren, rechnen, anzeigen, ausblenden, auslösen, verschicken, ablehnen.

Und eine halbe Stunde ist weg.

Manchmal eine ganze.

Manchmal mehr.

Diese Zeit taucht nirgends auf. Nicht in Jira. Nicht in der Roadmap. Nicht in den Schätzungen. Sie wird schlicht vom normalen Betrieb der Organisation geschluckt.

Dazu kommen Kosten, die noch unsichtbarer sind: der Kontextwechsel.

Die Frage kommt selten zum passenden Zeitpunkt. Sie kommt, weil ein Kunde wartet. Weil jemand aus dem Vertrieb gerade im Termin sitzt. Weil ein CSM einen Austausch vorbereitet. Weil der Support noch heute antworten muss.

Also unterbricht man, was man gerade tat. Man arbeitet sich in ein Thema ein. Man testet. Man antwortet. Und dann versucht man, dorthin zurückzufinden, wo man vorher war.

Das ist nicht nur verlorene Zeit. Das ist ein Bruch im Denken.

Und genau diese Art von Arbeit sollte die KI abnehmen.

Das Problem ist nicht die Frage. Es ist die Quelle.

Man könnte einwenden: Dann braucht es eben eine bessere Dokumentation.

In der Theorie: ja.

In der Praxis: nein.

Eine Produktdokumentation hinkt dem echten Produkt fast immer hinterher. Das ist kein Problem persönlicher Disziplin. Es liegt nicht nur daran, dass jemand vergessen hat, eine Seite nachzuziehen.

Es ist eher struktureller Natur.

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

Details werden nachjustiert.

Grenzfälle tauchen auf.

Während der Entwicklung fallen Entscheidungen.

Technische Zwänge erzwingen kleine Änderungen am Verhalten.

In einem Pull Request oder einem Merge Request wird diskutiert.

Abwägungen landen nicht immer in der ursprünglichen Dokumentation.

Das ist nicht zwangsläufig schlimm. Es ist sogar ziemlich normal. Ein lebendiges Produkt entsteht nicht wie ein festgeschriebenes Dokument.

Es hat aber eine schlichte Folge: Die Spec ist nicht die Wahrheit über das Produkt.

Sie ist eine Näherung, die zu einem bestimmten Zeitpunkt nützlich war.

Die Wahrheit ist das, was läuft.

Und was läuft, ist der Code.

Der Code als Quelle der Produktwahrheit

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.

Wer wissen will, wie sich das Produkt tatsächlich verhält, muss anschauen, was ausgeliefert wurde. Und was ausgeliefert wurde, steckt im Quellcode.

So gesagt kann das schroff klingen. Man könnte es lesen als: „Werft die ganze Dokumentation weg.“

Darum geht es nicht.

Die richtige Unterscheidung verläuft nicht zwischen „Code“ und „Dokumentation“.

Sie verläuft zwischen dem, was erklärt, und dem, was beschreibt.

Was erklärt, behalten wir.

Was beschreibt, generieren wir neu.

Die Kontexte müssen erhalten bleiben. Sie enthalten die Diskussionen, die Quellen, die Überlegungen, die Ideen, die zu einer Entscheidung geführt haben. Das sind wiederverwendbare Bausteine.

Die Entscheidungen müssen erhalten bleiben. Wenn ein Unternehmen eine Richtung wählt, muss das Warum festgehalten werden. Warum diese Wahl? Welche Alternativen wurden verworfen? Warum löst diese Entscheidung eine frühere ab?

Dafür sind die Product Decision Records da, die PDR. Darüber habe ich schon geschrieben: Ein PDR beschreibt kein Feature, es hält eine strukturierende Produktentscheidung fest.

Bestimmte Vorgaben müssen ebenfalls greifbar bleiben: vertragliche Zusagen, regulatorische Auflagen, externe Dokumente, besondere Verpflichtungen. 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 neu generiert werden.

Denn der Code ist die Wahrheit über das umgesetzte Verhalten.

Was die KI möglich macht

Bisher hatte diese Idee eine offensichtliche Grenze.

Code ist Code.

Für den Support ist er nicht immer lesbar. Für den Vertrieb nicht immer. Für das C-Level auch nicht immer. Und selbst ein PM tut sich schwer, vor allem ohne technischen Hintergrund.

Lange brauchte es deshalb eine Zwischenschicht. Specs. Unterlagen für den Support. Produktseiten. Changelogs. Tabellen. Schaubilder.

Die KI verändert diese Rechnung.

Sie kann die Schnittstelle zwischen einer fachlichen Frage und dem Quellcode werden.

Der Support kann fragen: „Was passiert, wenn der Kunde dieses Element nach der Freigabe storniert?“

Ein CSM kann fragen: „Unter welchen Bedingungen bleibt dieser Workflow hängen?“

Jemand aus dem Vertrieb kann fragen: „Können wir diesem Interessenten diese Konfiguration zusagen?“

Ein PM kann fragen: „Wo ist diese Regel umgesetzt, und welche Fälle sind nicht abgedeckt?“

Und die KI kann im Code nachsehen, in der Git-Historie, in den Merge Requests, in den Feature Flags, in den fachlichen Kontexten — und daraus eine verständliche Antwort bauen.

Keine magische Antwort.

Eine verankerte Antwort.

Eine gute Produktantwort muss ihre Belege zeigen

Hier liegt der entscheidende Punkt.

Antwortet die KI ohne Beleg, wird sie zu einer weiteren ungefähren Dokumentation. Schneller, eleganter, aber nicht unbedingt verlässlicher.

Man muss die KI also zwingen, ihre Antwort zu verankern.

Wenn sie behauptet, dass es eine Regel gibt, 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 dieser Merge Request dieses Verhalten eingeführt hat, weil dieser Test dieses Szenario abdeckt.“

Die Belege müssen nicht im Zentrum der Antwort stehen. Für den Support oder den Vertrieb können sie am Ende des Dokuments stehen. Nicht alle müssen die technischen Details lesen.

Aber es muss sie geben.

Ihre bloße Anwesenheit verändert das Verhalten der KI. Sie kann nicht mehr allein nach Plausibilität antworten. Sie muss ihre Aussagen an Tatsachen binden.

Es ist dieselbe Logik wie bei einer Textanalyse. Wenn ich eine KI ein Korpus auswerten lasse, ist mir lieber, sie nennt zu jeder Schlussfolgerung den Satz oder den Absatz, auf den sie sich stützt. Das begrenzt Halluzinationen erheblich.

Bei einer Produktfrage ist es genauso.

Der Beleg kann eine Datei sein.

Eine Funktion.

Eine Ausnahme.

Ein Test.

Ein Commit.

Ein Merge Request.

Ein Pull Request.

Ein Feature Flag.

Eine Produktentscheidung.

Eine fachliche Quelle.

Ohne das verschiebt man das Problem nur. Man ersetzt das lückenhafte Gedächtnis des PM durch das wahrscheinlichkeitsbasierte Gedächtnis eines Modells.

Das reicht nicht.

Man muss auch sagen, was man nicht weiß

Eine gute Produktantwort darf nicht nur antworten.

Sie muss auch sagen, wo sie nicht weiterkommt.

Das ist eine zentrale Direktive.

Die KI muss schreiben können:

„Ich habe keinen Test gefunden, der diesen Fall abdeckt.“

„Der Code zeigt zwei mögliche Verhaltensweisen, je nach Zustand des Feature Flags.“

„Ich kann das genaue Verhalten für diesen Kunden nicht bestimmen, ohne seine Konfiguration einzusehen.“

„Das PDR nennt eine Regel, der Code scheint aber etwas anderes umzusetzen.“

„Die aktuelle Support-Dokumentation widerspricht dem Verhalten, das im Code zu sehen ist.“

Das ist unangenehm, aber es ist wertvoll.

Ein seriöser Mensch macht es genauso. Wenn er etwas nicht weiß, sagt er es. Wenn er Zweifel hat, benennt er sie. Wenn er testen muss, testet er.

Es geht nicht darum, den Eindruck zu erwecken, die KI wüsste alles.

Es geht darum, den Aufwand fürs Suchen zu senken und zugleich die Nachvollziehbarkeit zu erhöhen.

Nicht alle brauchen dieselbe Lesart

Eine Produktfrage kann mehrere Fachbereiche betreffen.

Der Support will meist eine Antwort, die er dem Kunden direkt geben kann.

Der CSM will die Nutzung und die Auswirkungen verstehen.

Der Vertrieb will wissen, was er zusagen kann und welchen Nutzen er hervorheben soll.

Der PM will die Regel, die Grenze, die Ausnahme prüfen.

Die Geschäftsführung will vielleicht verstehen, was strategisch auf dem Spiel steht.

Man könnte also für jede Zielgruppe eine eigene Antwort entwerfen.

Nötig ist das aber nicht unbedingt.

Ein und dieselbe Antwort lässt sich in mehrere Blickwinkel gliedern. Ein kurzer Teil, der die Frage beantwortet. Ein Teil für den Support. Ein Teil zur Nutzung. Ein Teil zum Nutzen. Ein Teil zu den Grenzen. Ein Teil mit den Belegen.

Jeder liest das, was er braucht.

Und manchmal ist es gerade nützlich, dass jemand aus dem Vertrieb eine Produktgrenze sieht oder ein CSM den technischen Ursprung eines Verhaltens versteht. Das hängt von der Kultur des Unternehmens ab. Manche Organisationen halten Informationen lieber knapp. Andere gewinnen an Reife, indem sie sie teilen.

Das ist keine rein technische Frage.

Das ist eine Frage der Kultur.

Die nötigen Bausteine

Technisch reicht es nicht, ein LLM an ein Git-Repository zu hängen und zu hoffen, dass alles funktioniert.

Mehrere Werkzeuge ergänzen sich.

Das RAG findet die passenden Fragmente. Es ist oft sehr wirksam darin, aus einer großen Menge Dokumente oder aus umfangreichem Code die relevanten Stücke hervorzuholen.

Aber das RAG reicht nicht immer. Es findet. Es reist nicht unbedingt weiter.

Ein semantischer Graph hilft dabei, das Umfeld zu erkunden: verwandte Begriffe, benachbarte Module, verbundene Regeln, Ereignisse, die andere Ereignisse auslösen.

Das Durchgehen des Dateisystems bleibt ebenfalls unverzichtbar. Ist eine Zone erst einmal gefunden, muss man manchmal das Verzeichnis lesen, die benachbarten Dateien öffnen, die lokale Struktur verstehen. Das ist weniger elegant als eine Vektorsuche, aber oft sehr wirksam.

Git bringt eine weitere Dimension ins Spiel: die Zeit.

Der aktuelle Code sagt, was existiert. Die Historie sagt, wie man dorthin gekommen ist. Commits, Pull Requests oder Merge Requests können die Absicht offenlegen, die Diskussionen, die Kompromisse, die Korrekturen.

Feature Flags fügen noch eine Nuance hinzu. Der Code kann mehrere mögliche Verhaltensweisen enthalten. Welche davon tatsächlich greift, hängt dann vom Zustand des Flags ab.

Hat die KI keinen Zugriff auf diesen Zustand, muss sie bedingt antworten: Ist das Flag aktiv, gilt dieses Verhalten; ist es das nicht, ein anderes.

Hat sie Zugriff auf die Umgebung, kann sie weiter gehen: Für genau diesen Kunden, in genau dieser Konfiguration, ist dieses Verhalten aktiv.

Dieser Schritt ist wichtig. Die Produktfrage zielt nicht immer auf den Code im Abstrakten. Sie zielt manchmal auf das Produkt, so wie ein bestimmter Kunde es erlebt.

Die Bedingung: Code, der die Fachsprache spricht

Eine Grundbedingung gibt es allerdings.

Der Code muss den Fachbereich abbilden.

Ist der Code Spaghetticode, verstecken sich die fachlichen Begriffe hinter technischen Namen, liegen die Regeln verstreut, tragen die Ausnahmen nicht das Vokabular der Domäne, dann tut sich die KI schwer.

Aber das ist keine neue Grenze.

Ein menschlicher Entwickler tut sich ebenfalls schwer.

Ein technisch versierter PM tut sich ebenfalls schwer.

Ein Team, das das Produkt weiterentwickeln will, tut sich ebenfalls schwer.

Code, der den Fachbereich nicht abbildet, ist kein guter Code. Er erzwingt permanent eine Übersetzung zwischen dem fachlichen Bedarf und der Mechanik der Software. Jede Weiterentwicklung verlangt, diese Verbindung im Kopf neu aufzubauen. Jedes Debugging wird teurer. Jede Regel wird schwerer auffindbar.

Genau deshalb gibt es Ansätze wie DDD schon lange. Die Idee ist nicht mit der KI entstanden.

Die KI macht diesen Anspruch nur sichtbarer.

Wer den Code als Quelle der Produktwahrheit befragen will, braucht Code, der die Sprache des Produkts spricht.

Die Entitäten müssen die Namen des Fachbereichs tragen.

Die Aktionen müssen lesbar sein.

Die Ereignisse müssen erzählen, was geschehen ist.

Die Ausnahmen müssen Regeln ausdrücken, nicht nur technische Fehler.

Die Policies müssen die Kettenreaktionen sichtbar machen.

Die Module müssen eine vorhersehbare Struktur haben.

Eine Ausnahme wie ElementAnnuléNonModifiable ist nicht bloß eine Fehlermeldung. Sie ist eine fachliche Regel, in Code geschrieben.

Solcher Code wird befragbar.

Nicht weil die KI zaubert.

Sondern weil der Fachbereich bereits in dem Material steckt, das sie liest.

Von der einzelnen Antwort zur neu generierten Dokumentation

Eine Slack-Frage zu beantworten ist der erste Anwendungsfall.

Aber nicht der einzige.

Wenn sich eine Produktfrage aus dem Code beantworten lässt, lässt sich auch ein Teil der Produktdokumentation neu generieren.

Man kann eine Support-FAQ erzeugen.

Einen lebenden Artikel über eine Funktion nachziehen.

Ein Changelog generieren.

Eine Spec aus dem aktuellen Zustand des Produkts rekonstruieren.

Für den Vertrieb eine verlässlichere Unterlage darüber erstellen, was zugesagt werden kann und was nicht.

Die Logik bleibt immer dieselbe: keine Artefakte von Hand pflegen, die das tatsächliche Verhalten beschreiben, wenn sich dieses Verhalten aus der Quelle der Wahrheit rekonstruieren lässt.

Die Specs verschwinden nicht vollständig.

Sie wechseln den Status.

Vor der Produktion dienen sie dem Gespräch.

Mit ihnen lässt sich diskutieren, erkunden, abstecken, entscheiden.

Nach der Produktion dürfen sie nicht mehr beanspruchen, die dauerhafte Wahrheit über das Produkt zu sein.

Sie werden neu generierbar.

Das ist kein Glaubenssatz

Ein wenig Pragmatismus gehört natürlich dazu.

Nicht jedes Unternehmen kann das auf den Millimeter genau umsetzen.

Manche schleppen einen schweren Altbestand an Dokumentation mit.

Manche haben ein schwieriges Legacy.

Manche unterliegen strengen regulatorischen Auflagen.

Manchen fehlt noch die technische Kultur dafür.

Manche haben ihre Produktentscheidungen schlecht festgehalten.

Manche dürfen nicht allen Fachbereichen dieselben Informationen zeigen.

Es geht also nicht darum zu sagen: Löscht morgen früh eure gesamte Dokumentation.

Das wäre absurd.

Es geht darum, den Schwerpunkt zu verschieben.

Aufhören, die beschreibende Dokumentation als Quelle der Wahrheit zu betrachten.

Aufhören, den PM immer wieder von Hand prüfen zu lassen, was das Produkt längst tut.

Aufhören, von Hand Artefakte zu pflegen, die zwangsläufig auseinanderlaufen.

Und anfangen, ein System zu bauen, in dem der Code, die Entscheidungen, die Kontexte und die Quellen miteinander sprechen.

Mehr als eine Produktmethode

Im Grunde ist die Produktfrage nur ein Sonderfall.

Sie legt eine größere Verschiebung offen.

Lange bestand das Informationssystem eines Unternehmens aus Datenbanken, Dokumentenablagen, Wikis, Tickets, Tabellen, Ordnern, Dokumenten.

Man suchte darin.

Man las es.

Man schrieb es ab.

Man hielt es aktuell.

Man vergaß es.

Mit der KI lässt sich etwas anderes beginnen.

Man kann mit dem Informationssystem sprechen.

Man kann eine Frage stellen.

Man kann einen Beleg verlangen.

Man kann die verwandten Ideen erkunden.

Man kann die Historie zurückverfolgen.

Man kann einen Widerspruch aufdecken.

Man kann ein Artefakt neu generieren.

Die Produktfrage ist ein guter Einstieg, weil sie konkret ist. Sie kostet jeden Tag Zeit. Sie unterbricht die Arbeit. Sie legt offen, wie weit Dokumentation und Produktion auseinanderliegen.

Dahinter steckt aber ein tieferes Thema.

Es geht nicht nur darum, dem Support zu schnelleren Antworten zu verhelfen.

Es geht darum, das Unternehmen aus seinen echten Quellen heraus befragbar zu machen.

Und beim Produkt ist die echte Quelle des Verhaltens der Code.