Lange habe ich im Deliverable das eigentliche Ergebnis der Arbeit gesehen.

Ein Dokument ist fertig. Eine Präsentation ist verschickt. Eine Spec ist geteilt. Ein Artikel ist veröffentlicht. Ein Lastenheft ist beantwortet und beim Kunden.

Es ist etwas entstanden.

Also wirkt die Arbeit erledigt.

Aber je länger ich KI mit Kontexten einsetze, desto unvollständiger kommt mir diese Selbstverständlichkeit vor.

Das Deliverable ist sichtbar.

Es ist notwendig.

Aber es ist nicht immer das eigentliche Kapital.

Das fertige Dokument verbraucht Denkarbeit

Ein Deliverable entsteht für einen Zweck.

Es richtet sich nach einer Zielgruppe, einem Moment, einer Formvorgabe. Eine Spec spricht zu Entwicklern. Ein Pitch spricht zu einem CPO. Eine Support-Dokumentation spricht zu einem Team, das schnell antworten muss. Ein Artikel spricht zu Lesern, die das Thema noch nicht kennen. Ein Lastenheft spricht zu einem Kunden mit seinen eigenen Feldern, seiner Nummerierung, seinem Vokabular.

Jedes Deliverable wählt aus dem Material aus, vereinfacht, formuliert um und ordnet es für einen genauen Bedarf.

Das ist normal. Das ist sogar seine Aufgabe.

Nur hat diese Aufbereitung ihren Preis: ein Teil des Denkens, aus dem das Deliverable hervorgegangen ist, verschwindet dahinter.

Man sieht das fertige Dokument.

Man sieht nicht mehr zwangsläufig die Quellen, das Zögern, die verworfenen Alternativen, die nicht übernommenen Beispiele, die Zwischenentscheidungen, die Widersprüche, die Nuancen, die man im Kopf behalten hat, aber nicht in der verschickten Fassung.

Das Deliverable trägt das Ergebnis.

Es trägt nicht unbedingt die Überlegung.

Das Problem beginnt beim zweiten Deliverable

Solange nur ein Output entstehen muss, bleibt dieses Problem unauffällig.

Man arbeitet an einem Material. Man schreibt ein Dokument. Man verschickt es. Ende.

Im echten Leben muss derselbe Inhalt aber oft mehrfach dienen.

Aus demselben Material entsteht vielleicht noch:

• eine fachliche Spec;
• User Stories;
• ein Pitch für die Geschäftsleitung;
• eine Notiz für den Vertrieb;
• eine Support-Dokumentation;
• ein Testplan;
• eine Antwort auf ein Lastenheft;
• ein Artikel;
• eine kurze Zusammenfassung für ein Meeting.

In einem klassischen Workflow fühlt sich jedes neue Format an wie ein Neuanfang.

Man öffnet das vorige Dokument. Man kopiert. Man formuliert um. Man streicht, was die neue Zielgruppe nicht anspricht. Man ergänzt, was fehlt. Manchmal geht eine Nuance verloren. Und zwei Versionen beginnen auseinanderzudriften.

Das ist nicht nur lästig.

Das ist gefährlich.

Der Support bekommt womöglich eine andere Erklärung als der Vertrieb. In der Spec kann eine Annahme stehen, die im Pitch nicht mehr auftaucht. Das Lastenheft kann auf eine alte Formulierung zurückgreifen, die nicht mehr stimmt. Der Artikel kann eine wichtige Unterscheidung verwischen, weil das verfügbare Material schon zu stark auf eine Zielgruppe hin zugeschnitten ist.

Das Problem ist nicht, mehrere Dokumente zu produzieren.

Das Problem ist, ein Deliverable zur Hauptquelle des nächsten Deliverables zu machen.

Ein Output ist keine Quelle der Wahrheit

Ein fertiges Dokument ist ein Output.

Es kann sehr gut sein.

Aber es wurde für einen bestimmten Verwendungskontext geschrieben.

Es enthält also Entscheidungen, die nicht immer zum Wissen selbst gehören: den Ton, die Detailtiefe, die Beispiele, die Reihenfolge, das Maß an Vorsicht, die Art, die Dinge zu benennen, das, was man zeigt und was nicht, das, was man als bekannt voraussetzt.

