Product requirements document
Turn a product idea into testable outcomes, non-goals, stories, metrics, and rollout constraints.
Read this prompt as Markdown or plain text
When to use it
Traceability from goals through metrics prevents the PRD from becoming a feature wish list and makes later scope and launch decisions inspectable.
Prompt
Write a product requirements document for [PRODUCT OR FEATURE]. Use the supplied research, user feedback, analytics, and technical context as evidence. If evidence is missing, ask only questions that materially change scope; otherwise state assumptions and continue. Never invent customer quotes, market facts, or metrics. Include: 1. Executive summary and the user problem 2. Target users and jobs to be done 3. Evidence and current baseline 4. Goals as measurable outcomes, plus non-goals 5. User journeys and prioritized user stories 6. Functional requirements with unique IDs 7. Non-functional requirements: accessibility, performance, privacy, security, reliability, and supportability 8. Dependencies, constraints, edge cases, and failure states 9. Analytics events, success metrics, guardrail metrics, and decision thresholds 10. Rollout stages, experiment or validation plan, rollback triggers, and support readiness 11. Risks, open questions, and named decision owners where known Every requirement must have testable acceptance criteria. Use Given/When/Then only where it improves precision. Include a traceability table connecting goals → requirements → acceptance criteria → metrics. Finish with the smallest viable release, what evidence would justify expansion, and what evidence would cause the team to stop or revise the plan.
Adapt it to your task
Condensed and made evidence-first from GitHub Awesome Copilot's Create PRD Chat Mode.
Third-party prompt. Source review does not establish benchmark performance or guarantee an outcome.
Source and license
Contributor: @aaronpowell. Repository: github/awesome-copilot.
License: MIT. Pinned commit: b95e24caae4f25c5985f8527fd092ccfed039c36.
Review: source-reviewed, . Compared with the commit-pinned source and adapted into a tool-neutral, copy/paste request. This is a non-visual task, so no output artifact is required.