Ich habe zwei Bücher, die mich in Produkt geprägt haben: Inspired von Marty Cagan und Gestão de Produtos von Joca Torres, bei dem ich sogar das Glück hatte, ein Mentoring zu machen. Jahrelang waren diese beiden meine Landkarte: was ein PM ist, was ein Product Designer ist, was ein Engineer ist, wer was macht. Jede Rolle mit klaren Konturen.
Im letzten Jahr, als ich mein Team bei Prolog mit KI arbeiten sah, fing ich an, diese Konturen verrutschen zu spüren. Nicht, dass die Bücher falsch geworden wären: es ist die Ebene, auf der jede Rolle stattfindet, die nach oben gerückt ist.
Im ersten Text der Serie habe ich das Unbehagen erzählt, das mich dazu brachte, Tech bei Prolog umzubauen, und im zweiten, was ein Harness ist, die Infra, die KI liefern lässt. Am Ende des ersten hatte ich versprochen, einen bestimmten Teil aufzumachen: wie sich die Arbeit jedes Berufs ändert, wenn KI zu dem wird, der baut. Darum geht es hier.
Die Arbeit verschwindet nicht, sie rückt eine Ebene nach oben
KI löscht nicht die Rolle jedes Berufs, sie ändert die Ebene, auf der sie stattfindet.
Die einfache Lesart, die mit Angst verkauft, ist “KI wird Beruf X ersetzen”, und das habe ich nicht passieren sehen. Was ich gesehen habe, war, dass der Inhalt der Arbeit den Ort wechselte: was früher machen war, wurde zu dirigieren und den kritisieren, der macht.
Der Engineer, der den Code schrieb, reviewt jetzt, was der Agent geschrieben hat. Der PM, der die Spec schrieb, beurteilt jetzt den Prototypen, der in Stunden daraus entstanden ist. Die Person ist dieselbe, das Instrument in ihrer Hand hat sich geändert.
Als ich mit diesem Gedanken zu Cagan und Joca zurückkehrte, fiel der Groschen auf andere Weise. Beide beschreiben sorgfältig die Ausführung jeder Rolle (die konkrete Aufgabe, das Deliverable, das, was am Ende des Tages aus deinen Händen kommt), und genau das übernimmt KI. Was für den Menschen übrig bleibt, ist die andere Hälfte: entscheiden, was es wert ist, gebaut zu werden, das Loch in dem finden, was gebaut wurde, Geschmack haben, um zu wissen, was gut ist. Das Urteil, nicht die Ausführung.
Also mache ich, was ich mit mir selbst gemacht habe: die Definition jeder Rolle aus den Büchern nehmen und fragen, was KI davon frisst und was davon übrig bleibt (und teurer wird).
Das Team der drei, laut den Büchern
Bevor wir es Rolle für Rolle aufteilen, lohnt es sich, daran zu erinnern, wie die Bücher das Team zusammenstellen. Joca ist direkt: ein erfolgreiches Produkt muss wünschenswert, tragfähig und baubar sein, und das definiert “die drei essenziellen Funktionen, um ein erfolgreiches Produkt zu schaffen” (Kap. 2): UX-Designer, Produktmanagement und Entwickler, das Trio, das er core team nennt. Cagan beschreibt in Inspired dieselben Rollen im Eröffnungskapitel, “Key Roles and Responsibilities”.
Beide bestehen auf einem Punkt, auf den ich am Ende zurückkomme: es ist keine Beziehung von Chef und Untergebenem. In Jocas Worten sind “Produktengineering, Produktmanagement und UX ein Team, es gibt keine Unterordnungsbeziehung zwischen diesen Gruppen” (Kap. 31), und bei Cagan taucht dieselbe Idee auf als PM und Engineering, die “Gleichgestellte sind, keine Position ist der anderen untergeordnet” (Kap. 5, in meiner Übersetzung). Und wenn KI in die Mitte des Trios tritt, ist es diese Partnerschaft, die am meisten die Form ändert.
Tabelle: jeder Beruf in der Tech steigt eine Ebene höher. Engineering wird vom Code-Produzenten zum Kritiker des Agenten; Produkt vom Spec-Writer zum Architekten der Iteration; Design vom Screen-Produzenten zum Dirigenten des Experiments; Qualität vom Tester zum Bauer der Validierung.
Die Rolle jedes Berufs in der Tech
Dieselbe Rolle, eine Ebene höher
die Ausführung geht an den Agenten · das Urteil bleibt bei dir: entscheiden, kritisieren, Geschmack haben
Engineer: vom Code-Produzenten zum Kritiker des Agenten
Für Engineering zählt nicht mehr, wie viel Code du produzierst: es wurde, wie gut du kritisierst, was der Agent produziert hat.
Jocas Definition ist so klar, dass es weh tut, sie jetzt wiederzulesen: “Produktengineering ist verantwortlich dafür, das Produkt zu entwickeln und es am Laufen zu halten”, und weiter hinten “baut” das Engineering “das Produkt” (Kap. 31). Bauen war das Verb. Cagan ergänzt es von der anderen Seite, wenn er über die Beziehung zu Produkt spricht: “der Product Manager ist verantwortlich dafür, die Lösung zu definieren, aber das Engineering-Team weiß besser, was möglich ist, und es ist am Ende dasjenige, das diese Lösung liefert” (Kap. 5, in meiner Übersetzung). Definieren auf der einen Seite, liefern auf der anderen.
Jetzt gehört die Lieferung der ersten Version dem Agenten. Was sich nicht geändert hat und teurer wurde, ist alles, was Cagan dem Engineer als Innovationsquelle anheftete: “die Engineers wissen besser als irgendjemand, was möglich ist” (Kap. 5). Zu wissen, was möglich ist, das Loch im Plan zu finden, den der Agent vorgeschlagen hat, den Performance- oder Sicherheits-Trade-off zu sehen, den er nicht sieht, zu entscheiden, wann man eingreift und wann man laufen lässt. Das wiegt jeden Monat mehr. Syntax auswendig, Boilerplate von Hand, Stack Overflow durchkämmen, Codevolumen als persönliche Trophäe: das wiegt weniger.
Bei Prolog habe ich das dem Team klipp und klar gesagt: niemand wird nach Codezeilen bewertet. Wer immer gut darin war, “das Loch zu finden”, wird wertvoller, und wer sich mit “viel Code schnell produzieren” identifizierte, wird neu kalibrieren müssen, wo er investiert. Und das schmälert das Engineering nicht. Sein Wert lag immer mehr darin, zu wissen, was taugt, als schnell zu produzieren, und jetzt wird das nur explizit.
PM: vom Spec-Writer zum Architekten der Iteration
Der PM spürt es, wenn der Prototyp billig wird: seine Arbeit hört auf, das Dokument zu schreiben, und wird, welche Idee die Zeit des Teams wert ist, auszuwählen.
Cagan ist kategorisch, was den Kern der Arbeit angeht: “jemand muss herausfinden, was die Lösung ist, das Produkt, einschließlich der Funktionalitäten, der User Experience und der Release-Kriterien. Dieser jemand ist der Product Manager, und diese Aufgabe ist der Kern seiner Arbeit” (Kap. 1, in meiner Übersetzung). Joca gibt die grobe Kontur: Produktmanagement ist “die Funktion, die für alle Aspekte eines Softwareprodukts verantwortlich ist, während des gesamten Lebenszyklus dieses Produkts, von der Konzeption bis zum Ende seines Lebens” (Kap. 2).
Achte darauf, dass bei beiden das Schlüsselwort herausfinden ist, nicht spezifizieren. Cagan hat ein ganzes Kapitel nur dazu, zu verteidigen, dass die Arbeit Discovery ist, nicht “Anforderungen”: Software hat zwei Phasen, “herausfinden, was zu bauen ist (das richtige Produkt), und bauen (das Produkt auf die richtige Weise). Die erste wird von Discovery dominiert, die zweite ist Ausführung” (Kap. 12, in meiner Übersetzung). Das war immer seine Botschaft, und KI hat sie nur wörtlich gemacht.
Denn wenn der Build von Wochen auf Stunden kollabiert, hört der Engpass auf, das Bauen zu sein, und wird, zu entscheiden, was zu bauen sich lohnt. Die lange, im Komitee reviewte Spec, das geschlossene Quartalsplanning, der Status-Report als Deliverable, die Verkehrssteuerung zwischen Engineering und Design: all das wiegt weniger. Was mehr wiegt, ist schnelles Discovery (prototypen, um zu verstehen, nicht speccen, um zu bauen), Kuratieren von Hypothesen (welche Idee die Zeit des Teams wert ist) und öfter zu entscheiden, was nicht zu tun ist. Einige Firmen nennen diesen PM schon “Editor” oder “Architekt”. Es ist nicht weniger PM: es ist ein anderer PM, der, der kuratiert, der mit Geschmack entscheidet, der Richtung gibt. Was im alten zentral war, die Spec schreiben, ist das, was leicht geworden ist.
Product Designer: vom Screen-Produzenten zum Dirigenten des Experiments
Im Design verlässt die Arbeitseinheit den Screen und geht zum System, das Screens produziert, und der Product Designer wählt jetzt aus, welche Variante überlebt.
Bei Joca ist die Definition von UX, verstehen, um zu entwerfen: “UX ist verantwortlich dafür, den Nutzer und das Problem, das man für diesen Nutzer lösen will, tief zu verstehen” (Kap. 32). Und der Ablauf, den er beschreibt, ist das Ritual, das jeder kennt: Papierprototyp, dann Wireframe, dann fängt “der visuelle UX-Designer an, Farbe und Form in diese Screens zu bringen”. Cagan schneidet die Rolle mit derselben Logik in zwei: der Interaction Designer “entwickelt ein tiefes Verständnis der Nutzer und erstellt die Tasks, die Navigation und den Flow”, mappt das in Wireframes und gibt es an den Visual Designer weiter, der “dem Wireframe Fleisch gibt” (Kap. 4, in meiner Übersetzung).
Diese Verkettung, verstehen, skizzieren, Screen für Screen verfeinern, ist genau das, was KI verkürzt. Die Arbeitseinheit hört auf, “der Screen” zu sein, und wird “das System, das Screens generiert”. Dieselbe Variante fünfmal in Figma neu machen, Komponente für Komponente spezifizieren, das pixelgenaue Handoff als Ritus: wiegt weniger. In Iterationsgeschwindigkeit prototypen (mehrere Optionen parallel, die schlechten wegwerfen), das visuelle System definieren statt jeden isolierten Screen, und die schnelle visuelle Kritik (die KI etwas vorschlagen sehen und auf den ersten Blick merken, dass es falsch ist, bevor der Nutzer es merkt): wiegt mehr.
Und hier sagt Cagan, damals 2008, etwas, das den Product Designer davor schützt, zu denken, er sei zum Knöpfchendrücker geworden: seine Arbeit war nie nur, schön zu zeichnen. “Ein gutes Produkt braucht eine gute User Experience. Und eine gute Experience braucht die enge Zusammenarbeit zwischen Produkt und Design” (Kap. 4, in meiner Übersetzung). Die KI generiert die Variante, und wer entscheidet, welche davon es wert ist, zum Nutzer zu kommen, sind weiterhin Menschen mit Geschmack.
QA: vom Tester zum Bauer der Validierung
QA ist der interessanteste Fall, weil es die Rolle ist, die die Bücher fast nicht isoliert haben, und die, die KI am meisten bewegt.
Achte darauf: in Jocas Trio (Designer, PM, Entwickler) und in Cagans Rollen taucht Qualität verwässert auf, als Verantwortung des Teams, nicht als eigener Stuhl mit einer eigenen Methode. Lange hat das Sinn ergeben, aber jetzt nicht mehr, und der Grund ist einfach: wenn der Agent schnell baut und die Validierung manuell bleibt, hast du nur technische Schulden in hoher Geschwindigkeit produziert.
Also hört QA auf, derjenige zu sein, der den Testfall von Hand durchläuft, und wird derjenige, der das Testing Harness entwirft, das System, das das System testet: KI konfigurieren, um Tests für den Code zu schreiben, den eine andere KI geschrieben hat, Regressionen erkennen, bevor der Nutzer es tut, überlegen, wo der Defekt tendenziell auftaucht. In der Praxis wurde es zu einer operativen Frage, die wir übernommen haben: jeder Bug, der durchrutscht, wird zu “wie erkennen wir das nächstes Mal automatisch?”. Erschöpfendes manuelles Testen eines bekannten Flows, bei jedem Release von Hand durchlaufene Regression, QA als einziges Tor vor dem Ausliefern: wiegt weniger. Validierung als System, nicht als Ballabgabe am Ende des Fließbands.
Es ist die Rolle, die am meisten eine Ebene aufsteigt, genau weil sie die am wenigsten definierte war. Wo die Bücher keine Kontur eingemeißelt haben, zeichnet KI eine neue.
Die Konstante: was die Bücher schon als das Wichtigste bezeichneten
Es gibt eine Sache, die sich nicht ändert, und sie war in beiden Büchern in aller Öffentlichkeit versteckt: was sie als die wichtigste Eigenschaft benennen, ist genau das, was KI nicht macht.
Joca eröffnet das Kapitel über die Eigenschaften eines guten PM ohne Umschweife: “die wichtigste von allen ist ohne jeden Zweifel die Empathie” (Kap. 4). Es ist keine Funktionstabelle und kein Deliverable: es ist die Fähigkeit, sich in die Lage dessen zu versetzen, der es nutzt. Cagan seinerseits verbringt das ganze Buch damit, Discovery, Taste und Urteil über Prozess zu verteidigen, und beide sagten, jeder auf seine Weise, dasselbe: was das Gute vom Mittelmäßigen trennt, war nie der mechanische Teil der Arbeit.
Und der mechanische Teil ist genau der, der an den Agenten ging. Die Spec schreiben, den Screen entwerfen, den Code schreiben, den Test durchlaufen. Was blieb und teurer wurde, ist kritischer Sinn, Taste (wissen, was gut ist), Urteil unter Ambiguität, Neugier, Sorge um den, der nutzt, was du machst. Zusammengefasst in dem Satz, den ich beim Team benutzt habe: der Inhalt der Arbeit ändert sich, die Person, die sie macht, nicht.
Diagramm in zwei Ebenen. Oben, was bei uns blieb und teurer wurde: Taste (wissen, was gut ist), Urteil unter Ambiguität, Empathie mit dem, der es nutzt, entscheiden, was man nicht tut, was die Bücher schon als das Wichtigste bezeichneten. Die Arbeit stieg eine Ebene höher. Unten, was an den Agenten ging: die Spec schreiben, den Screen entwerfen, den Code schreiben, den manuellen Test durchlaufen.
Blieb bei uns · und wurde teurer
was die Bücher schon als das Wichtigste bezeichneten
die Arbeit stieg eine Ebene höher
Ging an den Agenten
Was das kosten wird (ohne Klischee)
Ich will das nicht zu schön abschließen, weil es das nicht ist. Diese Veränderung kostet konkrete Dinge, und keins davon ist bequem.
Das erste ist, eine Gewohnheit von einem Jahrzehnt hinter sich zu lassen. Wer seit fünf, zehn Jahren in der alten Art steckt, trägt Muster, die geholfen haben, bis hierher zu kommen, und genau diese Muster sind es, die schwer wiegen, um sich zu ändern. Es gibt keine Abkürzung, und das Unbehagen ist zu erwarten.
Dann, die KI genauso zu kritisieren wie mit ihr zu erschaffen: den Vorschlag anzunehmen, der aufgetaucht ist, ist keine Arbeit; das Loch im Plan zu finden, den sie vorgeschlagen hat, schon. Was immer teuer war (kritisches Denken, Taste, Urteil), wird teurer.
Da ist auch, als Team zu scheitern, nicht als Person. Wir feuern keinen Engineer wegen eines Bugs in Produktion, wir verbessern das Review, und wenn die KI sich irrt, ist es das Harness, das wir stärken. Der Bug des Agenten ist Prozess, nicht Person: eine Verpflichtung, kein Slogan.
Und das unbequemste: zu akzeptieren, dass sich manche Funktionen mehr ändern als andere. Das erzeugt Unbehagen bei denen, die sich bis jetzt wenig geändert haben, und man kann nicht so tun, als wäre alles gleich. Was man tun kann, ist es in ein offenes Gespräch zu bringen.
Und um nicht wie jemand zu klingen, der am Ziel angekommen ist: Prolog steht bei all dem noch am Anfang. Wir sind weiter AI-assisted, mit einem Gewinn von 10 bis 20%, nicht AI-first von 5x oder 10x. Ich erzähle eine Richtung, die wir bauen, mit Treffer und mit Fehler, keinen Sieg.
Was ich davon mitnehme
Die Bücher sind nicht falsch geworden. Sie beschrieben die Ausführung jeder Rolle mit einer Präzision, die ich erst jetzt wirklich verstanden habe (die Spec schreiben, den Screen entwerfen, das Produkt bauen, den Test durchlaufen), und diese Ausführung gehört jetzt dem Agenten. Und was für den Menschen übrig blieb, ist der andere Teil, urteilen, kritisieren, Geschmack haben, sich um den kümmern, der nutzt, was, zurück zu Cagan und Joca, das ist, was sie schon von der ersten Seite an als das Wichtigste bezeichneten.
Vielleicht ist das der gute Teil: die Arbeit, die KI uns aus der Hand genommen hat, ist die, die am repetitivsten war, und die, die sie gelassen hat, ist die, die immer am schwersten und am interessantesten war. Ich erzähle weiter, wie es läuft.
Quellen
- Marty Cagan, Inspired: How to Create Products Customers Love (1. Auflage, 2008). Die Rollendefinitionen stammen aus den Kapiteln 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) und 12 (Product Discovery). Die Übersetzungen der Passagen sind meine.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Die Definitionen stammen aus den Kapiteln 2 (Was ist Software-Produktmanagement?), 4 (Wichtigste Eigenschaften eines Produktmanagers), 31 (Produktengineering und Produktmanagement) und 32 (UX und Produktmanagement).
- Die Lesart, dass die Rolle eine Ebene aufsteigt, stützt die Serie: OpenAI, Harness Engineering, und Peter Pang, CTO von CREAO.