AI Product Operating Model: vom Managen der Arbeit zum Managen des Kontexts

Warum die Teams hinter den Coding-Agents mehr als ihr Tempo verändert haben

«Welchen Coding-Agent sollen wir kaufen?» ist nicht mehr die Frage, die ich von CPOs höre. Die Frage lautet: «Wie soll mein Produktteam arbeiten, jetzt, wo Engineering in Tagen liefert?» Die erfahrenste Antwort kommt von den Teams, die die Agents bauen. Ant Murphy hat über dreissig Interviews mit den Leuten hinter Claude Code, Codex und Cursor durchgearbeitet und sieben wiederkehrende Muster gefunden. Zusammen gelesen beschreiben sie ein AI Product Operating Model, das sich von dem unterscheidet, mit dem die meisten Teams heute arbeiten.¹

Die Muster sind leicht aufzuzählen und leicht misszuverstehen. Alle managen Agents. Die Arbeitseinheit wächst. Entwicklung wird bottom-up. Dogfooding speist die Discovery. Prototypen ersetzen Meetings. Agents brauchen eine Umgebung, keinen Prompt. Rollen verschwimmen. Einzeln gelesen klingen sie nach einer Produktivitätsgeschichte. Zusammen zeigen sie auf etwas anderes: auf die Arbeit, die diese Teams aufgehört haben zu tun, und auf die Arbeit, die sie stattdessen angefangen haben.

Ich bin Mitgründer von Teklens. Davor habe ich Aioma aufgebaut und Localinas CRM an Swisscom verkauft, und ich habe an der ZHAW unterrichtet. Bei Teklens haben wir 24 Discovery-Gespräche mit Product-Leuten darüber geführt, wie ihre Teams mit KI arbeiten, und die CPO-Frage oben ist die, die sich wiederholt. Dieser Beitrag geht die sieben Muster mit den Original-Interviews hinter Murphys Lesart durch und argumentiert dann, dass sie sich zu einer Verschiebung addieren: vom Managen der Arbeit zum Managen des Kontexts. Du nimmst mit, was jedes Muster voraussetzt, bevor es funktioniert, eine Checkliste, ob ein Agent euer nächstes Feature übernehmen könnte, und die Gründe, weshalb eine Bank oder ein Industrieunternehmen die Prinzipien anpassen und nicht die Prozesse kopieren sollte.

Die These in einem Satz: Die Ausführung ist billig geworden, also ist alles um die Ausführung herum zur Aufgabe geworden, und die knappe Ressource in einem Produktteam ist nicht mehr Coding-Kapazität, sondern gemeinsamer Kontext und Urteilsvermögen. Coding ist schnell geworden. Die Koordination nicht.

Warum wird jeder zum Manager von KI?

Weil sich die operative Frage geändert hat: von «Wie mache ich das?» zu «Wie bringe ich einen Agent dazu, das zu tun?». Product-Leute bei den Frontier-Firmen delegieren operative Arbeit: Metriken analysieren, Hypothesen prüfen, Jira nachführen, Dokumentation ordnen, Entscheide vorbereiten. Die menschliche Rolle rückt eine Ebene nach oben: das Ziel definieren, den Kontext liefern, die Grenzen setzen, das Ergebnis beurteilen.¹

Alexander Embiricos, der bei OpenAI das Produkt Codex leitet, zieht die Linie zwischen Pairing und Delegation. Pairing heisst, der Agent tippt, während du zuschaust. Delegation heisst, er baut, während du im Meeting sitzt oder schläfst, in seiner eigenen Umgebung, und du kommst zurück, um das Ergebnis zu prüfen. Sein Punkt für Product-Leute: Delegation ist eine Fähigkeit, und die Fähigkeit besteht darin, ein Briefing zu schreiben, das genug Kontext zum Handeln enthält, ohne den Lösungsweg einzuengen.⁵

Cat Wu, Head of Product für Claude Code bei Anthropic, beschreibt denselben Schritt von der anderen Seite. Wenn eine Product Managerin an einem Nachmittag von der Idee zum funktionierenden Prototyp kommt, verschwindet die Lücke zwischen «Was wäre, wenn wir …» und «Hier, probier das» fast. Der neue Reflex: zuerst die Demo, dann das Dokument.³

