So schreiben Sie eine PRD, von der aus Entwickler versenden können

Die meisten Produktanforderungsdokumente scheitern aus demselben Grund: Sie beschreiben Funktionen statt Probleme und Ergebnisse. Ein Produktmanager schreibt: „Das System sollte ein Dashboard mit Diagrammen haben.“ Ein Ingenieur liest das und fragt: Welche Diagramme? Welche Daten? Für wen? Warum Diagramme anstelle einer Tabelle, eines Exports oder einer automatisierten E-Mail?

Das PRD wird zur Feature-Wunschliste. Ingenieure interpretieren es anders als vom Premierminister beabsichtigt. Scope wächst in drei Richtungen gleichzeitig. Zwei Monate später hat das Team etwas gebaut, das technisch den Spezifikationen entspricht, aber niemandes Problem löst.

Eine gute Vorlage für ein Produktanforderungsdokument leistet eines gut: Sie bietet Ingenieuren genügend Kontext, um Tausende von Mikroentscheidungen zu treffen, ohne dass sie sich für jede einzelne an den PM wenden müssen. Es antwortet mit „Warum“ vor „Was“ und „Für wen“ vor „Wie“.

Dies ist das Format, das wir verwendenSaviwährend unsererEntdeckungs- und PRD-Phase. Wir haben komplexe Produkte aus diesen Dokumenten versendet, darunterFenado KI, eine Agentenplattform, die Texteingabeaufforderungen in funktionierende Web-Apps umwandelt und derzeit 50.000 Benutzer bedient.

Die 7 Abschnitte, die Ihr PRD benötigt

Eine nützliche Dokumentvorlage für Produktanforderungen besteht aus sieben Abschnitten. Jeder Abschnitt erzwingt eine bestimmte Art von Klarheit. Wenn Sie eine davon überspringen, entsteht eine Lücke, die während der Entwicklung mit Annahmen gefüllt wird.

1. Problemstellung

Beschreiben Sie das Problem anhand einer bestimmten Person, die unter bestimmten Schmerzen leidet. Drei Fragen strukturieren diesen Abschnitt:

• Wer hat dieses Problem?Benennen Sie die Person. „Einsatzleiter bei Logistikunternehmen mit 50-200 Fahrern“ ist sinnvoll. „Benutzer“ ist es nicht.
• Wie schmerzhaft ist es?Quantifizieren Sie die Kosten. Zeitverschwendung, Geldverlust, Fehler entstehen. „Disponenten verbringen 3 Stunden pro Tag damit, Routen manuell zuzuweisen“ ist ein Problem, das es zu lösen lohnt. „Die Routenzuweisung könnte verbessert werden“ sagt den Ingenieuren nichts.
• Was machen sie jetzt?Beschreiben Sie die aktuelle Problemumgehung. Menschen lösen dieses Problem heute, auch wenn ihre Lösung langsam, manuell oder fehleranfällig ist. Das Verständnis der Problemumgehung verrät den Ingenieuren, wie „gut genug“ aussieht und wo die Messlatte liegt.

Die Problemstellung ist die Grundlage. Wenn die Ingenieure das Problem gut verstehen, können sie bessere Kompromisse bei der Konstruktion eingehen, ohne Entscheidungen zu eskalieren. Ist dies nicht der Fall, erwarten Sie für jede Unklarheit in der Spezifikation eine Slack-Nachricht.

2. Erfolgskennzahlen

Definieren Sie mit bestimmten Zahlen, wie „erledigt“ aussieht. Vage Ziele wie „Verbesserung der Benutzererfahrung“ lassen sich weder messen noch darauf aufbauen. Vergleichen Sie diese beiden:

• Vage:„Machen Sie das Onboarding schneller“
• Spezifisch:„Reduzieren Sie die Onboarding-Zeit für neue Benutzer von 3 Tagen auf 2 Stunden, indem Sie den Schritt des manuellen Datenimports eliminieren.“

Die spezifische Version sagt Ingenieuren, worauf sie sich konzentrieren müssen. Sie wissen, dass der Schritt des Datenimports der Engpass ist. Sie wissen, dass das Ziel 2 Stunden und nicht 2 Minuten sind, was sich darauf auswirkt, wie viel Automatisierung es wert ist, aufgebaut zu werden. Beziehen Sie 3 bis 5 Metriken ein. Mehr als das, und Sie optimieren für zu viele Ergebnisse auf einmal, was bedeutet, dass Sie für keines davon optimieren.

3. User Stories gruppiert nach Persona

