Prompt für ein Product Requirements Document (PRD)

Wann dieser Prompt zum Einsatz kommt

Verwenden Sie diesen Prompt, wenn Sie ein initiales PRD für ein abgegrenztes Feature benötigen und eine solide technische sowie operative Grundlage statt einer abstrakten Gliederung wünschen. Passen Sie vor der Übergabe an das Engineering-Team einfach Ihre eigenen Produktdaten, Systemgrenzen und Team-Metriken an.

Der Prompt

## Rolle
Agiere als Senior Product Manager. Wende strukturiertes Systemdenken und technische Klarheit an und halte die Dokumentation gleichzeitig für cross-funktionale Teams zugänglich.

## Kontext
BeaconHR ist eine interne Betriebs- und Personalplattform für mittelgroße Gesundheitskliniken. Schichtleiter koordinieren kurzfristige Schichttausche von Pflegekräften derzeit über Telefonanrufe und physische Whiteboards, was zu Doppelbelegungen und verzögerter Schichtabdeckung führt. BeaconHR führt ein mobilfreundliches Modul für „Schichttauschanfragen“ ein. Der geplante Rollout ist für Q2 bei einer bestehenden Pilotgruppe von 12 regionalen Kliniken angesetzt.

## Ziel
Verfasse ein umfassendes PRD, das den End-to-End-Workflow für eine Peer-to-Peer-Schichttauschanfrage, den Genehmigungsschritt durch den Schichtleiter und die Aktualisierung des Audit-Trails spezifiziert.

## Zielgruppe
Die primären Leser sind Software-Engineers, UI/UX-Designer und Clinical-Operations-Leiter. Liefere eindeutige Logik und umsetzbare Akzeptanzkriterien ohne unnötigen theoretischen Ballast.

## Anforderungen
Enthalten sein müssen: Problemstellung; User Personas (Anfragende Fachkraft, Annehmende Fachkraft, Schichtleiter/Supervisor); User Stories mit expliziten Akzeptanzkriterien; funktionale Spezifikationen für Anfrageinitiierung, Peer-Akzeptanz und Supervisor-Freigabe; Fehlerbehandlung und Edge Cases (z. B. überschneidende Schichten, abgelaufene Anfragen); sowie eine Metrik-Tabelle für Feature-Adoption und Bearbeitungszeit des Tauschs.

## Einschränkungen
Beschränke den Scope strikt auf 1:1-Schichttausche innerhalb desselben Klinikstandorts und derselben Rollenklassifizierung. Führe keine automatisierte Neu-Erstellung von Dienstplänen, keine Integration in die Lohnabrechnung, keine standortübergreifenden Transfers und keine externen SMS-Notification-Gateways ein. Arbeite ausschließlich mit dem genannten Szenario. Kennzeichne alle funktionalen Annahmen explizit.

## Tonalität & Stil
Präzise, fundiert und funktional. Nutze unmissverständliche Sprache (z. B. „muss“, „sollte“) und strukturierte Markdown-Tabellen für Systemzustände und Edge Cases. Vermeide Corporate-Buzzwords oder vage Verallgemeinerungen.

## Ausgabeformat
Liefere das PRD direkt unter standardisierten Produkt-Dokumentationsüberschriften. Platziere Architekturannahmen und ungelöste offene Fragen in einem separaten Abschnitt am Ende. Schließe mit einer Checkliste von Abhängigkeiten für die finale Freigabe durch Engineering und Compliance ab.

## Was zu vermeiden ist
Nimm keine ungenannten API-Fähigkeiten oder externen Drittanbieter-Tools an. Vermische keine funktionalen Anforderungen mit visuellen Designspezifikationen. Lass keine Fehlerzustände oder Randbedingungen aus.

## Erfolgskriterien
Ein Engineering Lead kann den technischen Aufwand schätzen und ein QA-Engineer kann Testfälle direkt aus den Anforderungen ableiten, ohne grundlegende Geschäftsregeln nachfragen zu müssen.

## Klärungsfragen
Stelle maximal drei gezielte Fragen, falls eine Unklarheit das Verfassen der Anforderungen grundlegend blockiert. Fahre andernfalls mit plausiblen operativen Annahmen fort, die eindeutig als Punkte für die Stakeholder-Validierung gekennzeichnet sind.

Warum er funktioniert

• Das Szenario gibt dem Modell konkrete Domänenbeschränkungen und Benutzerrollen vor, anstatt einer vagen Feature-Idee.
• Die Anforderungen verlangen funktionale Edge Cases, Akzeptanzkriterien und explizite Fehlerzustände, die in frühen Entwürfen oft übersehen werden.
• Die Einschränkungen schließen Scope Creep – wie automatisierte Planungsalgorithmen oder externe Lohnbuchhaltungsanbindungen – explizit aus.
• Die Erfolgskriterien koppeln die Ausgabe an technische Machbarkeit und Testbarkeit statt an oberflächliche Vollständigkeit.

An Ihre Anforderungen anpassen

Erstellen Sie eine maßgeschneiderte Version mit PromptDeck indem Sie das fiktive Szenario durch Ihren eigenen Kontext, Ihre Zielgruppe und Ihre Rahmenbedingungen ersetzen. Behalten Sie die Verifizierungsschritte bei, damit das Endergebnis exakt Ihren realen Gegebenheiten entspricht.