Product Requirements Document

Bevor eine Firma eine neue App oder Funktion baut, schreibt jemand auf, was dabei herauskommen soll. Genau das ist ein Product Requirements Document, meist mit PRD abgekürzt. Darin steht, welches Problem das Produkt löst, für welche Nutzergruppe es gedacht ist und woran man später erkennt, ob es funktioniert. Es ist kein Bauplan für Programmierer, sondern eine Beschreibung des Ziels. Man kann es sich wie die Aufgabenstellung für ein Referat vorstellen: Das Thema und die Anforderungen stehen fest, wie man sie erfüllt, bleibt offen. Geschrieben wird ein PRD meist von einer Person, die im Unternehmen Produktmanagement macht.

Ein Dokument gegen das Aneinandervorbeireden

An einem Produkt arbeiten selten nur zwei Leute. Es gibt Entwicklerinnen, Designer, Leute aus dem Verkauf und oft noch die Rechtsabteilung. Jede dieser Gruppen hat eine eigene Vorstellung davon, was gebaut wird. Ohne gemeinsames Dokument entstehen Missverständnisse, die erst nach Monaten auffallen.

Ein PRD zwingt zu einer Entscheidung, bevor Geld ausgegeben wird. Änderungen an einem Textdokument kosten eine Stunde. Änderungen an fertigem Code kosten Wochen. Deshalb gilt in vielen Firmen die Faustregel, dass Nachdenken vorne billiger ist als Nachbessern hinten.

Ebenso wichtig ist, was ein PRD ausschließt. Ein guter Abschnitt heißt „Nicht im Umfang“ und listet auf, was ausdrücklich nicht gebaut wird. Ohne diese Grenze wächst ein Projekt immer weiter, ein Effekt, den man Scope Creep nennt: Das Vorhaben schwillt durch ständige kleine Zusatzwünsche an, bis kein Termin mehr hält.

Was in einem PRD tatsächlich drinsteht

Ein typisches PRD beginnt mit dem Problem und dem Ziel. Danach folgen die Nutzergruppen, oft in Form kurzer Beispielpersonen. Der Hauptteil besteht aus User Stories, also Sätzen nach dem Muster: „Als Nutzer möchte ich mein Passwort zurücksetzen, damit ich wieder Zugang bekomme.“ Jede dieser Anforderungen ist so formuliert, dass man nachprüfen kann, ob sie erfüllt ist.

Dazu kommen Erfolgskennzahlen. Statt „die Suche soll besser werden“ steht dort etwa: „80 Prozent der Suchanfragen liefern innerhalb von 300 Millisekunden ein Ergebnis.“ Solche Zahlen machen aus einem Wunsch eine überprüfbare Aussage. Häufig ergänzen Skizzen der Benutzeroberfläche und offene Fragen das Dokument.

Ein verbreiteter Irrtum ist, ein PRD sei nach dem Schreiben fertig. In der Praxis wird es laufend überarbeitet, weil neue Erkenntnisse dazukommen. Abzugrenzen ist es vom technischen Design-Dokument, das die Entwicklerinnen selbst schreiben. Das PRD sagt, was gebaut wird, das Design-Dokument sagt, wie.

PRDs bei Tech-Konzernen und in KI-Werkzeugen

Praktisch jedes größere Softwareunternehmen arbeitet mit PRDs, von Google über SAP bis zu kleinen Start-ups. Wenn in Wirtschaftsnachrichten steht, ein Konzern habe eine Funktion „gestrichen“, steckt dahinter oft ein PRD, das nie freigegeben wurde. Auch Bewerbungsgespräche im Produktmanagement drehen sich häufig um solche Dokumente.

Seit einigen Jahren werden PRDs auch mit KI erstellt. Sprachmodelle wie ChatGPT liefern auf Zuruf einen ersten Entwurf, den Menschen anschließend korrigieren. Manche Entwicklungswerkzeuge gehen weiter und erzeugen aus einem PRD direkt erste Programmteile. Der Nutzen bleibt begrenzt, wenn die Anforderungen unklar sind: Ein vages Dokument führt zu vagem Ergebnis, egal ob Mensch oder Maschine es umsetzt.