Gruppieren Sie Geschichten nach der Person, die die Aktion ausführt, und nicht nach Themenbereich. Dies sorgt dafür, dass Ingenieure über Arbeitsabläufe statt über Bildschirme nachdenken. Eine User Story folgt dem Format:„Als [Persona] möchte ich [handeln], damit [Ergebnis] entsteht.“

Ein Beispielsatz für eine Taxibuchung SaaS:

• Passagier:„Als Passagier möchte ich vor der Buchung einen Kostenvoranschlag einholen, damit ich die Preise vergleichen kann.“
• Treiber:„Als Fahrer möchte ich den Abholort auf einer Karte sehen, damit ich navigieren kann, ohne den Passagier anzurufen.“
• Operatorin:„Als Flottenbetreiber möchte ich alle aktiven Fahrten auf einen Blick sehen, damit ich Fahrer neu zuweisen kann, wenn jemand absagt.“

Drei unterschiedliche Menschen, drei unterschiedliche Bedürfnisse, drei unterschiedliche Schnittstellen. Durch die Gruppierung nach Personen wird der häufige Fehler vermieden, einen Bildschirm zu erstellen, der versucht, alle drei zu bedienen, aber keiner von ihnen gut bedient.

4. Umfangsgrenze (was Sie NICHT bauen)

Dieser Abschnitt ist genauso wichtig wie die Funktionsliste. Die Umfangsgrenze ist eine schriftliche Vereinbarung darüber, was das Produkt in dieser Phase nicht tun wird. Ohne sie schleicht sich der Umfang vom ersten Tag an ein, da jeder Stakeholder davon ausgeht, dass sein Lieblingsmerkmal enthalten ist.

Schreiben Sie explizite Ausschlüsse:

• „Keine mobile App in Version 1. Nur Web mit responsivem Design.“
• „Keine mehrsprachige Unterstützung bis Phase 2.“
• „Zahlungen werden über die Weiterleitung von Stripe Checkout abgewickelt; kein benutzerdefinierter Zahlungsablauf.“
• „Das Admin-Panel ist nur intern; kein White-Labeling für Mieter.“

Jeder Ausschluss verhindert eine Konversation, die sonst mitten im Sprint stattfinden würde, wenn jemand sagt: „Moment, ich dachte, wir bauen das auch.“ Bringen Sie die schwierigen Entscheidungen im Voraus in das Dokument und nicht in die Standup-Liste in drei Wochen.

5. Technische Einschränkungen

Listen Sie die nicht verhandelbaren Faktoren auf, die die Art und Weise, wie das Produkt hergestellt wird, einschränken. Hierbei handelt es sich nicht um Implementierungsdetails (geben Sie hier keine Datenbanken oder Frameworks an). Hierbei handelt es sich um Geschäfts- und Compliance-Anforderungen, die das Engineering kennen muss, bevor es seinen Ansatz wählt.

• Integrationen:„Bestandsdaten müssen über RFC aus dem vorhandenen SAP-System des Kunden abgerufen werden.“ Ingenieure müssen über Abhängigkeiten von Drittanbietern Bescheid wissen, bevor sie die Datenschicht entwerfen.
• Leistung:„Das Dashboard muss mit 10.000 Datenzeilen in weniger als 2 Sekunden geladen werden.“ Diese Einschränkung bestimmt Entscheidungen über Caching, Paginierung und ob Daten vorab aggregiert werden sollen.
• Einhaltung:„Alle Patientendaten müssen im Ruhezustand und während der Übertragung verschlüsselt werden. HIPAA-Konformität erforderlich.“ Dieser eine Satz verändert den gesamten Infrastrukturansatz.
• Datenresidenz:„Benutzerdaten müssen in EU-Rechenzentren bleiben.“ Dadurch entfallen bestimmte Cloud-Anbieter und Regionen.

Technische Einschränkungen verhindern, dass das Engineering etwas baut, das im Staging funktioniert und in der Produktion scheitert, weil bis zur sechsten Woche niemand die SAP-Integration erwähnt hat.

6. Wireframes oder Benutzerflüsse

Die Wireframes müssen nicht poliert aussehen. Sie müssen klar sein. Ein Figma-Prototyp funktioniert, ebenso wie ein handgezeichnetes Diagramm, das mit einer Telefonkamera fotografiert wurde. Entscheidend ist, dass das Dokument zeigt, wie sich ein Benutzer Bildschirm für Bildschirm durch das System bewegt.

Fügen Sie mindestens Folgendes ein:

