Vom Organigramm zur Produktverantwortung

Diesen Beitrag anhören (13 Min.)

Ein KI-Assistent erzeugt einen Entwurf – und danach wartet der Vorgang auf Freigabe, Review und Release wie zuvor. Wer trägt ihn vom beobachteten Kundenproblem bis zur messbaren Wirkung? Diese Frage beantwortet keine noch so schnelle Entwurfserzeugung. KI kann den Arbeitsfluss vom ersten Kundensignal über Plan und Umsetzung bis zu Review und Wirkung durchgängiger machen – wenn die Verantwortung für Problem, Entscheidung, Prüfung und Wirkung an einer Stelle zusammengeführt wird.

KI beseitigt Organisationsgrenzen nicht automatisch. Sie senkt die Kosten, sich in den nächsten Schritt einzuarbeiten. Ob daraus ein zusammenhängender Vorgang wird oder nur ein schnellerer Zulauf auf dieselben Wartepunkte, entscheidet die Organisation, nicht das Modell.

Der Arbeitsfluss vom Kundenproblem bis zur Wirkung

Mit Arbeitsfluss meine ich hier eine konkrete Kette: Ein Kundensignal wird beobachtet, daraus entsteht eine Hypothese, aus der Hypothese ein Plan, aus dem Plan eine Umsetzung, aus der Umsetzung ein Review mit fachlicher Abnahme, danach ein Release und schließlich eine beobachtbare Wirkung, die wieder als Signal in den nächsten Durchlauf einfließt.

flowchart LR
    S[Kundensignal] --> H[Hypothese und Plan]
    H --> E[Entwurf und Umsetzung]
    E --> Q[Review und Abnahme]
    Q --> R[Release]
    R --> W[Wirkung beobachten]
    W --> S
    A[KI: Kontext, Varianten,<br/>Tests und Dokumentation] --> H
    A --> E
    A --> Q

Die Ausgangshypothese lautet, dass diese Kette in arbeitsteiligen Organisationen selten durchgängig ist: Ein Ticket beschreibt den Wunsch, ein anderer Mensch entscheidet über das Design, ein dritter baut die Schnittstelle, ein vierter prüft den Release. Jede Rolle kann ihre Aufgabe sehr gut erledigen, während das Ergebnis für den Kunden trotzdem unvollständig bleibt. Wer nur einen kleinen Ausschnitt sieht, kann kaum beurteilen, ob eine neue Funktion das Kundenproblem löst oder lediglich einen Teilprozess sauberer macht.

KI verändert an dieser Kette vor allem einen Kostenfaktor: das Einarbeiten in den jeweils nächsten Schritt. Ein Assistent kann einen unbekannten Service erklären, vorhandene Entscheidungen zusammentragen, einen Datenfluss skizzieren und passende Tests vorschlagen. Er ersetzt dabei kein Fachwissen. Er senkt die Hürde, Fachwissen aus anderen Teilen der Organisation rechtzeitig einzubeziehen – bevor eine Entscheidung getroffen ist, nicht nachdem eine fertige Lösung abgeliefert wurde.

Übergaben verkürzen sich nicht automatisch

Meine These ist: KI kann Übergaben verkürzen, wenn die Verantwortung für Problem, Entscheidung, Prüfung und Wirkung zusammengeführt wird. Das ist eine Hypothese über Organisation, kein nachgewiesenes Gesetz. Bleibt die Verantwortung verteilt wie zuvor, beschleunigt KI lediglich die Produktion von Zwischenständen, die weiterhin auf dieselben Freigaben warten.

Der Beitrag über schnellere Entwicklung und unveränderte Prozesse beschreibt diese Kehrseite: Wenn eine Organisation denselben alten Ablauf nur schneller füllt, verschiebt sich der Stau. Mehr Entwürfe warten auf dieselben Reviewer, und mehr Dokumente widersprechen sich. Der Gewinn entsteht erst, wenn die frei gewordene Zeit in das Verständnis des gesamten Vorgangs fließt.