Beachte, was beide Beschreibungen gemeinsam haben. Einen Agent zu führen gleicht dem Führen eines Menschen in genau einem Punkt: Das Briefing ist die Arbeit. Und ein gutes Briefing braucht den Kontext, den du um neun Uhr morgens nicht im Kopf hast: was letzten Sprint entschieden wurde, welche Option verworfen wurde und warum, welche Stelle im Code die Änderung berührt.

Warum wird die Arbeitseinheit grösser?

Weil es Sinn ergab, jedes Feature in Dutzende kleine User Stories zu zerlegen, solange Coding Wochen dauerte. Wenn es Stunden dauert, kostet die Zerlegung mehr, als sie spart. Teams an der Frontier übergeben einem Agent ein ganzes Feature, ein Problem oder ein gewünschtes Ergebnis. Das ist keine Rückkehr zum Wasserfall. Die Ausführungseinheit ist gewachsen, und der Engpass ist dorthin gewandert, wo entschieden wird, was gebaut wird, wo Kontext koordiniert wird und wo geprüft wird, ob das Ergebnis gut ist.¹

Das Codex-Team bei OpenAI ist der Extremfall. «We write very few specs on the Codex team. We're talking 10 bullet points and that's it», sagte Embiricos im April 2026 zu Peter Yang. Das Team plant kurzfristig und langfristig und, in seinen Worten, nie mittelfristig.⁴

Zehn Bullets funktionieren bei OpenAI aus einem Grund, der nicht mitreist. Die anderen 990 Bullets liegen im gemeinsamen Kontext: eine Codebase, die der Agent lesen kann, Evaluationssuiten, die «fertig» definieren, Konventionen, die jeder Engineer befolgt, und Kolleginnen, die die letzte Version geschrieben haben und in Hörweite sitzen. Gib zehn Bullets einem Agent in einer Firma, in der die Entscheide in Sitzungsprotokollen und die Akzeptanzkriterien in jemandes Kopf liegen, und du bekommst Software im Wert von zehn Bullets. Was ein Ticket stattdessen tragen muss, habe ich in der Anatomie eines Jira-Tickets für KI-Product-Management beschrieben.

Warum wird Produktentwicklung bottom-up, und was verhindert das Chaos?

Weil an der Frontier niemand die Roadmap vorhersagen kann. Teams bei Anthropic, OpenAI und Cursor geben Einzelnen ungewöhnlich viel Autonomie: Designer, Product Manager und Engineers bringen eine Idee vom Konzept zum Prototyp, manchmal bis zum Produktionskandidaten, innerhalb von Tagen. Das funktioniert für sie, weil sie in unerforschtem Gebiet arbeiten. Niemand weiss, was das nächste Modell können wird oder was Nutzer schätzen werden, also schlägt schnelles Erkunden vieler Richtungen das Planen des einen perfekten Wegs.¹

Wus Version in Lenny's Podcast: «We want to make sure every single person on the team feels empowered to take their idea from just an idea to out in the world in less than a week, sometimes even in a day.» Die Desktop-App von Claude Code entstand aus dem, was sie einen Side Quest nennt, einem halbtägigen Experiment zu etwas, das gerade machbar geworden war, nicht aus einem Plan.^2,3

Der Vorbehalt ist der Teil, der beim Weitererzählen verloren geht. Das ist kein Chaos. Hinter dem Tempo sitzen Code Reviews, automatisierte Tests, Evaluationen, gestaffelte Releases und Schutzmechanismen. «Alle können liefern» funktioniert nur, wenn die Infrastruktur rund ums Liefern sehr stark ist. Die DORA-Studie 2025 mit fast 5'000 Fachleuten sagt die allgemeine Version deutlich: KI erhöht den Durchsatz, und ohne starke automatisierte Tests, reife Versionskontrolle und schnelle Feedback-Schleifen wird das zusätzliche Änderungsvolumen zu Instabilität.^1,10

