Was ist ein Produktanforderungsdokument (PRD)?

Ein Überblick über das prototypische Produktmanagement-Dokument

Kenton Kivestu, ex-Google, ex-BCG, Gründer bei RocketBlocks Veröffentlicht: 11. September 2019 | Zuletzt aktualisiert: 8. November 2019

PRD-Grundlagen | PRD-Inhalte | PRD-Walkthrough | PRD-Vollbeispiel

Ein PRD ist ein strukturierter Satz von Richtlinien dafür, wie ein Produkt (oder Feature) aussehen sollte.

Im Endeffekt sind PRDs die Goldlöckchen unter den Produktentwicklungsdokumenten: Es darf nicht zu sehr in den Himmel wachsen (z.B., eine Pressemitteilung), aber auch nicht zu technisch (z.B. ein detaillierter technischer Implementierungsplan).

Eine hilfreiche Art, sich ein PRD vorzustellen, ist daher das Brückendokument, das die übergeordnete Produktvision aufnimmt und so weit definiert und eingrenzt, dass ein Ingenieur daraus einen glaubwürdigen Implementierungsplan erstellen kann.

Warum machen sich Unternehmen die Mühe, PRDs zu schreiben? PRDs dienen als Eckpfeiler, der die Daseinsberechtigung eines Produkts/Features durch die Beantwortung grundlegender Fragen darlegt: Warum sollten wir es bauen? Welches Problem wird es lösen? Wie soll es aussehen? Wie wird der Erfolg aussehen?

Welche Unternehmen verwenden PRDs und wer schreibt sie? (Oben)

Außerdem variiert die bevorzugte Nomenklatur von Unternehmen zu Unternehmen (und manchmal sogar von Team zu Team!). So bezeichnet Google diese Dokumente historisch gesehen als PRDs, während die Spielefirma Zynga sie als specs bezeichnet, was eine Abkürzung für Produktspezifikationen ist.

Schließlich sind Produktmanager oft die Autoren von PRDs, aber das stimmt nicht in jedem Fall. Insbesondere in kleineren Unternehmen und Startups kann ein PRD von einem Gründer, CTO, technischen Leiter oder einer anderen Führungskraft geschrieben werden, die bei der Produktentwicklung hilft. Aber unabhängig davon, wer ein PRD verfasst, ist der Input von wichtigen funktionsübergreifenden Teammitgliedern entscheidend für die Erstellung eines guten PRD.

Welche Abschnitte und Inhalte sollten in einem PRD enthalten sein? (Oben)

Teams, die PRDs verwenden, neigen dazu, sich auf eine Liste von „Muss“-Abschnitten in einem PRD zu einigen, die für die Größe ihres Unternehmens, die Release-Kadenz, das Produktstadium und die Komplexität sinnvoll sind. Hier werden wir uns auf eine Handvoll „üblicher verdächtiger“ Abschnitte konzentrieren, die üblicherweise in vielen PRDs enthalten sind:

• Kontext & Begründung: Warum bauen wir das?
• Ziele &Erfolgsmetriken: Was ist das konkrete Ziel dieser Arbeit?
• Anwendungsfälle: welche konkreten Anwendungsfälle soll dies ermöglichen?
• Anforderungen: was muss gebaut werden?
• Offene Fragen: welche Fragen müssen beantwortet werden, bevor wir beginnen können?

Um die einzelnen Abschnitte dieser PRDs zu betrachten, stellen wir uns vor, wir schreiben ein PRD für eine kleine Ergänzung der mobilen App für Uber-Fahrer. Stellen wir uns vor, wir schreiben ein PRD, um einen kleinen Ausschnitt eines Beschreibungstextes zu der Seite hinzuzufügen, die Uber den Fahrern anzeigt, wenn sie die App nach einer abgeschlossenen Fahrt öffnen (siehe Screenshot unten).

Beispiel-PRD: Aktualisierungen der Uber-App für Fahrer (oben)

Lassen Sie uns nun einsteigen und jeden Abschnitt durchgehen und sich vorstellen, wie ein PRD aussehen könnte, das dieses Problem adressiert.

Abschnitt 1: Kontext & Begründung

Dieser Abschnitt sollte den Kernkontext darlegen, der beleuchtet, warum ein bestimmtes Feature oder Produkt in Betracht gezogen wird. Er könnte Anekdoten aus dem Support-Team, Beobachtungen aus der UX-Forschung, unterstützende Marktdaten oder Erkenntnisse des Teams darüber, in welche Richtung sich das Produkt entwickeln muss, enthalten.

Abhängig von der Kultur des Teams und dem Umfang des Features kann dieser Abschnitt recht kurz oder lang sein. Manche Unternehmen lieben es, detaillierte, hochquantitative Analysen durchzuführen, die für das Feature sprechen.

Für unser Beispiel-PRD von Uber könnten wir uns etwas wie das Folgende vorstellen:

Recent user research sessions showed that many riders often skip rating their driver on this screen because they can’t remember which driver they are rating (e.g., Viele Fahrer sehen ihren Fahrer nicht einmal von Angesicht zu Angesicht, da sie hinten sitzen).

Da Fahrerbewertungen ein wichtiger Datensatz für unsere Algorithmen und Abläufe sind, hat jeder „Anstoß“, den wir den Nutzern geben können, um Fahrer zu bewerten, eine wichtige, verstärkende Wirkung auf das Geschäft.

Abschnitt 2: Ziele &Erfolgsmetriken

Als Nächstes werden im Abschnitt „Ziele“, wenig überraschend, die spezifischen Ziele dargelegt, die durch das Feature/Produkt erreicht werden sollen. Während der Kontext-Abschnitt ein Bild davon malt, warum das Team den Aufwand für wichtig hält, sollte der Ziel-Abschnitt einen konkreten Pfahl in den Boden setzen, wie das Unternehmen / Team / Produkt davon profitieren wird und wie es gemessen werden kann.