Zusammengeführte Verantwortung bedeutet dabei nicht, dass ein Mensch gleichzeitig Produktmanager, Designer, Sicherheitsfachmann und Betriebsverantwortlicher sein muss. Gemeint ist, dass ein klar begrenzter Ausschnitt des Produkts von derselben Stelle weiterverfolgt wird: vom beobachteten Problem über eine Hypothese und eine Änderung bis zur Rückmeldung aus der Nutzung. Spezialdisziplinen bleiben unverzichtbar. Der Unterschied liegt im Zeitpunkt: Spezialisten werden früher und gezielter einbezogen, statt am Ende einer langen Kette eine fertige Lösung entgegenzunehmen.

Das Organigramm verschwindet dadurch nicht. Menschen brauchen klare Zuständigkeiten, Entwicklungsperspektiven und Entscheidungen, die nicht zwischen Teams verloren gehen. Aber der durchgängige Arbeitsfluss kann wichtiger werden als die Grenzen zwischen den Kästchen – dort, wo Verantwortung tatsächlich zusammengeführt ist.

Vertikale Schnitte als überprüfbare Hypothese

Vertikale Arbeitspakete machen diese These überprüfbar. Statt eine Änderung nach technischen Schichten zu zerlegen – zuerst Datenmodell, dann API, dann Oberfläche – wird ein kleiner, nutzbarer Ausschnitt durch alle Schichten geführt. Ein solcher Schnitt hat einen klaren Zweck, eine sichtbare Wirkung und eine überschaubare Zahl offener Entscheidungen.

Bereits ohne generative KI war diese Arbeitsweise sinnvoll. Ein möglicher Hinderungsgrund war der Aufwand, sich in fremde Teile des Systems einzuarbeiten: Ein Entwickler kannte etwa das Frontend, nicht die Regeln im Backend. Das Produktteam kannte die Wirkung für Anwender, nicht die Folgen für Betrieb oder Datenmodell. Also wurden Arbeitspakete entlang von Zuständigkeiten geschnitten und anschließend über viele Meetings wieder zusammengesetzt.

flowchart TD
    P[Produktproblem] --> V[Vertikaler Schnitt]
    V --> U[Oberfläche]
    V --> F[Fachlogik]
    V --> D[Daten und Verträge]
    V --> B[Betrieb und Beobachtung]
    U --> X[Ein überprüfbares Ergebnis]
    F --> X
    D --> X
    B --> X
    K[KI: Abhängigkeiten und<br/>Vorschläge sichtbar machen] --> V

Kleinere vertikale Schnitte sind eine überprüfbare Organisationshypothese, keine pauschale Aussage über jedes Team. Die Hypothese lautet, dass ein Team mit KI-Unterstützung mehr von diesem Zusammenhang selbst erkunden kann – welche Services betroffen sind, welche Verträge sich ändern, welche Testfälle fehlen, welche Dokumentation angepasst werden muss. Ob die Beobachtungen im konkreten Kontext für diese Hypothese sprechen, lässt sich anhand von Wartezeit, Zahl der Übergaben, Nacharbeit und Zeit bis zum Nutzerfeedback prüfen. Die Werte werden mit identischer Definition vor und nach einem begrenzten Piloten erhoben; andere Prozessänderungen müssen festgehalten werden, weil ein solcher Vergleich keine eindeutige Ursache beweist. Fällt die Messung anders aus als erwartet, ist die Hypothese für diesen Kontext zunächst nicht bestätigt, nicht das Team gescheitert.

Ein vertikaler Schnitt darf nicht zum Vorwand werden, jede Spezialdisziplin auf wenige Menschen abzuwälzen. Wo Sicherheit, Regulierung oder tiefe Fachkenntnis nötig sind, bleibt Zusammenarbeit Pflicht. Der Schnitt verändert die Reihenfolge der Beteiligung, nicht ihre Notwendigkeit.

Technologie wird wieder zur Option

Viele Technologiewahlen entstehen aus dem, was ein Team gerade kennt. Das ist verständlich: Eine unbekannte Plattform verlangt Recherche, kleine Versuche und die Sorge, später allein damit dazustehen. Darum werden Anforderungen gelegentlich an die vorhandenen Werkzeuge angepasst, obwohl ein anderer Weg besser passen könnte.