Was macht Dogfooding mit der Discovery?

Es verkürzt die Feedback-Schleife von Wochen auf Minuten. Die Teams hinter Claude Code, Codex und Cursor nutzen ihre eigenen Produkte den ganzen Tag. Sie treffen auf Bugs, Grenzen und Chancen, bevor ein Kunde sie meldet. Anthropic nennt seine Version Antfooding; Wu sagt, der Kanal des Teams erhält alle paar Minuten Feedback.^1,2

Cursor ist genauso gewachsen: intensive interne Nutzung und ein bewusster Fokus auf Power User statt auf eine breite «Alle können coden»-Geschichte, wie Michael Truell im selben Podcast beschrieben hat.⁸

Dogfooding hat eine gefährliche Schwäche, und Murphy benennt sie: Du bist nicht unbedingt dein Kunde. Interne Nutzung ergänzt die Customer Discovery. Sie ersetzt sie nicht. Kundenverständnis, Strategie, Research und Daten zählen weiterhin, und an den Grundlagen hat sich nichts geändert.¹

Für die meisten DACH-Unternehmen ist die Schwäche die ganze Geschichte. Ein Produktteam bei einem Versicherer nutzt seine eigene Schadensoftware nicht den ganzen Tag. Die Engineers eines Industrieunternehmens fahren nicht die Anlage des Kunden. Dogfooding gibt dir die Feedback-Schleife der Entwicklerwerkzeuge nur, wenn du Entwicklerwerkzeuge baust. Alle anderen müssen die Schleife mit Kunden bauen, was langsamer ist und sich nicht überspringen lässt.

Warum ersetzen Prototypen einige Meetings?

Weil das Debattieren einer hypothetischen Lösung relativ teuer wird, wenn Bauen billig ist. Statt einer Stunde am Whiteboard baut ein Team zwei Versionen und vergleicht sie. KI senkt die Kosten von Alternativen so weit, dass Teams zehn Konzepte testen, wo sie früher zwei getestet haben. Die Produktdiskussion wandert von Meinungen zu Artefakten: die Idee zeigen, testen, vergleichen.¹

Ian Silber, Head of Product Design bei OpenAI, beschreibt den Prozess bei Oberflächen, die zählen: «we try 100 things, we throw out 99, we finally ship one», oft täglich wechselnd, mit A/B-Tests und User Research, bevor sich etwas verfestigt.⁷

Das Meeting verschwindet nicht. Es rückt nach hinten und bekommt einen anderen Input: ein Artefakt und ein Testergebnis statt einer Folie und einer Meinung. Das ist ein besseres Meeting. Es ist auch ein Meeting, das einen Entscheid produziert, der in den meisten Firmen nirgends steht, wo ein Agent ihn am nächsten Morgen lesen könnte. Behalte das für das sechste Muster im Kopf.

Was braucht ein Agent ausser einem Prompt?

Fünf Dinge, und die Interviews sind sich darin einig, auch wo sie sich beim Format uneinig sind. Ein langlaufender Agent braucht genug Kontext, um Entscheidungen zu treffen, ein klares gewünschtes Ergebnis, explizite Prüfkriterien, Zugang zu den beteiligten Werkzeugen und Systemen und eine Schleife, in der er bauen, testen, prüfen, korrigieren und wiederholen kann. Ob das als ausführliches PRD, als leichter Plan oder als einzelnes Ziel ankommt, wird noch gestritten. Die Anforderungen darunter sind dieselben.¹

Die Neuerung ist deshalb nicht Prompt Engineering. Es ist der Bau einer Umgebung, in der ein Agent weiter auf ein überprüfbares Ergebnis hinarbeiten kann. Nufar Gaspar nennt das Loop Engineering: ein Ziel, Beurteilungs- und Abbruchkriterien, die der Agent messen kann, eine Zyklen-Kappe und eine Sandbox. Die Methode habe ich in Agentic Loops: vom Prompten zum Multiplayer-Team aus Agents beschrieben; dieser Beitrag bleibt bei dem, was sie vom Produktteam verlangt.⁹

