# Vorlage für ein Produktanforderungsdokument (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.

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

[Vorlage herunterladen (.zip)](https://nodary.ai/downloads/prd-vorlage.zip)

## 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.

- Produktanforderungsdokument: Die Seite, die alle zuerst lesen: das Problem, die Ziele, was dazugehört und was nicht, und ein Link zu jedem Teil.
- Nutzer und Belege: Für wen das Feature ist, was diese Menschen heute ohne es tun, und die Recherche hinter dem Problem.
- Anforderungen: Was das Feature können muss, jede Anforderung mit ihrer Priorität und der Prüfung, die sie belegt.
- Design und Abläufe: Wie Nutzer sich durch das Feature bewegen: der Ablauf, die Screens, die Zustände und die Grenzfälle.
- Launch und Kennzahlen: Woran Sie erkennen, dass es funktioniert hat, wie es ausgerollt wird, und was Sie zum Zurückrollen bringen würde.
- Entscheidungen und offene Fragen: Jede Entscheidung, die das PRD geändert hat, mit wer und warum, und die Fragen, die noch offen sind.

### 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

| Feld | Dieses 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](https://nodary.ai/de/templates/prd#doc-users).

_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](https://nodary.ai/de/templates/prd#doc-launch).

[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._

- [Nutzer und Belege](https://nodary.ai/de/templates/prd#doc-users): für wen das Feature ist, und die Recherche hinter dem Problem
- [Anforderungen](https://nodary.ai/de/templates/prd#doc-requirements): was es können muss, mit Prioritäten und Abnahmekriterien
- [Design und Abläufe](https://nodary.ai/de/templates/prd#doc-design): der Ablauf, die Screens, die Zustände und die Grenzfälle
- [Launch und Kennzahlen](https://nodary.ai/de/templates/prd#doc-launch): Kennzahlen, Rollout und Launch-Checkliste
- [Entscheidungen und offene Fragen](https://nodary.ai/de/templates/prd#doc-decisions): was wer warum entschieden hat, und was noch offen ist

_Diese Vorlage dürfen Sie frei nutzen, ändern und teilen. Sie stammt von_ [Nodary](https://nodary.ai/de)_, wo sich diese Dateien als Karte verlinkter Dokumente importieren lassen._

### Nutzer und Belege

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Für wen das Feature ist und was Sie über diese Menschen wissen. Jede Aussage hier sollte auf ihre Quelle verweisen._

#### Für wen

| Wer | Was sie erreichen wollen | Was im Weg steht |
| --- | --- | --- |
| [Hauptnutzer] | [...] | [...] |
| [Weitere Nutzer] | [...] | [...] |

_Beispiel (ein Beispiel-Feature): Ein Account Manager teilt einen Angebotsentwurf eine Woche lang zur Kommentierung mit einem Kunden. Heute stellt er sich eine Erinnerung, um den Link abzuschalten, und vergisst es manchmal._

#### Heute, ohne das Feature

_Was Nutzer heute tun, Schritt für Schritt, Workarounds eingeschlossen. Der Workaround ist oft die beste Spezifikation, die Sie bekommen._

1. [Schritt]
2. [Schritt]
3. [Workaround]

#### Belege

| Quelle | Was sie sagt | Datum | Link |
| --- | --- | --- | --- |
| [Kundeninterview] | [...] | [Datum] | [...] |
| [Support-Tickets] | [...] | [...] | [...] |
| [Nutzungsdaten] | [...] | [...] | [...] |

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Produktanforderungsdokument](https://nodary.ai/de/templates/prd#doc-overview) · [Anforderungen](https://nodary.ai/de/templates/prd#doc-requirements) · [Design und Abläufe](https://nodary.ai/de/templates/prd#doc-design)

### Anforderungen

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Eine Zeile pro Anforderung, geschrieben als etwas, das Nutzer tun können. Die Priorität ist Muss, Soll oder Kann: Ein Release geht raus, wenn jedes Muss erfüllt ist._

#### User Stories

| ID | Als | möchte ich | damit | Priorität |
| --- | --- | --- | --- | --- |
| A1 | [Nutzer] | [...] | [...] | [Muss, Soll, Kann] |
| A2 | [...] | [...] | [...] | [...] |
| A3 | [...] | [...] | [...] | [...] |

_Beispiel (ein Beispiel-Feature): A1. Als Person, die ein Dokument teilt, möchte ich den Tag wählen, an dem ein Link aufhört zu funktionieren, damit ein Kunde den Zugang verliert, wenn das Projekt endet. Muss._

#### Abnahmekriterien

_Für jedes Muss die Prüfungen, die belegen, dass es funktioniert. Schreiben Sie sie so, dass ein Tester oder ein KI-Agent sie durchführen kann, ohne Sie zu fragen._

| Anforderung | Gegeben | Wenn | Dann |
| --- | --- | --- | --- |
| A1 | [eine Ausgangslage] | [eine Aktion] | [das prüfbare Ergebnis] |
| A1 | [...] | [...] | [...] |

#### Nicht-funktionale Anforderungen

| Bereich | Anforderung |
| --- | --- |
| Performance | [...] |
| Sicherheit und Datenschutz | [...] |
| Barrierefreiheit | [...] |
| Sprachen | [...] |
| Kompatibilität | [Browser, Geräte, Versionen] |

#### Nicht im Umfang

- [Was dieses Release nicht tut, und warum]
- [...]

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Nutzer und Belege](https://nodary.ai/de/templates/prd#doc-users) · [Design und Abläufe](https://nodary.ai/de/templates/prd#doc-design) · [Launch und Kennzahlen](https://nodary.ai/de/templates/prd#doc-launch)

### Design und Abläufe

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Verlinken Sie die Designdateien, statt sie einzufügen. Halten Sie hier den Ablauf und die Entscheidungen dahinter fest, damit Text und Screens sich nie widersprechen._

#### Nutzerablauf

_Der Hauptweg, vom Einstieg bis zu dem, was Nutzer erhalten. Kann das Team ihn nicht zeichnen, ist er noch nicht entschieden._

```mermaid
flowchart LR
  n0["Einstieg"]
  n1["Erste Aktion"]
  n2["Wichtige Wahl"]
  n3["Bestätigung"]
  n4["Ergebnis"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
```
_Der Hauptablauf, von [wo Nutzer starten] bis [was sie erhalten]_

#### Screens

| Screen | Zweck | Designlink | Status |
| --- | --- | --- | --- |
| [Screen] | [...] | [...] | [Skizze, Mockup, final] |
| [Screen] | [...] | [...] | [...] |

#### Zustände

_Jeder Screen hat mehr Zustände als den Normalfall. Haken Sie jeden ab, sobald er gestaltet ist, oder schreiben Sie, warum er nicht vorkommen kann._

- [ ] Leer: noch nichts zu zeigen
- [ ] Laden
- [ ] Fehler, mit dem, was Nutzer als Nächstes tun können
- [ ] Keine Berechtigung
- [ ] Langsame oder verlorene Verbindung
- [ ] Sehr langer Text und sehr große Zahlen

#### Grenzfälle

| Fall | Was passiert |
| --- | --- |
| [...] | [...] |
| [...] | [...] |

_Beispiel (ein Beispiel-Feature): Jemand öffnet einen Link eine Minute nach seinem Enddatum: Er sieht, dass der Link abgelaufen ist und wen er fragen kann, nie eine Fehlerseite._

#### Offene Fragen

- [ ] [Frage], [wer sie beantwortet], [bis wann]

Siehe auch: [Anforderungen](https://nodary.ai/de/templates/prd#doc-requirements) · [Launch und Kennzahlen](https://nodary.ai/de/templates/prd#doc-launch)

### Launch und Kennzahlen

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Eine Hauptkennzahl, zwei oder drei Nebenkennzahlen und eine Leitplanke: etwas, das nicht schlechter werden darf, während die Hauptkennzahl steigt._

#### Kennzahlen

| Kennzahl | Art | Ausgangswert | Ziel | Gemessen mit | Prüfdatum |
| --- | --- | --- | --- | --- | --- |
| [...] | [Haupt] | [...] | [...] | [...] | [Datum] |
| [...] | [Neben] | [...] | [...] | [...] | [...] |
| [...] | [Leitplanke] | [...] | [...] | [...] | [...] |

#### Rollout

| Stufe | Wer es bekommt | Datum | Weiter, wenn |
| --- | --- | --- | --- |
| [Intern] | [das Team] | [...] | [...] |
| [Beta] | [...] | [...] | [...] |
| [Alle] | [...] | [...] | [...] |

#### Launch-Checkliste

- [ ] Hilfeartikel geschrieben
- [ ] Support-Team informiert
- [ ] Release Notes entworfen
- [ ] Analytics-Events geprüft
- [ ] Zurückrollen getestet

#### Zurückrollen

_Was Sie dazu bringen würde, das Feature abzuschalten, und wie. Entscheiden Sie es vor dem Launch, solange noch niemand am Ergebnis hängt._

- Wir rollen zurück, wenn: [...]
- Wie: [ein Flag, ein Release, ein Skript]
- Wer entscheidet: [Name]

Siehe auch: [Produktanforderungsdokument](https://nodary.ai/de/templates/prd#doc-overview) · [Anforderungen](https://nodary.ai/de/templates/prd#doc-requirements) · [Entscheidungen und offene Fragen](https://nodary.ai/de/templates/prd#doc-decisions)

### Entscheidungen und offene Fragen

**Verantwortlich:** [Name] · **Status:** Entwurf · **Zuletzt geprüft:** [Datum]

_Wenn eine Entscheidung das PRD ändert, fügen Sie hier eine Zeile hinzu und aktualisieren die betroffene Seite. Das Protokoll sagt, warum; die Seite sagt, was jetzt gilt._

#### Entscheidungsprotokoll

| Datum | Entscheidung | Entschieden von | Warum | Geänderte Seite |
| --- | --- | --- | --- | --- |
| [Datum] | [...] | [...] | [...] | [...] |

_Beispiel (ein Beispiel-Feature): Links funktionieren bis zum Ende ihres letzten Tages in der Zeitzone ihres Eigentümers, nicht bis Mitternacht UTC. Entschieden von Product Owner und technischer Leitung, weil Kunden in anderen Zeitzonen in der Beta einen Tag zu früh den Zugang verloren. Geänderte Seite: Anforderungen._

#### Offene Fragen

| Frage | Wer sie beantwortet | Bis wann | Antwort |
| --- | --- | --- | --- |
| [...] | [Name] | [Datum] | [...] |

Siehe auch: [Produktanforderungsdokument](https://nodary.ai/de/templates/prd#doc-overview) · [Anforderungen](https://nodary.ai/de/templates/prd#doc-requirements) · [Launch und Kennzahlen](https://nodary.ai/de/templates/prd#doc-launch)

## So nutzen Sie sie

### 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.

### 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.

### 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.

### 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.

## 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.

Die Seite: https://nodary.ai/de/templates/prd