Context Engineering: Warum das KI-PRD den Menschen unter Zeitdruck schlägt

Markus Andrezak ist seit rund 30 Jahren im Produktmanagement unterwegs, unter anderem bei Fireball und eBay, heute mit Überprodukt. Er war lange skeptisch gegenüber generativer KI und legt in dieser Folge offen, was seine Einschätzung geändert hat.

Der Auslöser war kein neues Modell. Es war eine Arbeitsweise.

Was Context Engineering von Prompten unterscheidet

Der Unterschied klingt nach einer Nuance und ist keine. Prompten heißt, eine Aufgabe möglichst gut zu formulieren. Context Engineering heißt, die Aufgabe so weit zu zerlegen, dass jeder Teilschritt genau das Material bekommt, das er braucht.

Das Ergebnis, sagt Andrezak, sind keine brauchbaren Ausgaben mehr, sondern absurd gute. Der Grund dafür ist unspektakulär: Ein Modell scheitert selten am Können und häufig daran, dass ihm die Hälfte der Voraussetzungen fehlt.

Praktisch heißt das, die Arbeit verlagert sich nach vorn. Statt eine Antwort zu korrigieren, sorgt man dafür, dass die richtigen Unterlagen im richtigen Schritt vorliegen. Das ist mühsamer, als es klingt, und wirksamer als jede Formulierungskunst.

Das unbequeme Ergebnis

Der Satz, an dem sich die Folge aufhängt, lautet sinngemäß: Ein KI-generiertes Product Requirements Document aus 20 Kundeninterviews schlägt in der Praxis oft das, was ein Produktmanager unter echtem Organisations-Zeitdruck abliefert.

Der entscheidende Halbsatz ist „unter Zeitdruck“. Die Aussage richtet sich nicht gegen die Fähigkeiten von Menschen, sondern gegen die Bedingungen, unter denen sie arbeiten. Wer zwischen zwei Steuerungsrunden ein PRD schreiben soll, kann 20 Interviews nicht gründlich auswerten. Ein System, das genau das tut, hat den Vorteil nicht durch Intelligenz, sondern durch Zeit.

Daraus folgt ausdrücklich nicht, den Menschen aus dem Ablauf zu nehmen. Es folgt daraus, sich die besten Rohentwürfe erarbeiten zu lassen und dann zu kuratieren.

Synthetische Personas und simulierte Workshops

Der Teil, der am meisten Widerspruch provoziert und am besten belegt ist: Andrezak lässt Strategie-Workshops von KI-Agenten durchspielen, bevor er echte Kunden trifft. Für 30 bis 40 Dollar an Schnittstellengebühren entstehen Diskussionen, die er in der Qualität mit echten Workshops vergleicht, plus ein Erkenntnisvorsprung, den er sich sonst über Wochen erarbeiten müsste.

Der naheliegende Einwand lautet, dass synthetische Personas keine echten Menschen sind. Der Einwand stimmt und trifft nicht den Vergleichsmaßstab. Die Alternative ist selten sorgfältige Nutzerforschung. Die Alternative ist häufig eine Persona, die ein 25-jähriges Produktteam an die Wand gehängt hat, während die tatsächliche Zielgruppe über 50 ist.

Gemessen daran ist die synthetische Variante die realistischere. Gemessen an guter Forschung ist sie es nicht. Welcher Vergleich zutrifft, weiß jede Organisation selbst.

Führung muss Klarheit schaffen

Der zweite große Strang betrifft Organisationen. Kent Becks Beobachtung, dass 90 Prozent der bisherigen Fähigkeiten entwertet und 10 Prozent massiv aufgewertet werden, beschreibt eine Verschiebung, die ohne Führung im Chaos endet.

Als Gegenbeispiel dient Amazon unter Andy Jassy: unmissverständliche Kommunikation von Zielen und Grenzen. Nicht, weil dort alles richtig gemacht wird, sondern weil die Ansage eindeutig ist. Mitarbeitende, die wissen, was erwartet wird und was nicht erlaubt ist, probieren mehr aus als solche, die es nicht wissen.

Die historische Parallele zieht sich durch die ganze Folge: Bei Continuous Deployment hieß es vor über zehn Jahren ebenfalls, das gehe nicht, allenfalls für Spielereien. Dann verschwand der Engpass beim Ausliefern. Genau das passiert gerade beim Programmieren.

Was daraus für die Arbeitsweise folgt

Zwei konkrete Ratschläge aus der Folge sind unmittelbar anwendbar.

Der erste betrifft den Umgang mit Agenten: nicht in die Markdown-Datei greifen und Details selbst korrigieren, sondern mit dem Agenten reden und das gewünschte Ergebnis benennen. Wer die Ausgabe repariert, repariert einen Einzelfall. Wer die Absicht formuliert, verändert alle folgenden.

Der zweite betrifft die Beurteilung. Sie wandert ans Ende der Wertschöpfungskette. Bauen wird billig, Kuratieren wird zur eigentlichen Kernkompetenz. Damit verschiebt sich, worauf Erfahrung sich auszahlt: weniger auf das Erzeugen, mehr auf das Auswählen und Verwerfen.

Wie sich das im Alltag anfühlt, illustriert das Beispiel von Boris Cherny mit zehn offenen Terminals in einer Arbeitsweise, die in der Folge halb bewundernd als ADHS-Development-Stil bezeichnet wird.

Fazit

Die Folge beantwortet die Frage, ob KI Produktmanagement ersetzt, mit einem klaren Nein und einer unbequemen Präzisierung: Sie ersetzt den Teil des Produktmanagements, der unter Zeitdruck ohnehin schlecht gemacht wird.

Für die eigene Arbeit folgen daraus zwei Prüffragen. Wie viel Ihrer Vorarbeit ist Fleißarbeit, die niemand gründlich macht, weil die Zeit fehlt? Das ist der Teil, der sich lohnt.

Und woran erkennen Sie ein gutes Ergebnis? Wenn Sie darauf keine Antwort haben, hilft kein Modell, weil dann auch das Kuratieren nicht funktioniert.

Ob Rollen zu austauschbaren Generalisten verschmelzen, sieht Andrezak übrigens nüchtern. Generalisten waren historisch immer selten, daran haben weder Management by Objectives noch der Unified Process etwas geändert. Rollen verwaschen an den Rändern und bleiben im Kern bestehen.