Schau dir die fünf Anforderungen noch einmal an. Vier davon sind Kontext, keine Anweisung: was der Agent weiss, wie «fertig» aussieht, wie das Ergebnis geprüft wird, was er erreichen kann. DORA zählt «connect AI to your internal context» zu den Fähigkeiten, die Teams, die von KI profitieren, von Teams trennen, die nur schneller werden. Eine Produktorganisation, die die vier Fragen für ein Feature nicht beantworten kann, kann dieses Feature nicht delegieren, egal wie gut das Modell ist. Stripes Engineering-Team hat genau das für die ganze Firma gebaut; das Enterprise-AI-Playbook dahinter ist ein eigener Beitrag.¹⁰

Verschwinden die Produktrollen?

Nein. Sie verschwimmen. KI macht es Product Managern leichter, Prototypen zu bauen, Designern, selbst zu bauen, und Engineers, an der Discovery teilzunehmen, und die stärksten KI-Firmen stellen weiterhin Product Manager, Designer und Engineers ein. Was sich ändert, ist die Grenze zwischen den Rollen, und welcher Teil jeder Rolle es wert ist, bezahlt zu werden.¹

Der Commodity-Anteil jedes Berufs ist der Teil, der automatisiert wird. Ein Product Manager, dessen Wert vor allem im Schreiben von Jira-Tickets liegt, ist exponiert. Eine Designerin, deren Wert vor allem im Schieben von Pixeln liegt, ist exponiert. Ein Engineer, dessen Wert vor allem im Übersetzen einer Spezifikation in Syntax liegt, ist exponiert. Im Codex-Team schreiben Designer heute mehr Code, als Engineers sechs Monate zuvor geschrieben haben, und Silber erwartet Start-ups mit zwei Designern und einem Engineer: der Engineer, damit das System solide bleibt, die Designer, um herauszufinden, was gebaut werden soll.^1,4,7

Der tiefe Teil jedes Berufs bleibt. Gute Product Manager bringen Urteilsvermögen, kommerzielles Denken und einen Riecher für die Probleme mit, bei denen ein kleiner Entscheid viel verändert. Gute Designer bringen Kundenempathie, Kreativität und Interaktionsexpertise. Gute Engineers bringen Architektur, technisches Urteilsvermögen und kreatives Problemlösen. KI erweitert, was jede Person ausführen kann. Sie beseitigt den Bedarf an Expertise nicht, weshalb auch ein CPO, der Product Management bereut, trotzdem PMs einstellt.¹

Warum führt die eigentliche Verschiebung vom Managen der Arbeit zum Managen des Kontexts?

Weil Softwareteams ihren ganzen Apparat um das Verwalten von Aufgaben gebaut haben: Tickets, Stories, Übergaben, Spezifikationen, Statusberichte. KI macht die Ausführung billiger. Das erhöht den Wert von allem um die Ausführung herum: Was wollen wir erreichen? Warum? Was muss der Agent wissen? Was wurde bereits entschieden? Woher wissen wir, dass das Ergebnis korrekt ist? Die knappe Ressource ist nicht mehr Coding-Kapazität. Es sind gemeinsamer Kontext und Urteilsvermögen.¹

Kontext managen heisst, das Ziel, die bereits gefallenen Entscheide, die Grenzen und die Prüfkriterien eines Vorhabens aufgeschrieben, aktuell und lesbar zu halten, für jede Person und jeden Agent, die daran arbeiten. Arbeit managen heisst, zu verfolgen, wer welche Aufgabe bis wann erledigt. Das Erste macht das Zweite weitgehend überflüssig; das Zweite bringt das Erste nie hervor.

Der Ausgangspunkt ist nicht schmeichelhaft. In der Umfrage des Pragmatic Institute von 2019 unter rund 2'500 Product-Leuten gingen 73 Prozent der Arbeitszeit an taktische Arbeit, Koordination, Administration und Support und 27 Prozent an Strategie. Das war vor den Coding-Agents. Agents senken die 73 Prozent nicht von selbst. Sie machen jeden fehlenden Entscheid schneller sichtbar, denn ein Agent ohne Kontext fragt entweder nach oder rät.¹²

