Vom Organigramm zur Produktverantwortung

Wenn eine Idee schneller zu einem getesteten Produkt werden kann, verändert sich nicht nur die Geschwindigkeit der Softwareentwicklung. Es verändert sich, wer einen vollständigen Teil des Problems bearbeiten kann. Genau darin liegt für mich die spannendste Wirkung von KI: Ein Mensch oder ein kleines Team kann wieder mehr vom ersten Kundensignal bis zur Wirkung im Produkt verantworten.

Das ist keine Behauptung, dass große Teams überflüssig werden. Komplexe Produkte brauchen weiterhin Fachwissen, Betrieb, Sicherheit, Design und Entscheidungen an vielen Stellen. Aber die Größe eines Arbeitspakets wird neu verhandelbar. Was früher mehrere Übergaben brauchte – Recherche, fachliche Klärung, Entwurf, Implementierung, Tests, Dokumentation und Release-Vorbereitung – kann deutlich öfter als zusammenhängender Vorgang bearbeitet werden.

Mir ist in den letzten Monaten aufgefallen, wie stark sich dadurch die Rolle des Programmierens verschiebt. Der Code bleibt wichtig. Er ist aber immer seltener der Engpass. Wenn ein Assistent Bibliotheken erklärt, Beispiele findet, Tests vorbereitet und einen ersten Entwurf schreibt, wird Technologie mehr und mehr zum Werkzeug für eine Anforderung. Der Schwerpunkt wandert zu der Frage, ob die Anforderung verstanden wurde, ob die Lösung zum Produkt passt und woran wir ihre Qualität erkennen.

Vom Code zur vollständigen Produktarbeit

Ein Programmierer konnte immer schon über den eigenen Code hinausdenken. Im Alltag begrenzen jedoch Übergaben den Blick: 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.

KI verringert vor allem die Kosten, sich in den nächsten Schritt einzuarbeiten. Sie kann einen unbekannten Service erklären, vorhandene Entscheidungen zusammentragen, einen Datenfluss skizzieren und passende Tests vorschlagen. Sie ersetzt dabei kein Fachwissen. Sie senkt die Hürde, Fachwissen aus anderen Teilen der Organisation rechtzeitig einzubeziehen.

Dadurch wird aus der Rolle des Softwareentwicklers häufiger Produktarbeit im engeren Sinn. Gemeint ist nicht, dass jeder Mensch gleichzeitig Produktmanager, Designer, Sicherheitsfachmann und Betriebsverantwortlicher sein muss. Gemeint ist, dass ein Mensch einen klar begrenzten Ausschnitt des Produkts weiter verfolgen kann: vom beobachteten Problem über eine Hypothese und eine Änderung bis zur Rückmeldung aus der Nutzung.

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

Dieses Ende-zu-Ende-Denken ist kein neues Managementwort. Es ist die Voraussetzung dafür, Lücken zu erkennen. Wer nur einen kleinen Ausschnitt sieht, kann kaum beurteilen, ob die neue Funktion das Kundenproblem löst oder lediglich einen Teilprozess sauberer macht. Wer den gesamten Weg verfolgt, sieht eher, wo Wissen fehlt, wo ein Release hängen bleibt oder wo das Produkt eine neue Erklärung braucht.

Vertikale Schnitte werden wertvoller

Der praktische Hebel dafür sind vertikale Arbeitspakete. 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.

Vor KI war diese Arbeitsweise schon sinnvoll. Sie scheiterte aber oft an der Zeit, die es kostete, in fremde Teile des Systems einzusteigen. Ein Entwickler kannte das Frontend, nicht aber die Regeln im Backend. Das Produktteam kannte den Kundennutzen, nicht die Folgen für Betrieb oder Datenmodell. Also wurden Arbeitspakete entlang von Zuständigkeiten geschnitten und anschließend über viele Meetings wieder zusammengesetzt.

Mit KI kann ein kleineres Team mehr von diesem Zusammenhang selbst erkunden. Es lässt sich schneller prüfen, welche Services betroffen sind, welche Verträge sich ändern, welche Testfälle fehlen und welche Dokumentation angepasst werden muss. Das macht eine Änderung nicht automatisch richtig. Es ermöglicht aber, die richtigen Fragen früher zu stellen und sie im selben Vorgang zu beantworten.

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