KI verändert diese Rechnung. Sie kann Dokumentation durchsuchen, Beispiele aus einem Repository erklären, Varianten gegenüberstellen und einen kleinen Prototypen vorbereiten. Aus einer unbekannten Technologie wird dadurch noch keine gute Entscheidung. Aber es wird günstiger, die Entscheidung auf Basis eines echten Versuchs zu treffen statt auf Basis der Gewohnheit.

Eine brauchbare Untersuchung hält dabei mehrere Möglichkeiten offen:

Was ist die kleinste Änderung, mit der wir etwas über das Kundenproblem lernen?
Welche vorhandenen Systeme, Daten und Verträge müssen wir wirklich verstehen?
Welche Annahme übernimmt die KI, und wie lässt sie sich prüfen?
Welche Wirkung erwarten wir nach dem Release, und woran merken wir das Gegenteil?

Die Antworten müssen nicht immer wie eine Architekturentscheidung dokumentiert werden. Bei einer kleinen Änderung reicht oft ein sauberer Pull Request mit Tests und einer kurzen Begründung. Entscheidend ist, dass die KI nicht bloß mehr Optionen produziert, sondern hilft, Optionen schneller zu bewerten und schlechte Ideen früher zu verwerfen.

Erstellen wird billiger, Review und Abnahme werden wichtiger

Das sichtbarste Ergebnis von KI ist oft ein Entwurf: Code, ein Test, eine Zusammenfassung, eine API-Beschreibung, ein Release-Hinweis. Der Entwurf kann erstaunlich gut sein. Er kann aber auch eine falsche Voraussetzung mit großer Überzeugung weitertragen. Je günstiger das Erstellen wird, desto stärker wächst deshalb der Wert von Review und fachlicher Abnahme.

Review meint hier mehr als den Pull Request. Es umfasst die fachliche Prüfung einer Anforderung, den Blick auf Widersprüche im vorhandenen Wissen, den Test unter realistischen Bedingungen und die Frage, ob der Release das Produkt verbessert. Qualitätssicherung ist damit kein letztes Tor vor dem Ausrollen. Sie begleitet den gesamten Schnitt.

review_focus:
  product_question: "Does this solve the observed customer problem?"
  domain_question: "Which business rule could make this wrong?"
  technical_question: "Which contract or dependency can break?"
  quality_signal: "What evidence would change our decision?"
  release_check: "Can we observe the result and recover safely?"

Dieses Beispiel ist keine neue Checkliste für jede Kleinigkeit. Es zeigt die Verschiebung: Bei KI-gestützten Entwürfen kann sich der Engpass von der Erzeugung zur Prüfung verschieben. Wichtiger wird dann, schnell und zuverlässig zu entscheiden, was von einem Entwurf behalten, geändert oder verworfen werden muss.

Die NBER-Studie „Generative AI at Work“ liefert dazu einen begrenzten empirischen Hinweis. Bei mehr als 5.000 Beschäftigten im Kundensupport erhöhte ein KI-Assistent die Zahl gelöster Fälle pro Stunde im Mittel um 14 Prozent, wobei weniger erfahrene Beschäftigte besonders profitierten. Diesen Befund zu den weniger erfahrenen Beschäftigten lese ich als Hinweis darauf, dass KI bewährte Vorgehensweisen verbreiten kann – das ist meine Interpretation, kein direkter Studienbefund. Ein Beleg für dieselbe Wirkung in jeder Aufgabe oder gar in der Produktentwicklung ist die Studie ohnehin nicht. Für die Produktarbeit bleibt daraus vor allem: Der erste Entwurf wird zugänglicher. Erfahrung entwertet das nicht. Erfahrung wird sichtbarer dort, wo sie zählt – bei der Auswahl einer Richtung, beim Erkennen eines untypischen Falls und beim Urteil über Qualität.

Verantwortung technisch verankern