Wer von diesem Dokument aus alles Weitere produziert, erbt seine Entscheidungen.

Manchmal ist das nützlich.

Oft engt es ein.

Ein Satz, der einen Kunden beruhigen soll, ist nicht unbedingt eine gute Grundlage für eine interne Dokumentation. Eine Folie für die Geschäftsleitung ist keine gute Grundlage für eine User Story. Eine kurze Antwort in einer Tabelle ist keine gute Grundlage, um eine Produktentscheidung zu verstehen.

Das Deliverable ist ausgerichtet.

Das Arbeitswissen sollte neutraler bleiben.

Die Welt der Ideen

Deshalb halte ich es für sinnvoll, zwischen die Quellen und die Deliverables eine Schicht zu legen.

Ich nenne sie die Welt der Ideen.

Das ist kein besonders technischer Name.

Aber er sagt gut, was sie leisten soll.

Die Welt der Ideen sammelt das, was verstanden wurde, bevor es für eine bestimmte Zielgruppe umgeformt wird.

Darin finden sich etwa:

• atomare Notizen;
• thematische Notizen;
• Definitionen;
• Annahmen;
• Widersprüche;
• Entscheidungen;
• Beispiele;
• Grenzen;
• Beziehungen zwischen Ideen;
• offene Punkte zum Prüfen.

Dieses Material spricht noch nicht zu einem Kunden, einem Entwickler oder einem Leser.

Es spricht zur Arbeit selbst.

Es muss nicht elegant sein.

Es muss wiederverwendbar sein.

Eine Notiz darf kein Aufhänger werden

Dieser Punkt ist heikler, als er aussieht.

Beim Schreiben eines Artikels will man eine Idee am liebsten direkt in einen Satz verwandeln.

Beim Vorbereiten einer Präsentation will man sie direkt in einen Folienpunkt verwandeln.

Beim Schreiben einer Spec will man sie direkt in eine Anforderung verwandeln.

Nur wird die Notiz dann schon zu einem Stück des Deliverables.

Sie verliert ihre Neutralität.

Eine gute Notiz muss das Wissen auf einer Ebene halten, auf der es sich später anders ausdrücken lässt.

Sie darf eine Unterscheidung enthalten, einen Beleg, eine Annahme, eine Abwägung, eine Nuance. Aber sie darf nicht gefangen sein im Artikel, in der Folie oder in der Spec von heute.

Der build dient dem Produzieren.

Die Notiz dient dem Bewahren dessen, woraus sich später etwas produzieren lässt.

Der Unterschied wirkt klein.

Er ändert alles, wenn man drei Wochen später zurückkommt.

Die KI macht diese Trennung sehr viel nützlicher

Vor der KI konnte diese Zwischenschicht schwerfällig wirken.

Man konnte schon damals saubere Notizen machen, Quellen sichern, Zusammenfassungen anlegen. Aber daraus mehrere Deliverables zu bauen, blieb erhebliche Handarbeit.

Mit der KI zahlt sich diese Trennung sehr viel stärker aus.

Ist das Material gut organisiert, kann die KI beim Neuzusammensetzen helfen.

Sie kann eine lange Fassung erzeugen, eine kurze, eine vertriebliche, eine technische, eine vorsichtige, eine erklärende.

Sie kann dasselbe Wissen an mehrere Zielgruppen anpassen.

Aber damit das sauber gelingt, muss sie von der richtigen Schicht ausgehen.

Nicht nur vom zuletzt verschickten Dokument.

Nicht nur von einem Chat.

Nicht nur von einem fertigen PDF.

Sie muss zurück können zu den Quellen, den Notizen, den Entscheidungen, den Grenzen, den noch offenen Punkten.

Dann ändert die Arbeit ihren Charakter.

Man produziert nicht mehr nur ein Dokument.

Man baut ein Material, aus dem sich etwas produzieren lässt.

Das Kapital ist das, was nach dem Output bleibt

Eine gute Frage nach jedem Deliverable ist einfach:

was bleibt?

Nicht nur: wo liegt die Datei?

Sondern:

• welche Ideen sind stabil geworden?
• welche Quellen tragen diese Ideen?
• welche Entscheidungen sind gefallen?
• welche Alternativen wurden verworfen?
• welche Formulierungen haben sich bewährt?
• welche Punkte bleiben wackelig?
• welche Bausteine können einer anderen Zielgruppe dienen?

