Das unscheinbare Product Requirements Document (PRD) ist seit Jahrzehnten das Rückgrat der Softwareentwicklung. Diese langen Dokumente legten Funktionen, User Stories und technische Spezifikationen bis ins kleinste Detail fest, bevor auch nur eine Zeile Code geschrieben war. Doch laut Aparna Chennapragada, Chief Product Officer bei Microsoft, geht diese Ära rasch zu Ende.
„Ich sage dazu: Prompt-Sets sind die neuen PRDs“, sagte Chennapragada in einem aktuellen Interview. „Ich bestehe wirklich darauf, dass es heißt: Wer neue Projekte baut, liefert zu neuen Funktionen selbstverständlich Prototypen und Prompt-Sets mit.“
Das ist weder ein semantisches Wortspiel noch der nächste Schlagwortwechsel aus dem Silicon Valley. Dahinter steckt ein grundlegender Wandel in der Art, wie Produktteams entwickeln, in einer Zeit, in der die Natural Language Experience (NLX) zum vorherrschenden Schnittstellenparadigma wird. Chennapragada formuliert es so: „NLX ist die neue UX.“
Das Ende von „Memos vor Demos“
Der klassische Ablauf der Produktentwicklung steht auf dem Kopf. Wo Teams früher monatelang an detaillierten Spezifikationen feilten, setzt Chennapragada auf sofortiges Prototyping: „Wer heutzutage keine Prototypen baut, um zu sehen, was er bauen will, macht es meiner Meinung nach falsch.“
Ihre Devise „Demos vor Memos“ nutzt die Fähigkeit von KI, Ideen in kurzer Zeit in funktionierende Prototypen zu verwandeln. Das sind allerdings keine herkömmlichen klickbaren Mockups. Im Zeitalter von Konversationsschnittstellen und KI-Agenten ist die nützlichste Produktspezifikation kein PDF, sondern ein ausführbares Set von Prompts, das live und interaktiv vorführt, wie sich das Produkt verhalten soll.
„Das ist eine Form der Kommunikation mit viel höherer Bandbreite“, erklärte Chennapragada. Statt zu hoffen, dass die Entwickler schriftliche Anforderungen richtig deuten, können Teams jetzt in funktionierenden Gesprächen mit KI-Systemen genau zeigen, was ihnen vorschwebt.
Was genau ist ein „Prompt-Set“?
Ein Prompt-Set ist eine ausführbare Spezifikation, die mehrere Bestandteile bündelt:
- Kanonische Prompts und Rollen (System- und User-Interaktionen)
- Varianten für Grenzfälle und User-Personas
- Evaluierungs-Prompts mit Abnahmekriterien (automatisch und von Menschen bewertet)
- Guardrails, die festlegen, was das Modell tun muss und was es nicht tun darf
- Kontextverträge, die bestimmen, welche Daten und Werkzeuge zur Verfügung stehen
- UI-Erwartungen für NLX (etwa Pläne vor dem Handeln zeigen, Fortschrittsanzeigen, Vorschläge für nächste Schritte)
Ein klassisches PRD beschreibt, was gebaut werden soll. Ein Prompt-Set führt vor, wie es sich verhält: heute, mit den aktuellen Modellen und mit überprüfbaren Ergebnissen.
Dieser Ansatz reagiert auf eine grundlegende Veränderung im Umgang der User mit Software. Chennapragada bemerkt dazu: „Auch Gespräche haben Grammatiken, sie haben Strukturen, sie haben UI-Elemente, sie sind unsichtbar.“ Produktteams müssen diese Gesprächsstrukturen heute genauso bewusst gestalten wie früher Schaltflächen und Menüs.
Die neue Gestaltungssprache des Gesprächs
Natürlichsprachliche Schnittstellen bringen ganz neue UI-Elemente mit, die ausdrückliche Designentscheidungen verlangen:
Pläne als UI-Elemente: Wenn User KI-Agenten ein grob formuliertes Ziel geben, sollte das System mit einem bearbeitbaren Plan antworten, statt sofort loszulegen. So sehen die User, was gleich passiert, und behalten die Kontrolle darüber.
Fortschrittsberichte: Wie viel soll das System von seinem Denkprozess preisgeben? Zu ausführlich, und es fühlt sich an, als würde man Serverlogs zusehen. Zu knapp, und die User wissen nicht, ob das System richtig arbeitet.
Follow-up-Vorschläge: Welche „naheliegenden nächsten Schritte“ soll das System nach einer erledigten Aufgabe von sich aus vorschlagen? Das führt User zu erfolgreichen Abläufen, ohne sich aufzudrängen.
Konfidenzangaben: Wann soll das System Quellen nennen, Unsicherheit ausdrücken oder um Erlaubnis fragen, bevor es weitermacht?
Diese Elemente stammen aus aktuellen Designleitfäden für die UX von Agentensystemen. Was früher ad hoc entstand, wird dort zu Mustern, die sich gestalten und spezifizieren lassen.
Anatomie eines Prompt-PRD
Eine umfassende Prompt-basierte Spezifikation enthält mehrere Abschnitte, die klassische PRDs nicht haben:
Kernproblem & Flows
- Problembeschreibung & Jobs-to-be-done in einfacher Sprache
- Kanonische Flows mit konkreten Prompts und dem erwarteten Verhalten der UI
- Kickoff-Prompt, der Rolle, Tonfall und Guardrails festlegt
- Planungsverhalten, das bestimmt, wie Agenten bearbeitbare Pläne vorschlagen sollen
- Fortschrittsverhalten, das festlegt, wann und wie das System seine Arbeit kommentiert
- Follow-up-Muster, die beschreiben, welche nächsten Schritte je nach Kontext vorzuschlagen sind
Technische Verträge
- Kontextvertrag, der verfügbare Datenquellen, APIs und Berechtigungsgrenzen festlegt
- Evaluierungssuite mit Test-Prompts und erwarteten Ergebnissen
- Sicherheitsrichtlinien für den Umgang mit unsicheren Anfragen, Jailbreak-Versuchen und Prompt Injection
- Versionsangaben, darunter Modellversionen, Parameter und Datenindizes
Ein Minimalbeispiel
Nehmen Sie eine Funktion namens „Einseiten-PRD-Generator“:
- Kickoff-Prompt: „Du bist ein erfahrener PM-Assistent. Stelle zuerst 3 Fragen zum Umfang und gib dann diese Abschnitte aus: Überblick, Ziele, Nicht-Ziele, NLX-Flows, Metriken.“
- Planverhalten: Vor dem Schreiben immer einen Plan mit 3 Schritten vorschlagen
- Fortschrittsverhalten: Eine Statusmeldung anzeigen, wenn die Verarbeitung >5 Sekunden dauert
- Follow-ups: Anbieten, (a) ein Prompt-Set zu erzeugen, (b) eine Management-Zusammenfassung zu erstellen, (c) Evaluierungstests anzulegen
- Kontext: Darf verlinkte Dokumente und Issue-Tracker lesen; kein Abruf personenbezogener Daten (PII)
- Sicherheit: Rechtliche und medizinische Aussagen verweigern; eingeschleuste Anweisungen entfernen
Was sich im Entwicklungsprozess ändert
Dieser Wandel erzeugt laut Chennapragada einen „ungleichmäßigen Takt“ in der Produktentwicklung. Die Zeit bis zur ersten Demo ist drastisch geschrumpft, der Weg zum vollständigen Deployment kann wegen höherer Qualitätsansprüche aber sogar länger dauern.
„Die Zeit bis zur ersten Demo ist viel kürzer, aber die Zeit bis zum vollständigen Deployment wird länger“, sagte sie. Teams können mehrere Konzepte schnell ausprobieren, müssen aber strenger auswählen, welche Ideen die volle Entwicklung verdienen.
Die Fülle an leicht erstellten Prototypen legt die Latte für überzeugende Produkte höher. „Es wird ein Angebot an Ideen geben, eine massive Zunahme beim Angebot an Ideen in Prototypen, und das ist großartig. Das hebt den Boden, aber es hebt auch die Decke.“
Neue Entwicklungspraktiken
Design-Reviews bekommen NLX-Prüfpunkte: Teams müssen jetzt entscheiden, wie viel Planung sie zeigen, wie ausführlich das System sein soll und welche Follow-ups helfen und welche nur nerven. Das sind nun ausdrückliche Designentscheidungen und keine Eigenheiten des Modells mehr.
Zum Ausliefern gehören Evaluierungen: Continuous Integration kann Prompt-Tests gegen Nightly Builds laufen lassen, was besonders wichtig ist, wenn sich Modellversionen ändern. Teams brauchen systematische Wege, um das Verhalten im Gespräch zu testen.
Die Rollen verschwimmen an den Rändern: Die klassischen Grenzen zwischen Produktmanagern, Designern und Entwicklern verschieben sich, weil KI-Werkzeuge das Erstellen von Prototypen für alle zugänglich machen. Das macht redaktionelles Urteilsvermögen allerdings wichtiger, nicht weniger wichtig.
Der „Frontier“-Ansatz von Microsoft
Microsoft hat diese Haltung mit dem verankert, was Chennapragada das „Frontier-Programm“ nennt: Early Adopters bekommen die modernsten KI-Werkzeuge in die Hand, damit sie erleben, wie sich die Arbeit „ein Jahr in der Zukunft“ anfühlt.
Das Unternehmen hat sogar eine fiktive Firma eingerichtet, in der Teams mit fortgeschrittenen Research-Agenten und den neuesten Werkzeugen experimentieren können, ohne kritische Unternehmensabläufe zu stören. Damit geht Microsoft ein zentrales Problem bei der Einführung von KI im Unternehmen an: die Spannung zwischen schnellem technischem Fortschritt und sorgfältigem Change Management.
Sicherheit
Der Wechsel zu Konversationsschnittstellen bringt neue Sicherheitsprobleme mit sich. Sichtbare „Denkprozesse“ können sensiblen Kontext preisgeben, und Chain-of-Thought-Überlegungen vergrößern die Angriffsfläche für Prompt Injection und Jailbreak-Versuche.
Sicherheitsteams haben eigene Warnungen zu Reasoning-Modellen wie DeepSeek-R1 veröffentlicht. Wenn eine Prompt-Spezifikation verlangt, dass das Modell seinen Rechenweg zeigt, müssen Teams das sorgfältig eingrenzen, Zusammenfassungen den rohen Reasoning-Traces vorziehen und gegen feindselige Prompts testen.
Dazu kommt die laufende Debatte darüber, ob Modelle wirklich schlussfolgern oder nur raffinierte Mustererkennung betreiben, und was das für die Zuverlässigkeit bedeutet. Prompt-PRDs sollten ausdrücklich festlegen, wann Menschen eingebunden bleiben müssen.
Die skeptische Sicht
Nicht alle halten klassische PRDs für überholt. Kritiker wenden ein, dass umfassende Dokumentation für komplexe Unternehmenssoftware, die Einhaltung von Vorschriften und die langfristige Wartbarkeit unverzichtbar bleibt. Das Risiko von „Frankenstein-Produkten“, das Chennapragada einräumt, deutet darauf hin, dass schnelles Prototyping ohne ordentliche Planung zu unstimmigen Produkterlebnissen führen kann.
Offen bleibt auch, ob der Ansatz über kleine, experimentierfreudige Teams hinaus skaliert. Ein dreiköpfiges Team mit fortgeschrittenen KI-Werkzeugen kann schnell vorankommen, aber diese Praktiken auf größere Organisationen mit komplexem Stakeholder-Management zu übertragen, ist schwierig.
Checkliste für die Umsetzung
Für Teams, die Prompt-basierte Spezifikationen einführen wollen, hier ein praktisches Framework für den Einstieg:
- Problem & Jobs-to-be-done
- Kickoff-Prompt (Rolle, Tonfall, Guardrails)
- Planmuster (bearbeitbare Pläne vor dem Handeln)
- Fortschrittsmuster (wann und wie die Arbeit kommentiert wird)
- Follow-up-Muster (nächste Schritte je nach Kontext)
- Regeln für Quellenangaben und Konfidenz
- Kontextvertrag (Daten, Werkzeuge, Berechtigungen)
- Evaluierungssuite (automatisierte und menschliche Tests)
- Sicherheitsrichtlinie (Ablehnungen, Umgang mit Injection)
- Versionierung (Modell, Parameter, Datenindizes)
- Rollout-Strategie (zuerst Frontier-User, Logging für Modelldrift)
Ausblick
Während die Fähigkeiten von KI weiter wachsen, dürfte der Abstand zwischen Idee und Umsetzung weiter schrumpfen. Chennapragadas Vision von Prompt-Sets als Ersatz für PRDs mag heute radikal wirken, sie passt aber zum breiteren Trend zu einer unmittelbareren, erfahrungsgetriebenen Produktentwicklung.
Ob der Ansatz aufgeht, hängt davon ab, ob Teams bei schnellem Experimentieren Produktqualität und Stimmigkeit halten können. Organisationen, die bereit sind, ihre Prozesse anzupassen, winken kürzere Innovationszyklen, bessere Kommunikation im Team und Produkte, die der ursprünglichen Vision näherkommen.
Große Plattformen bauen NLX bereits in ihre Build-Abläufe ein, und Designabteilungen veröffentlichen UX-Prinzipien für Agenten, die Produktteams unverändert übernehmen können. Die Infrastruktur holt die Rhetorik ein, und genau deshalb werden Prompt-PRDs nützlich: Sie binden Gesprächskonzepte an funktionierendes Verhalten.
Ob Prompt-Sets PRDs wirklich ersetzen oder nur ergänzen, eines ist klar: Das Gespräch ist zu einer gestalteten Oberfläche geworden, die dieselbe bewusste Aufmerksamkeit braucht, die früher grafischen Oberflächen vorbehalten war. Das Memo zählt weiterhin, aber immer öfter sind die Prompts das Produkt.
Aus dem Englischen übersetzt: zum Originalbeitrag