Product requirements document prompt

When to use it

Use this when you need an initial PRD for a scoped feature and want a solid technical and operational baseline rather than an abstract outline. Swap in your own product facts, system constraints, and team metrics before taking it to engineering.

The prompt

## Role
Act as a senior product manager. Apply structured systems thinking and technical clarity while keeping documentation accessible to cross-functional teams.

## Context
BeaconHR is an internal operations platform for mid-sized healthcare clinics. Shift managers currently coordinate emergency nurse shift swaps via phone calls and physical whiteboards, causing double-bookings and delayed coverage. BeaconHR is adding a mobile-friendly "Shift Swap Requests" module. Target release is Q2 for an existing pilot group of 12 regional clinics.

## Objective
Author a comprehensive PRD specifying the end-to-end workflow for a peer-to-peer shift swap request, manager approval gate, and audit trail updates.

## Audience
The primary readers are software engineers, UI/UX designers, and clinical operations leads. Provide unambiguous logic and actionable acceptance criteria without unnecessary theory.

## Requirements
Include: problem statement; user personas (Requesting Staff, Accepting Staff, Clinic Supervisor); user stories with explicit acceptance criteria; functional specifications covering request initiation, peer acceptance, and supervisor sign-off; error handling and edge cases (e.g., overlapping shifts, expired requests); and a metrics table for feature adoption and swap turnaround time.

## Constraints
Limit scope strictly to 1:1 shift swaps within the same clinic location and role classification. Do not introduce automated schedule re-generation, payroll processing integration, cross-location transfers, or external SMS notification gateways. Work only with the stated scenario. Label all functional assumptions explicitly.

## Tone & style
Be concise, rigorous, and functional. Use unambiguous language (e.g., "must", "should") and structured markdown tables for states and edge cases. Avoid corporate buzzwords or vague generalities.

## Output format
Deliver the PRD directly under standardized product documentation headings. Place architectural assumptions and unresolved open questions in a distinct section at the end. Conclude with a checklist of dependencies for engineering and compliance sign-off.

## What to avoid
Do not assume unstated API capabilities or external vendor tools. Avoid combining functional requirements with visual design specifications. Do not omit error states or edge conditions.

## Success criteria
An engineering lead can estimate technical effort and a QA engineer can derive test cases directly from the requirements without needing to clarify core business rules.

## Clarifying questions
Ask up to three focused questions only if an ambiguity fundamentally blocks drafting the requirements. Otherwise, proceed with reasonable operational assumptions clearly marked as items for stakeholder validation.

Why it works

• The scenario gives the model concrete domain constraints and user roles instead of a vague feature idea.
• The requirements demand functional edge cases, acceptance criteria, and explicit error states often missed in early drafts.
• The constraints explicitly rule out scope creep like automated scheduling algorithms or external payroll tie-ins.
• The success criteria anchor the output to engineering readiness and testability rather than superficial completeness.

Make it yours

Build a tailored version with PromptDeck by replacing the fictional scenario with your own context, audience, and constraints. Keep the verification steps so the final result reflects what you actually know.