Fiona Fung, die bei Anthropic die Teams für Claude Code und Cowork führt, berichtete im Juni 2026, dass ihre Teams rund achtmal mehr Code ausliefern als zuvor. Sie berichtete auch von den versteckten Kosten: Wenn alle neben ihrem eigenen Agent arbeiten, hört Engineering auf, eine gemeinsame Tätigkeit zu sein, und das Team musste seine Verbindung bewusst wieder aufbauen, mit Pairing-Lunches und Hackathons. Wenn gemeinsamer Kontext bei Anthropic nicht von selbst entsteht, entsteht er nirgends von selbst. Er muss gemanagt werden.⁶

Marty Cagan definiert das Product Operating Model entlang dreier Fragen: wie ihr baut, wie ihr Probleme löst und wie ihr entscheidet, welche Probleme ihr löst. Die KI-Version verändert die erste Frage am stärksten, weil Agents jetzt einen grossen Teil des Bauens übernehmen. Das setzt die anderen beiden unter Druck, und Kontext managen ist die Praxis, die alle drei verbunden hält: Der Entscheid erreicht die Spec, die Spec erreicht den Agent, das Ergebnis wird gegen den Entscheid geprüft.¹³

Warum du Anthropic oder OpenAI nicht kopieren solltest

Weil die Frontier-Firmen unter Bedingungen arbeiten, die dein Unternehmen nicht hat: aussergewöhnliches technisches Talent, eine Technologie, die sich monatlich ändert, hohe Unsicherheit darüber, was Nutzer wollen, und interne Infrastruktur, die Fehler auffängt, bevor sie etwas kosten. Eine Bank, ein Industrieunternehmen oder ein etabliertes SaaS-Geschäft arbeitet unter anderen Zwängen. Wer «alle liefern jede Woche» kopiert, ohne die Fähigkeiten, Schutzmechanismen und den Kontext dahinter, bekommt mehr Chaos, nicht mehr Tempo.¹

DORAs Einzeiler zu seinen Daten von 2025 ist die Warnung: «AI doesn't fix a team; it amplifies what's already there.» METRs kontrollierte Studie mit erfahrenen Open-Source-Entwicklern ergänzt das unbequeme Detail: Mit KI-Werkzeugen waren sie auf ihren eigenen Repositories 19 Prozent langsamer, während sie glaubten, schneller zu sein. Kleine Stichprobe, spezifisches Umfeld, aber der Befund zur Selbstwahrnehmung ist der belastbare Teil.^10,11

Die Lektion ist nicht, die Prozesse zu kopieren. Sie lautet, zu verstehen, warum sie funktionieren, und die Prinzipien anzupassen. Dasselbe Argument habe ich gemacht, warum das Spotify-Modell scheitert, mit KI-Agenten erst recht: Eine Praxis, die ohne die Bedingungen verpflanzt wird, die sie tragen, wird zum Ritual.

Womit der Beitrag zur Frage des CPO zurückkommt. «Wie soll mein Produktteam jetzt arbeiten?» hat keinen Prozess als Antwort. Es hat vier Prinzipien, die die Frontier-Teams teilen und die die Verpflanzung überstehen: Menschen definieren die Absicht. Agents führen mehr von der Arbeit aus. Gemeinsamer Kontext hält beide auf Kurs. Prüfung schliesst die Schleife. Murphy nennt das das entstehende Product Operating System. Es ist eine grössere Veränderung, als dem Produkt-Stack ein weiteres KI-Werkzeug hinzuzufügen, und es ist die Veränderung, die die sieben Muster die ganze Zeit beschrieben haben.¹

Wo Teklens in diesem Bild sitzt

