Product Requirement Document (PRD)
Formales Dokument, das Produktziele, Nutzeranforderungen und Akzeptanzkriterien beschreibt.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypOrganisation
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Veraltete Anforderungen führen zu Fehlentwicklungen.
- Über-Spezifikation hemmt Innovation und technische Lösungen.
- Unklare Ownership verursacht Verzögerungen und Konflikte.
- Kurz und fokussiert schreiben; Umfang auf notwendige Entscheidungen begrenzen.
- Annahmen und offene Fragen sichtbar dokumentieren.
- Regelmäßige Überprüfung und Versionierung des PRD einplanen.
I/O & Ressourcen
- Produktvision und Strategie
- Nutzerforschung und Marktdaten
- Technische Randbedingungen und Integrationsanforderungen
- Priorisierte Anforderungen mit Akzeptanzkriterien
- Erfolgskriterien und Metriken
- Abhängigkeiten und Risikobewertung
Beschreibung
Ein Product Requirement Document (PRD) fasst Produktziele, Nutzerbedürfnisse, Prioritäten und Akzeptanzkriterien in einer strukturierten Form zusammen. Es dient als Kommunikations- und Entscheidungsgrundlage zwischen Produktmanagement, Entwicklung und Stakeholdern. Ein gutes PRD macht Annahmen sichtbar, reduziert Missverständnisse und lenkt Umsetzungsentscheidungen. Es unterstützt Roadmap-Planung und Risikoabschätzung.
✔Vorteile
- Verbesserte Abstimmung zwischen Produkt, Design und Entwicklung.
- Weniger Missverständnisse und Nacharbeit durch klare Akzeptanzkriterien.
- Bessere Entscheidungsgrundlage für Prioritäten und Roadmap.
✖Limitationen
- Kann zu ausführlich und damit träge werden, wenn zu detailliert.
- Qualität hängt stark von Stakeholder-Verfügbarkeit und Input ab.
- Nicht alle Unsicherheiten lassen sich vorab vollständig spezifizieren.
Trade-offs
Metriken
- Time-to-implement
Zeit zwischen PRD-Freigabe und ausgelieferter Funktion.
- Anzahl Nachfragen
Anfragen der Entwicklung zu unklaren Punkten im PRD.
- Erfolgsquote der Akzeptanztests
Anteil implementierter Features, die Abnahmekriterien erfüllen.
Beispiele & Implementierungen
MVP-Start eines Startups
Kleines PRD fokussiert auf Kernnutzen und schnelle Validierung am Markt.
B2B-Onboarding-Optimierung
PRD definiert Anforderungen für Integrationen, SLAs und Messgrößen.
Feature-Änderung wegen Compliance
Erweitertes PRD mit regulatorischen Vorgaben und Abnahmeschritten.
Implementierungsschritte
Stakeholder identifizieren und Ziele abgleichen
Nutzerbedürfnisse und Randbedingungen dokumentieren
Anforderungen priorisieren, Akzeptanzkriterien definieren und PRD freigeben
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unklare Integrationsanforderungen führen zu Nacharbeiten.
- Nicht berücksichtigte Skalierungsanforderungen müssen später adressiert werden.
- Fehlende Testkriterien erhöhen QA-Aufwand im Betrieb.
Bekannte Engpässe
Beispiele für Missbrauch
- PRD als reines Vertragsdokument gegenüber Entwicklung nutzen.
- Alle Details früh festlegen und keine Anpassungen erlauben.
- Stakeholder-Feedback ignorieren und das Dokument starr durchsetzen.
Typische Fallen
- Zu spät mit technischem Feedback einholen; technische Schulden entstehen.
- Widersprüchliche Anforderungen durch fehlende Priorisierung.
- Akzeptanzkriterien unklar formuliert, Tests nicht möglich.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Budget- und Zeitvorgaben
- • Regulatorische Anforderungen
- • Technische Plattformgrenzen