Um auf unser Uber-PRD zurückzukommen, könnte der Zielabschnitt wie folgt aussehen:

Die Anzahl der Fahrer, die den Fahrer bewerten, wenn sie mit diesem Bewertungsbildschirm konfrontiert werden, steigt um 5 %.

Abschnitt 3: Anwendungsfälle

Anwendungsfälle beschreiben, wie Kunden mit den vorgeschlagenen Funktionsänderungen interagieren werden. Das Ziel ist es, den spezifischen Kontext zu beschreiben, in dem die Kunden die Funktion erleben werden, und wie sie ihnen helfen wird, bestimmte Aufgaben zu erledigen.

Wir kehren zu unserem Beispiel des Uber-Bewertungsbildschirms zurück:

Travis nahm kürzlich am späten Freitagabend einen Uber, nachdem er sich mit Freunden getroffen hatte. Er nutzt Uber erst wieder am nächsten Mittwoch während eines arbeitsreichen Tages. Dann öffnet er die App und sieht die Bewertung für die Fahrt am Freitagabend. Er kann sich nicht erinnern, wann er das letzte Mal mit einem Uber gefahren ist und erkennt den Fahrer nicht. Daher drückt er den „Skip“-Button, anstatt den Fahrer zu bewerten.

Abschnitt 4: Anforderungen

Dieser Abschnitt könnte als das „Fleisch“ eines PRDs betrachtet werden, in dem beschrieben wird, was tatsächlich gebaut wird. Abhängig von der jeweiligen Funktion oder dem Produkt könnte dieser Abschnitt Feature-Wireframes, Full-Fidelity-Mockups und Details darüber enthalten, welche Änderungen am Frontend (z. B. mobile Apps) und/oder am Backend (z. B. Datenbanken, Verarbeitung usw.) vorgenommen werden müssen.

Schauen wir uns an, wie dies für das Uber-Beispiel aussehen könnte:

Front-End

• Einen neuen Ausschnitt des Beschreibungstextes unter der aktuellen Bewertungsaufforderung anzeigen
• Kopieren (Beispiel): „Ihre Fahrt vom Freitagabend“

API

• Bei der Abfrage der Fahrtdetails (z.B., Fahrer, Bild des Fahrers usw.), erfassen Sie auch den Fahrtendeskriptor (Sie brauchen hier keine neue Logik zu erstellen, verwenden Sie einfach dieselben Fahrtendeskriptoren, die wir bereits in den Betreffs der per E-Mail versendeten Fahrtenquittungen verwenden, anstelle von spezifischen Zeitstempeln).

Abschnitt 5: Offene Fragen

Schließlich sind offene Fragen ein Abschnitt, der als eine Art „Parkplatz“ dient, um Fragen zu stellen, die der Autor untersuchen, eine Entscheidung treffen oder Feedback erhalten muss, bevor er das PRD als abgeschlossen betrachtet.

• Welche Farbe und Größe soll der Beschreibungstext am Bildschirm haben? Cc @design – können Sie hier die richtigen Parameter empfehlen?
• Wie granular sind die Ride-Deskriptoren, die generiert werden (z.B., werden sie spezifischer als, sagen wir, Freitagabend?)
• Wenn diese Funktion nicht die gewünschten Ergebnisse liefert, welche nächsten Schritte sollten wir in Betracht ziehen?

Alles zusammenfügen: ein vollständiges PRD-Beispiel (oben)

Wenn Sie alles, was wir besprochen haben, zusammenfügen, erhalten Sie letztendlich ein Dokument, das wie das folgende aussieht (Link zum fiktiven Dokument hier). HINWEIS: Dies ist *kein* echtes Uber-PRD – es ist ein repräsentatives, fiktives Beispiel, das auf einem plausiblen Szenario basiert.

Selbst eine extrem einfache Funktion wie die beschriebene könnte ein PRD von mehr als einer Seite erzeugen! Wie Sie sich vorstellen können, können kompliziertere Funktionen am Ende PRDs erzeugen, die viel, viel länger sind als das hier besprochene Beispiel.

Zusammenfassung: Abschließende Gedanken zum PRD

Was wir oben besprochen haben, ist eine repräsentative Momentaufnahme dessen, wie ein PRD heute aussieht.

Wie erwähnt, ist es ein repräsentatives Beispiel, aber es sollte eine richtungsweisende Vorstellung davon vermitteln, wie ein PRD aussehen könnte. Seien Sie aber nicht überrascht, wenn Sie andere Formate oder andere Arten von Inhalten darin sehen (z.B. einen Abschnitt mit Arbeitsschätzungen von einem technischen Leiter, wie lange die Erstellung dauern wird, usw.). Hier ist zum Beispiel eine großartige PRD-Vorlage, die von Kevin Yien, einem Product Lead bei Square, zusammengestellt wurde.

Schließlich werden moderne Kommunikationsplattformen und Produktivitäts-Tools wie Slack, Google Docs, Notion, Quip, Office Online, Dropbox Paper und Asana einen erheblichen Einfluss auf die Entwicklung von PRDs in den kommenden Jahrzehnten haben. Wir haben bereits gesehen, dass sich PRDs zu „lebenden“ Dokumenten entwickeln, die wichtige Mitwirkende markieren, Inline-Kommentare und Feedback einholen und zusätzliche Daten (z. B. Tabellen, Screenshots usw.) einbetten.

Allerdings wird sich eine wichtige Sache nicht ändern: die Notwendigkeit einer Art von Produktdokument, um die Stakeholder auszurichten, als High-Level-Blueprint zu dienen und die Vision in konkrete Produktanforderungen zu übersetzen.