Zum Inhalt springen
Nodary
Kostenlos starten

Vorlage für ein Produkt­anforderungs­dokument (PRD)

Sechs verlinkte Dokumente, die ein Feature vom Problem bis zum Launch begleiten: für wen es ist, was es können muss, wie der Ablauf aussieht, woran Sie den Erfolg erkennen, und jede Entscheidung unterwegs. Laden Sie sie als Markdown-Dateien herunter: Sie öffnen sich in jedem Editor, zeigen ihr Diagramm auf GitHub und in Obsidian und lassen sich als Karte in Nodary importieren.

Vorlage herunterladenLive-Demo öffnen

6 Markdown-Dateien in einem .zip, 6 kB

Kostenlos, ohne Konto und ohne E-Mail-Adresse. Nutzen, ändern und teilen Sie sie, wie Sie möchten.

ProduktanforderungsdokumentNutzer und BelegeAnforderungenDesign und AbläufeLaunch und KennzahlenEntscheidungen und offene Fragen

Lesen Sie jede Seite vor dem Download

Die Übersicht passt auf einen Bildschirm und verlinkt fünf Teile: Entwicklung, Design und Support finden jeweils ihre Seite, und eine Änderung bleibt klein. Kursive Zeilen sagen, was hineingehört; die Beispiele folgen einem einzigen Beispiel-Feature, Freigabelinks, die ablaufen.

Dokumente

Datei PRD-Vorlage/Produktanforderungsdokument.md

Produktanforderungsdokument

So nutzen Sie diese Vorlage: Kursive Zeilen sind Hinweise. Ersetzen Sie sie durch Ihre eigenen Worte und löschen Sie sie dann. Werte in eckigen Klammern füllen Sie aus. Halten Sie diese Seite auf einem Bildschirm: Sie ist das, was eilige Leser, neue Kolleginnen und KI-Agenten zuerst lesen.

Auf einen Blick

FeldDieses Feature
Feature[Name]
In einem Satz[Was Nutzer nach dem Release tun können]
Product Owner[Name]
Technische Leitung[Name]
Design-Leitung[Name]
Status[Entwurf, in Prüfung, freigegeben, ausgeliefert]
Ziel-Release[Datum oder Version]

Problem

Wer das Problem hat, was es heute kostet und woher Sie das wissen. Ein Problem ohne Beleg ist eine Vermutung: Verlinken Sie die Recherche in Nutzer und Belege.

Beispiel (ein Beispiel-Feature): Leute teilen ein Dokument zur Durchsicht mit einem Kunden und vergessen dann, dass der Link existiert. Monate später öffnet er sich immer noch. Drei Kunden fragten im letzten Quartal, wie ein Link an einem bestimmten Datum aufhört zu funktionieren.

[Das Problem in zwei oder drei Sätzen]

Ziele und Nicht-Ziele

Ziele sagen, was sich für die Nutzer ändert, nicht was das Team baut. Nicht-Ziele sind die Entscheidungen, die verhindern, dass der Umfang still wächst.

  • Ziel: [was Nutzer tun können oder nicht mehr tun müssen]
  • Ziel: [...]
  • Nicht-Ziel: [was dieses Release bewusst weglässt]
  • Nicht-Ziel: [...]

Erfolg in einer Zeile

Die eine Kennzahl, die Ihnen einen Monat nach dem Launch sagt, ob es funktioniert hat. Die vollständige Liste steht in Launch und Kennzahlen.

[Kennzahl] steigt von [Ausgangswert] auf [Zielwert] bis [Datum].

Der Rest des PRD

Jeder Teil ist ein eigenes Dokument. Verlinken Sie ihn, statt daraus zu kopieren, damit jede Tatsache an einer Stelle lebt und sich an einer Stelle ändert.

Diese Vorlage dürfen Sie frei nutzen, ändern und teilen. Sie stammt von Nodary, wo sich diese Dateien als Karte verlinkter Dokumente importieren lassen.

Vorlage herunterladen6 Markdown-Dateien in einem .zip, 6 kB

So nutzen Sie sie

  1. Erst das Problem, dann die Lösung

    Füllen Sie zuerst Problem, Ziele und Nicht-Ziele der Übersicht aus, gemeinsam mit der Entwicklerin und dem Designer, die das Feature bauen. Sind Sie sich zu dritt beim Problem nicht einig, halten Sie dort an.

  2. Jedes Muss testbar machen

    Geben Sie jeder Muss-Anforderung Abnahmekriterien, die jemand anderes prüfen kann. Eine Anforderung, die niemand testen kann, ist ein Wunsch.

  3. Prüfen lassen, dann aktuell halten

    Bitten Sie um ein Review, wenn die Anforderungen stehen, und aktualisieren Sie das PRD, wenn eine Entscheidung sie ändert. Ein PRD, das beim Kickoff stehen bleibt, ist zum Launch falsch.

  4. Festhalten, was sich geändert hat und warum

    Jede Entscheidung kommt mit ihrem Urheber ins Entscheidungsprotokoll. Fragt jemand, warum das Feature so funktioniert, ist die Antwort einen Link entfernt.

Als Karte in Nodary importieren