Das ist die eine Stelle, an die Teklens in diesem Beitrag gehört. Jedes Muster oben braucht einen Ort, an dem Ziel, Entscheide, Grenzen und Prüfkriterien liegen, lesbar für Menschen und Agents, und aktuell, wenn sich ein Entscheid ändert. Teklens ist als dieser Ort gebaut: das gemeinsame Product Brain für euer Software-Team, ein gemeinsames Gedächtnis für Menschen und Agents. Es hält Produktentscheide, Kundenfeedback, Jira und Code verbunden und aktuell, damit Product, Engineering und KI-Agenten mit demselben Wissen arbeiten. Ihr entscheidet. Teklens hält das Wissen zusammen.

Die Arbeitsweise darum herum nennen wir AI Product Playbook: Activities, jede ein konkreter Arbeitsschritt vom Start bis zur Freigabe, mit einem Zweck, dem Wissen, das sie brauchen, einem benannten menschlichen Owner, zugewiesenen Agents, einem definierten Ergebnis und einer menschlichen Freigabe, entlang des Flusses vom Entscheid über Spec, Plan, Build und Review bis zur ausgelieferten Software. Menschen steuern und geben frei. Agents erledigen die Arbeit. Im Vokabular dieses Beitrags: Kontext managen als tägliche Praxis statt als Dokument, das niemand nachführt. Das Mass, das uns interessiert, ist weniger Koordinationsarbeit für das Team, nicht die Zahl der eingesetzten Agents.

Namen und Zahlen veröffentlichen wir nur mit Freigabe, deshalb steht hier keine Metrik; die ersten Teams arbeiten produktiv mit Teklens. Wenn du eine echte Activity vom Start bis zur menschlichen Freigabe auf eurem eigenen Jira und Repository sehen willst: Demo buchen, dreissig Minuten mit einem Founder und eine ehrliche Antwort, ob es zu eurem Setup passt. Ein Call, und Jira und euer Repo sind in unter einer Stunde verbunden.

Häufige Fragen

Empfehlungen

• Schreib den Entscheid auf, nicht nur das Ticket. Jeder Produktentscheid, der ändert, was gebaut wird, kommt an einen Ort, den Menschen und Agents lesen können: das Ziel, die gewählte Option, die verworfenen Optionen und warum. Fang mit den Entscheiden aus den Meetings dieser Woche an.
• Vergrössere die Arbeitseinheit nur dort, wo Prüfung existiert. Übergib einem Agent ein ganzes Feature, wenn du aufschreiben kannst, woran das Ergebnis geprüft wird. Wo du das nicht kannst, halte die Einheit klein und entwirf zuerst die Prüfung.
• Ersetze eine Debatte pro Woche durch zwei Prototypen. Nimm die nächste Diskussion, die eine Stunde dauern würde, bau zwei Versionen, leg sie drei Nutzern vor und entscheide am Artefakt.
• Halte Dogfooding und Customer Discovery getrennt. Führe in zwei Spalten, was die interne Nutzung gelehrt hat und was Kunden gelehrt haben. Bleibt die zweite Spalte leer, ist eure Discovery zum Stillstand gekommen.
• Bau das Sicherheitsnetz vor der Autonomie. Tests, Review, gestaffelte Releases und eine benannte Freigabeperson kommen vor «alle können liefern». Autonomie auf einem schwachen Netz ist das Chaos, vor dem Murphy warnt.
• Beurteile Rollen nach Urteilsvermögen, nicht nach Artefakt-Ausstoss. Frag bei Einstellung und Review, was die Person entschieden hat und was es verändert hat, nicht wie viele Tickets, Screens oder Pull Requests sie produziert hat.

Einordnung & Grenzen