Die Organisation wird dadurch nicht flach im Sinne von führungslos. Das Organigramm bleibt: Menschen brauchen klare Verantwortung, Entwicklungsperspektiven und Entscheidungen, die nicht zwischen Teams verloren gehen. Es kann aber schmaler werden. Weniger Übergaben bedeuten weniger künstliche Zwischenstationen. Ein Team muss nicht für jeden kleinen Schnitt mehrere andere Teams beauftragen, wenn es die nötigen Informationen, Werkzeuge und Leitplanken besitzt.

Das ist zugleich eine Grenze der Idee. Ein vertikaler Schnitt darf nicht zum Vorwand werden, jede Spezialdisziplin auf wenige Menschen abzuwälzen. Dort, wo Sicherheit, Regulierung oder tiefe Fachkenntnis nötig sind, bleibt Zusammenarbeit unverzichtbar. Der Unterschied ist: Spezialisten werden früher und gezielter einbezogen, statt am Ende einer langen Kette eine fertige Lösung entgegenzunehmen.

KI macht Technologie wieder zur Option

Viele Technologiewahlen entstehen aus dem, was ein Team gerade kennt. Das ist verständlich. Eine unbekannte Plattform, Bibliothek oder Schnittstelle 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. Sie macht aus einer unbekannten Technologie noch keine gute Entscheidung. Aber sie macht es günstiger, die Entscheidung auf Basis eines echten Versuchs zu treffen.

Das erweitert den Lösungsraum. Für eine Anforderung können Teams schneller prüfen, ob eine bestehende Komponente genügt, ob eine API eine Lücke schließt oder ob ein kleines neues Modul sinnvoller ist. Der Blick wandert vom Erstellen einzelner Dateien zur Frage: Welche Kombination aus Produktregel, Technik und Arbeitsablauf löst dieses Kundenproblem dauerhaft?

Eine gute 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 dokumentiert werden wie eine Architekturentscheidung. Bei einer kleinen Änderung reicht oft ein sauberer Pull Request mit Tests und einer kurzen Begründung. Wichtig ist, dass die KI nicht bloß mehr Optionen produziert. Sie soll helfen, Optionen schneller zu bewerten und schlechte Ideen früher zu verwerfen.

Erstellen wird billiger, Review wird wichtiger

Das sichtbarste Ergebnis von KI ist oft ein Entwurf: Code, ein Test, eine Zusammenfassung, eine API-Beschreibung oder 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 des Reviews.

Das 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 wird nicht zum letzten 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: Der Engpass ist nicht länger, eine erste Version zu erzeugen. Der Engpass ist, schnell und zuverlässig zu entscheiden, was davon behalten, ändern oder verwerfen werden muss.

Die Studie „Generative AI at Work“ des amerikanischen Forschungsnetzwerks NBER passt dazu. 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. Besonders stark profitierten weniger erfahrene Beschäftigte. Das ist ein Hinweis darauf, dass KI bewährte Vorgehensweisen verbreiten kann. Es ist kein Beleg dafür, dass sie in jeder Aufgabe dieselbe Wirkung erzielt.

Für Produktentwicklung heißt das: Der erste Entwurf wird leichter zugänglich. Das entwertet Erfahrung nicht. Erfahrung wird sichtbarer dort, wo sie zählt – bei der Auswahl einer Richtung, beim Erkennen eines untypischen Falls, beim Abwägen von Folgen und beim Urteil über Qualität.

Was sich für Organisationen ändern kann

Wenn kleine Gruppen größere Teile des Wegs vom Kundenproblem bis zur Wirkung bearbeiten, verändern sich auch Organisationen. Wissen muss auffindbar sein, damit nicht jede Anfrage bei derselben Person endet. Releases müssen so vorbereitet sein, dass ein Team eine Änderung kontrolliert bis zur Wirkung verfolgen kann. Produkt- und Serviceinformationen dürfen nicht in voneinander getrennten Kopien stehen, wenn sie durch denselben Vorgang aktualisiert werden sollten.

Hier liegt eine große Chance für Wissensmanagement. KI kann bestehende Regeln, Entscheidungen, Handbücher und Tickets schneller zusammenführen. Der eigentliche Fortschritt entsteht, wenn die Organisation diese Informationen so pflegt, dass sie überprüfbar bleiben. Ein Assistent darf aus bestätigtem Wissen Release Notes, Hilfetexte und technische Hinweise vorbereiten. Menschen prüfen anschließend, ob daraus für Kunden, Betrieb und Entwicklung wirklich dieselbe Aussage folgt.