Lautet die Antwort „nichts außer dem fertigen Dokument“, dann ist ein großer Teil der Arbeit verbraucht worden.

Das Deliverable ist entstanden.

Das Kapital nicht.

Bleiben dagegen Notizen zurück, verknüpfte Quellen, Entscheidungen, offene Fragen, erprobte Formulierungen, Angaben zur Verlässlichkeit, dann fängt das nächste Deliverable nicht bei null an.

Das sichtbare Ergebnis ist das Dokument.

Das Kapital ist die Fähigkeit, es neu zu machen, anzupassen, zu erklären, zu verteidigen und weiterzuführen.

Das verändert die Art zu arbeiten

Die Idee kann abstrakt klingen.

In einer Arbeitswoche wird sie sehr konkret.

Ein Nutzerinterview dient nicht nur dazu, ein Protokoll zu schreiben. Es kann in eine Produktnotiz einfließen, in eine Entscheidung, eine Annahme, ein Beispiel für eine spätere Präsentation.

Ein Lastenheft dient nicht nur dazu, einem Interessenten zu antworten. Es kann ein Gedächtnis für wiederkehrende Fragen anreichern, für geprüfte Antworten, für Belege und für Grenzen dessen, was gesagt werden darf.

Ein Artikel dient nicht nur dazu, einen Gedanken zu veröffentlichen. Er kann Ideen festigen, die später ein Buch tragen, eine Schulung, eine Methode, ein Produktgespräch.

Eine Spec dient nicht nur dazu, eine Funktion zu bauen. Sie kann festhalten, welche Abwägungen getroffen wurden, damit sich sechs Monate später verstehen lässt, warum das Produkt so funktioniert.

In all diesen Fällen ist das Deliverable nicht nutzlos.

Es bleibt unverzichtbar.

Aber es wird zu einem Output unter mehreren.

Es schöpft den Wert der Arbeit nicht mehr aus.

Das richtige Dokument an der richtigen Stelle

Ich glaube nicht, dass man Deliverables geringschätzen sollte.

Im Gegenteil.

Ein gutes Deliverable ist oft das, was die Arbeit übertragbar macht. Es zwingt zum Klären, zum Auswählen, zum Streichen, zum Formulieren. Es bringt das Denken in Kontakt mit einer echten Zielgruppe.

Aber man sollte aufhören, von ihm zu verlangen, dass es alles trägt.

Das fertige Dokument muss nicht sämtliche Quellen enthalten.

Es muss nicht alle Alternativen aufbewahren.

Es muss nicht jede Unsicherheit offenlegen.

Es muss nicht zum vollständigen Gedächtnis des Themas werden.

Es soll seine Arbeit als Deliverable tun.

Und das Gedächtnis der Arbeit muss woanders liegen.

Genau das leistet ein Kontext.

Der Kontext bewahrt das Material.

Der build erzeugt die Outputs.

Der Mensch behält das Urteil.

Die KI hilft beim Neuzusammensetzen.

Die Verschiebung des Werts

Diese Verschiebung halte ich für wichtig.

Früher haben wir vor allem aus Dokumenten Kapital aufgebaut.

Wir haben die Specs behalten, die Präsentationen, die Meeting-Notizen, die Protokolle, die verschickten Lastenhefte.

Künftig wird es eher darum gehen, aus dem Material Kapital aufzubauen, mit dem sich diese Dokumente produzieren lassen.

Das ist nicht dasselbe.

Aus einem Deliverable Kapital aufzubauen heißt, eine vergangene Form aufzubewahren.

Aus einem Kontext Kapital aufzubauen heißt, eine künftige Fähigkeit aufzubewahren.

Das Deliverable sagt: das hier haben wir verschickt.

Der Kontext sagt: das hier haben wir verstanden, entschieden, geprüft, verworfen — und das hier können wir daraus noch produzieren.

Deshalb ist das Deliverable nicht mehr das wichtigste Kapital.

Es bleibt der sichtbare Teil.

Aber der dauerhafte Wert verschiebt sich zu dem, was es erlaubt, mehrfach zu produzieren, ohne den Inhalt zu verlieren.

Das Dokument geht raus.

Das geordnete Denken bleibt.