Nodary ist ein KI-nativer Workspace, in dem die Dokumente eines Teams verlinkt sind, statt sich zu stapeln. Importieren Sie die .zip, und das PRD kommt mit seinen fünf Teilen darunter an, die Links zwischen den Seiten bleiben erhalten und das Diagramm wird gezeichnet. Setzen Sie es auf „In Prüfung“ und bitten Sie einen Inhaber oder Admin des Arbeitsbereichs oder des Projekts um Freigabe, sehen Sie, was sich seit Ihrem letzten Besuch geändert hat, und lassen Sie per MCP verbundene KI-Agenten die Anforderungen lesen, bevor sie Code dagegen schreiben.

  1. Öffnen Sie die Karte eines Projekts und wählen Sie „Importieren“.
  2. Wählen Sie den Tab „Ordner oder ZIP“ und dann „ZIP wählen“.
  3. Wählen Sie die heruntergeladene Datei, prüfen Sie die Baumstruktur und importieren Sie.

Der Free-Plan bietet zehn Dokumente pro Workspace, die eigene Seite des Projekts eingerechnet: Die sechs der Vorlage passen in einen neuen Workspace, mit Platz für drei weitere. Nodary hat außerdem eine einseitige Vorlage für eine Produktspezifikation (PRD) eingebaut.

Nodary für Produkt- und Entwicklungsteams
Eine Live-Board-Ansicht in Nodary, die Dokumente nach Status gruppiert (Entwurf, in Prüfung, erledigt, blockiert), jede Karte mit zuständiger Person und Fälligkeitsdatum; das gezeigte Beispielprojekt ist ein Spiel.

Ein PRD schreiben, das das Team wirklich nutzt

Ein PRD scheitert auf zwei Arten: Es beschreibt eine Lösung, die niemand hinterfragt hat, oder es wird nach dem Kickoff nicht mehr aktualisiert. Diese Gewohnheiten verhindern beides.

Vom Problem ausgehen

Schreiben Sie, wer das Problem hat und was es ihn kostet, bevor es um eine Lösung geht. Teams, die sich beim Problem einig sind, streiten weniger über Screens.

Sagen, was Sie nicht tun

Nicht-Ziele sind auch Entscheidungen. Sie aufzuschreiben verhindert, dass ein Feature Woche für Woche wächst.

Anforderungen testbar machen

„Schnell“ und „einfach“ lassen sich nicht prüfen. „Der Link öffnet sich innerhalb einer Minute nach seinem Enddatum nicht mehr“ lässt sich bauen und testen.

Mit Muss, Soll und Kann priorisieren

Ein Release geht raus, wenn jedes Muss erfüllt ist. Soll und Kann sind das, was Sie tauschen, wenn der Termin näher rückt.

Belege verlinken

Jede Aussage über Nutzer verlinkt das Interview, das Ticket oder die Daten dahinter, damit ein Reviewer sie prüft, statt ihr zu glauben.

Es lebendig halten

Aktualisieren Sie das PRD, wenn eine Entscheidung es ändert, und notieren Sie, warum. Am Ende soll es beschreiben, was ausgeliefert wurde, nicht was in Woche eins geplant war.

Fragen zum PRD

Was ist ein PRD?

Ein Produktanforderungsdokument (Product Requirements Document, PRD) beschreibt ein Feature oder Produkt, bevor es gebaut wird: welches Problem es löst, für wen, was es können muss, wie Erfolg gemessen wird und was außerhalb des Umfangs liegt. Meist verantwortet es ein Product Manager; Entwicklung, Design, Support und zunehmend KI-Coding-Agenten lesen es.

Was gehört in ein PRD?

Mindestens das Problem und seine Belege, Ziele und Nicht-Ziele, die Nutzer, priorisierte Anforderungen mit Abnahmekriterien, die wichtigsten Abläufe und Grenzfälle, Erfolgskennzahlen, der Rollout-Plan sowie ein Protokoll der Entscheidungen und offenen Fragen. Diese Vorlage hat für jede Gruppe ein Dokument.

Wie lang sollte ein PRD sein?

So lang, dass das Team das Feature bauen und testen kann, ohne Ihnen dieselbe Frage zweimal zu stellen. Die Übersicht sollte auf einen Bildschirm passen; die Anforderungen wachsen mit den Entscheidungen, nicht mit den Ideen.

Was ist der Unterschied zwischen einem PRD und einem technischen Designdokument?

Das PRD sagt, was das Feature leisten muss und warum. Das technische Designdokument sagt, wie das System es leistet: Architektur, Daten, Schnittstellen und Risiken. Schreiben Sie zuerst das PRD und verlinken Sie dann beide.

Können KI-Agenten das PRD nutzen?

Ja. Ein PRD aus verlinkten Dokumenten gibt einem Agenten den nötigen Kontext. In Nodary lesen per MCP verbundene Agenten wie Claude, ChatGPT oder Cursor die Anforderungen und das Entscheidungsprotokoll mit Ihren Rechten, bevor sie schreiben.

Kann ich die Vorlage außerhalb von Nodary nutzen?

Ja. Die Dateien sind reines Markdown: Obsidian öffnet den entpackten Ordner als Vault mit funktionierenden Links, und GitHub zeigt die Dateien mit ihrem Diagramm. Werkzeuge, die Markdown Datei für Datei importieren, übernehmen Text und Tabellen; prüfen Sie, wie sie mit Links zwischen Dateien umgehen.

Weiterlesen

Halten Sie die Anforderungen dort, wo das Team arbeitet.

Importieren Sie die Vorlage in Nodary, und das PRD wird zu einer Karte, die Ihr Team und Ihre KI-Agenten aktuell halten. Kostenlos mit zwei Mitgliedern, einem Projekt und zehn Dokumenten, ohne Kreditkarte.

Kostenlos startenLive-Demo öffnenVorlage herunterladen