• Der glückliche Weg für jede Persona (der erwartete Fluss, wenn nichts schief geht)
• Fehlerzustände und Grenzfälle (was passiert, wenn die Zahlung fehlschlägt, wenn Daten fehlen, wenn der Benutzer die Verbindung verliert)
• Der Einstiegspunkt (wie trifft der Benutzer zum ersten Mal auf diese Funktion?)

Benutzerflüsse offenbaren Komplexität, die Textbeschreibungen verbergen. Sie können einen Checkout-Prozess in zwei Sätzen beschreiben. Wenn Sie es zeichnen, stellen Sie fest, dass es sieben Bildschirme, drei Verzweigungspfade und zwei Integrationspunkte gibt. Dieses Bild erzwingt eine ehrliche Einschätzung.

7. Meilensteine ​​mit Akzeptanzkriterien

Teilen Sie das Projekt in Meilensteine ​​von zwei bis vier Wochen auf. Jeder Meilenstein liefert ein funktionierendes Inkrement, das die Beteiligten sehen und testen können. Schreiben Sie für jeden Meilenstein Akzeptanzkriterien auf, die binär sind: bestanden oder nicht bestanden, erledigt oder nicht erledigt.

• Meilenstein 1 (Woche 1-2):Der Benutzer kann sich registrieren, anmelden und ein leeres Dashboard sehen. Akzeptanz: Der Authentifizierungsablauf funktioniert mit E-Mail/Passwort und Google OAuth. Das Dashboard wird mit Zero-State-Messaging gerendert.
• Meilenstein 2 (Woche 3-4):Der Benutzer kann Projekte erstellen und bearbeiten. Akzeptanz: CRUD-Operationen funktionieren. Die Formularvalidierung erkennt leere Felder und doppelte Namen. Die Daten bleiben sitzungsübergreifend bestehen.
• Meilenstein 3 (Woche 5–6):Der Benutzer kann Teammitglieder einladen und Rollen zuweisen. Annahme: Einladungs-E-Mail wird innerhalb von 30 Sekunden versendet. Eingeladene Benutzer können das Projekt akzeptieren und mit den richtigen Berechtigungen darauf zugreifen.

Meilensteine ​​schaffen natürliche Kontrollpunkte für Kurskorrekturen. Wenn Meilenstein 2 vier statt zwei Wochen dauert, wissen Sie es, bevor Meilenstein 3 beginnt. Sie können den Umfang, den Zeitplan oder das Budget anpassen, bevor die Verbindungen überschritten werden.

Häufige Fehler, die eine PRD zerstören

40 Seiten schreiben, die niemand liest

Wenn Ihr PRD länger als 10 Seiten ist, überfliegen Ingenieure es. Sie lesen den ersten Abschnitt, springen zu dem Teil, der für ihren Sprint relevant ist, und verpassen den Kontext, der ihre Arbeit mit den Produktzielen verbindet. Ein prägnantes Dokument, das gelesen wird, übertrifft ein umfassendes Dokument, das in Google Drive gespeichert ist. Streben Sie 5 bis 10 Seiten mit Links zu ergänzendem Material (Wireframes, Forschungsdaten, Wettbewerbsanalysen) für Personen an, die Tiefe wünschen.

Angabe der Implementierungsdetails

Ein PRD sollte beschreiben, was das Produkt tut und warum. Es sollte nicht angegeben werden, dass das Backend PostgreSQL mit einem bestimmten Schema verwendet oder dass das Frontend React mit Redux verwendet. Das sind technische Entscheidungen, die dem Ingenieurteam obliegen. Wenn ein Produktmanager Implementierungsdetails spezifiziert, passieren zwei Dinge: Ingenieure fühlen sich mikroverwaltet und das Produkt wird an technische Entscheidungen gebunden, die ohne vollständigen technischen Kontext getroffen werden. Geben Sie die Einschränkung an („muss 10.000 gleichzeitige Benutzer verarbeiten“) und lassen Sie die Ingenieure die Tools auswählen.

Keine Bereichsgrenze

Das ist der teuerste Fehler. Ohne eine schriftliche Abgrenzung des Umfangs nehmen die Beteiligten unterschiedliche Ansichten darüber an, was enthalten ist. Der CEO erwartet eine mobile App. Der VP of Sales erwartet eine CRM-Integration. Der Premierminister erwartete weder das eine noch das andere. Als diese Annahmen auftauchen, hat das Team drei Wochen damit verbracht, in die falsche Richtung zu streben. Schreiben Sie auf, was ausgeschlossen ist. Lassen Sie sich die Ausschlüsse genehmigen. Verweisen Sie auf sie, wenn jemand fragt: „Können wir auch hinzufügen?“

Funktionen auflisten, ohne zu erklären, warum

„Das System sollte über ein Benachrichtigungscenter verfügen.“ Warum? Wer wird benachrichtigt? Worüber? Wie dringend sind diese Benachrichtigungen? Muss der Benutzer darauf reagieren oder dienen sie der Information? Eine Funktion ohne „Warum“ wird nach der Interpretation des Ingenieurs erstellt, die möglicherweise nicht den Anforderungen des Benutzers entspricht. Verknüpfen Sie Funktionen mit User Stories und Erfolgskennzahlen. Wenn eine Funktion keiner User Story zugeordnet ist, fragen Sie sich, ob sie in diese Phase gehört.

Dokumentvorlage für Produktanforderungen

Kopieren Sie diese Vorlage und füllen Sie sie für Ihr nächstes Projekt aus. Jeder Abschnitt enthält Hinweise, die Sie beim Schreiben unterstützen.

Wie Savi PRDs in der Discovery- und PRD-Phase verwendet

Wenn Sie ein Projekt mit startenSavi, der zweite Schritt in unseremVerfahrenist Discovery & PRD. Wir definieren gemeinsam Umfang, Features und technische Architektur. Sie erhalten ein detailliertes Produktanforderungsdokument mit Meilensteinen und Preisen, bevor Code geschrieben wird.

Dies ist keine Formalität. Der PRD ist der Vertrag zwischen dem, was Sie erwarten, und dem, was wir bauen. Jedes Feature, jeder Meilenstein und jedes Akzeptanzkriterium im PRD wird zu einem Einzelposten im Projektplan. Wenn während der Entwicklung eine Frage auftaucht, überprüfen wir zuerst die PRD und sprechen dann darüber. Dadurch verkürzt sich die Rückkopplungsschleife von Tagen auf Minuten.

Folgendes deckt unser Discovery- und PRD-Prozess ab:

• Problemvalidierung:We challenge your assumptions. Wenn das von Ihnen beschriebene Problem nicht mit der Erfahrung Ihrer Benutzer übereinstimmt, ist es schlimmer, schnell die falsche Lösung zu entwickeln, als langsam die richtige Lösung zu entwickeln.
• Umfangsverhandlung:Wir arbeiten durch, was in Version 1 gehört und was warten sollte. FürFenado KIDies bedeutete, mit der Generierung einer Single-Page-App zu beginnen und dann auf die Full-Stack-Ausgabe mit Datenbankschemata und API-Routen zu erweitern. The first version proved the core value; the second version expanded on it.
• Technische Architekturskizze:Vor der Schätzung skizzieren wir die Systemarchitektur. Dadurch werden Warnsignale frühzeitig erkannt: Integrationskomplexität, Leistungsengpässe, Compliance-Anforderungen, die den Infrastrukturansatz verändern.
• Meilensteine ​​zum Festpreis:Each milestone in the PRD maps to a fixed price. Sie wissen, was Sie für die einzelnen Leistungen bezahlen, bevor mit der Entwicklung begonnen wird. Keine Überraschungen bei der Stundenabrechnung, keine unbefristeten Zeitpläne.

Die Discovery- und PRD-Phase dauert 3 bis 5 Werktage. Das Ergebnis ist ein Dokument, das Sie jedem Ingenieurteam übergeben können, nicht nur unserem, und es verfügt über genügend Kontext zum Schätzen, Planen und Bauen. Das ist der Test für ein gutes PRD: Kann ein kompetenter Ingenieur, der noch nie mit Ihnen gesprochen hat, dieses Dokument lesen und das richtige Produkt bauen?

Das Schreiben des PRD ist die erste technische Entscheidung

Das PRD ist kein Dokument, das Sie vor Beginn der Entwicklung schreiben. Es ist die erste technische Entscheidung. Die Qualität Ihres Produktanforderungsdokuments bestimmt, ob Ihr Team seine Zeit damit verbringt, das Produkt zu entwickeln oder darüber zu diskutieren, wie das Produkt aussehen soll.

Nutzen Sie die sieben Abschnitte. Seien Sie bei jedem einzelnen konkret. Schreiben Sie auf, was Sie nicht bauen. Definieren Sie Erfolg mit Zahlen. Und wenn Sie auf einen Abschnitt stoßen, den Sie nicht ausfüllen können, ist das das Signal, mehr zu recherchieren, bevor Sie weiteren Code schreiben.

Ein fünfseitiges PRD, das die richtigen Fragen beantwortet, ist besser als ein vierzigseitiges PRD, das die falschen Fragen beantwortet.

Häufig gestellte Fragen