Das kann viele kleine Lücken 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.
• Ein Release wird nicht nur als technische Auslieferung verstanden, sondern als Beginn einer beobachtbaren Produktwirkung.
• Fehler und Rückfragen fließen zurück in Regeln, Tests und spätere Arbeitspakete.

Der bestehende Beitrag über schnellere Entwicklung und unveränderte Prozesse beschreibt die Kehrseite: Wenn Organisationen denselben alten Ablauf nur schneller füllen, verschiebt sich der Stau. Mehr Entwürfe warten dann auf dieselben Freigaben, und mehr Dokumente widersprechen sich. Der Gewinn entsteht erst, wenn ein Team die frei gewordene Zeit nutzt, um den gesamten Vorgang besser zu verstehen.

Der Arbeitsmarkt wird breiter und anspruchsvoller

Ich erwarte nicht, dass die Bezeichnung Softwareentwickler verschwindet. Sie beschreibt weiterhin ein wichtiges Handwerk. Aber die Grenzen zwischen Entwickeln, Analysieren, Testen, Dokumentieren und Produktdenken werden durchlässiger. Wer diese Verbindung herstellen kann, wird mehr Einfluss auf ein vollständiges Ergebnis haben.

Das schafft Chancen, stellt aber auch höhere Anforderungen. Es reicht weniger, ein Werkzeug bedienen zu können. Wichtig werden Fachdomäne, die Fähigkeit zum klaren Problemzuschnitt, Qualitätsbewusstsein und die Bereitschaft, Ergebnisse nach dem Release weiterzuverfolgen. KI kann fehlendes Wissen schneller zugänglich machen. Sie nimmt niemandem die Verantwortung ab, dieses Wissen richtig einzuordnen.

Für Menschen am Anfang ihrer Laufbahn ist das besonders wichtig. Viele typische Einstiegsaufgaben werden schneller vorbereitet oder teilweise automatisiert. Organisationen müssen deshalb Lernwege bewusster gestalten: nicht nur kleine Zuarbeit verteilen, sondern Zugang zu fachlichen Entscheidungen, Reviews und vollständigen Produktzyklen schaffen. Sonst fehlt später genau die Erfahrung, die eine KI nicht aus einem Prompt erzeugt.

Für erfahrene Entwickler liegt die Chance darin, das eigene Handwerk breiter einzusetzen. Weniger Zeit für mechanisches Übertragen kann mehr Zeit für die Produktfrage bedeuten: Welches Problem lösen wir? Welche Vereinfachung ist für den Kunden tatsächlich besser? Wo sind wir sicher genug, um auszuliefern, und wo brauchen wir noch einen Versuch?

Ein kleiner vollständiger Schnitt ist der Anfang

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 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. Vielleicht fehlt eine gemeinsame Wissensquelle. Vielleicht bleibt ein Spezialist dauerhaft Teil des Ablaufs. Entscheidend ist, dass die Organisation aus beobachteter Arbeit lernt und nicht aus einem abstrakten Umbauplan.

KI macht vollständige Produktentwicklung nicht einfach. Sie macht sie für kleinere Gruppen öfter möglich. Recherche, Entwurf, Tests, Dokumentation und Release-Vorbereitung rücken näher zusammen. Dadurch kann mehr Zeit in das fließen, was Produkte wirklich besser macht: Kundenprobleme verstehen, gute Entscheidungen treffen und die Wirkung der eigenen Arbeit ernst nehmen.

Das Organigramm wird nicht verschwinden. Aber der durchgängige Ablauf kann wichtiger werden als die Grenzen zwischen seinen Kästchen. Genau darin sehe ich die produktive Veränderung: weniger Übergaben um ihrer selbst willen, mehr vollständige Verantwortung und mehr Raum, aus Software ein besseres Produkt zu machen.

Weiterführende Quellen

• Begleitendes Repository: keines – der Beitrag behandelt Produktentwicklung und Arbeitsorganisation auf Grundlage empirischer Forschung und bestehender Blogbeiträge.
• NBER: Generative AI at Work
• ILO: The impact of GenAI on jobs, productivity and work organization
• Harvard Business School: The Cybernetic Teammate
• Microsoft: 2025 Work Trend Index

Wie fandest du diesen Beitrag?

Kommentare