• Ant Murphys sieben Muster sind seine Lesart von über dreissig öffentlichen Interviews mit Leuten aus drei Firmen, veröffentlicht im September 2026 als erster Teil einer Serie. Es ist eine Synthese von Anbieteraussagen, keine Studie, und die Firmen beschreiben ihre eigene Praxis.
• Cat Wu, Alexander Embiricos, Romain Huet, Fiona Fung, Ian Silber und Michael Truell sprechen über ihre eigenen Teams und Produkte. Zahlen wie «achtmal mehr Code» oder Feedback «alle paar Minuten» sind ihre Aussagen, nicht unabhängig gemessen.
• DORA 2025 hat fast 5'000 Technologie-Fachleute befragt und qualitative Interviews ergänzt; der Bericht zeigt Zusammenhänge, keine kausalen Effekte. METRs Studie ist ein randomisiertes Experiment mit kleiner Stichprobe in einem spezifischen Umfeld; der Befund zur Selbstwahrnehmung ist der belastbarste Teil.
• Die 27/73-Aufteilung des Pragmatic Institute stammt aus seiner Jahresumfrage 2019 unter rund 2'500 Product-Leuten, selbst eingeschätzt und vor den Coding-Agents. Sie zeigt den Ausgangspunkt, nicht den heutigen Stand.
• Die 24 Discovery-Gespräche sind Gespräche von Teklens mit Product-Leuten, keine Studie. Die Teklens-Aussagen beschreiben Fähigkeiten des Produkts, keine gemessenen Kundenresultate.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Ant Murphy, «How The Leading AI Companies Do Product (Part 1)», Newsletter auf antmurphy.me, September 2026 ↗ – Die sieben Muster und die Schlussargumente; dieser Beitrag folgt seiner Reihenfolge und ergänzt die Original-Interviews.
2. 2.Cat Wu mit Lenny Rachitsky, «How Anthropic's product team moves faster than anyone else», Lenny's Podcast, April 2026 ↗ – Das Zitat «less than a week», Antfooding, Prototypen statt Dokumente, Designer, die Code einchecken.
3. 3.Cat Wu, «Product management on the AI exponential», Anthropic, März 2026 ↗ – Zuerst die Demo, dann das Dokument; Side Quests; von der Idee zum Prototyp an einem Nachmittag.
4. 4.Alexander Embiricos und Romain Huet mit Peter Yang, «How OpenAI's Codex Team Builds with Codex», Creator Economy, 5. April 2026 ↗ – Specs mit zehn Bullets, Planungshorizonte, Designer, die Code schreiben.
5. 5.Alexander Embiricos mit Lenny Rachitsky, «Why humans are AI's biggest bottleneck (and what's coming in 2026)», Lenny's Podcast, 14. Dezember 2025 ↗ – Pairing versus Delegation; Delegation als Fähigkeit; Review als neue Aufgabe.
6. 6.Fiona Fung mit Lenny Rachitsky, «What happens after coding is solved?», Lenny's Podcast, 21. Juni 2026 ↗ – Achtmal mehr Code; Engineering ist keine gemeinsame Tätigkeit mehr; Pairing-Lunches und Hackathons.
7. 7.Ian Silber mit Lenny Rachitsky, «OpenAI's Head of Design: This is the best time in history to be a designer», Lenny's Podcast, August 2026 ↗ – «100 things, throw out 99, ship one»; zwei Designer und ein Engineer.
8. 8.Michael Truell mit Lenny Rachitsky, «The rise of Cursor», Lenny's Podcast, 2025 ↗ – Interne Nutzung und der Fokus auf Power User.
9. 9.Nufar Gaspar und Nathaniel Whittemore, «Agentic Loops for Knowledge Workers», The AI Daily Brief, 3. September 2026 ↗ – Loop Engineering: Goal Card, Prüfkriterien, Zyklen-Kappe.
10. 10.DORA, «State of AI-assisted Software Development 2025», Google Cloud, 23. September 2025 ↗ – Fast 5'000 Fachleute; KI als Verstärker; Durchsatz versus Instabilität; «connect AI to your internal context».
11. 11.METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10. Juli 2025 ↗ – Randomisiertes Experiment: 19 Prozent langsamer bei gefühlt höherem Tempo; kleine Stichprobe.
12. 12.Pragmatic Institute, «2019 Annual Product Management & Product Marketing Survey», 2019 ↗ – Rund 2'500 Befragte; 27 Prozent Strategie, 73 Prozent Taktik, Koordination, Administration und Support.
13. 13.Marty Cagan, «The Product Operating Model: An Introduction», Silicon Valley Product Group ↗ – Wie ihr baut, wie ihr Probleme löst, wie ihr entscheidet, welche Probleme ihr löst; der Rahmen hinter «Transformed» (2024).

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.