Wenn diese These ernst gemeint ist – zusammengeführte Verantwortung für Problem, Entscheidung, Prüfung und Wirkung –, dann muss sie sich auch in den Systemen wiederfinden, durch die Arbeit fließt. Sonst bleibt sie ein Vorsatz. Zwei versionierte Implementierungsbeispiele zeigen, wie eine solche Verankerung aussehen kann; geprüft am 17. August 2026 gegen den jeweils verlinkten Repository-Stand.

WorkKit führt HTTP, MCP, A2A, Webhooks und Chat in denselben Planungspfad und bindet Ausführung an explizite Work-Order-Autorität, Budgets, Verträge, Evidenz und Review. Das ist die technische Form dieser Verantwortungsbündelung: Egal über welchen Kanal ein Auftrag eintrifft, er läuft durch dieselbe Planung, und die Ausführung ist an explizite Work-Order-Autorität gebunden.

SubKit modelliert wiederkehrende Arbeit über mehrere Systeme als genehmigten, protokollierten Workflow und hält Schritte mit Außenwirkung bis zur Bestätigung zurück. Auch hier trennt das Design Vorbereitung und Ausführung von der bestätigten Außenwirkung: Ein Vorgang darf vorbereitet, geprüft und wiederholt werden, aber der Schritt, der nach außen wirkt, wartet auf die Abnahme.

Die Übertragung auf die Organisation ist eine Hypothese, keine Garantie. Wenn Wissen auffindbar ist, wenn Releases so vorbereitet sind, dass ein Team eine Änderung kontrolliert bis zur Wirkung verfolgen kann, und wenn Produkt- und Serviceinformationen aus denselben geprüften Quellen entstehen statt in getrennten Kopien zu altern – dann kann ein Vorgang mehr Lücken auf einmal schließen: Eine Produktänderung liefert zugleich Testfälle, Betriebsinformationen und einen Entwurf für die Kundendokumentation. Wiederkehrende Supportfragen zeigen früh, welche Produktregel oder Erklärung fehlt. Fehler und Rückfragen fließen zurück in Regeln, Tests und spätere Arbeitspakete. Ob diese Bedingungen erfüllt sind, muss jede Organisation an ihrem eigenen Arbeitsfluss prüfen.

Ein vollständiger Schnitt als Test

Die Veränderung beginnt nicht mit einem neuen Organigramm. Sie beginnt mit einem echten, begrenzten Produktproblem. Ein Team nimmt einen Vorgang, der heute mehrere Übergaben hat, und führt ihn einmal vollständig durch: Kundenfrage verstehen, Annahme prüfen, Änderung bauen, Qualität bewerten, veröffentlichen und die Wirkung ansehen.

vertical_slice:
  customer_problem: "Describe the observed problem"
  smallest_change: "Deliver one useful outcome"
  ai_support:
    - "Find relevant context"
    - "Prepare tests and documentation"
  human_review:
    - "Validate domain assumptions"
    - "Accept quality and release risk"
  outcome_signal: "Measure customer use and failures"

Danach ist die Diskussion über Rollen und Struktur konkreter. Vielleicht zeigt sich, dass ein Team eine Schnittstelle selbst verantworten kann. Möglicherweise fehlt eine gemeinsame Wissensquelle. Oder ein Spezialist bleibt dauerhaft Teil des Ablaufs. Entscheidend ist, dass die Organisation aus beobachteter Arbeit lernt und nicht aus einem abstrakten Umbauplan – und dass sie die Hypothese verwirft, wo die Messung dagegen spricht.

KI macht vollständige Produktentwicklung nicht einfach. Sie macht sie dort öfter möglich, wo Verantwortung, Review und Wirkung zusammengehören und nicht über viele Stationen verteilt sind. Recherche, Entwurf, Tests, Dokumentation und Release-Vorbereitung rücken näher zusammen. Das Organigramm bleibt. Aber die Entscheidung, die jede Organisation jetzt treffen kann, ist konkret: einen ausgewählten, begrenzten Arbeitsfluss einmal durchgängig verantworten und an seiner Wirkung messen, ob die Hypothese trägt.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare