Write a Product Requirements Document (PRD)

This prompt drafts a complete product requirements document with the sections a real PM ships — problem, goals and metrics, explicit non-goals, user stories, functional and non-functional requirements, and open questions. Use it to get from a rough feature idea to a reviewable first draft in minutes, then edit for your specifics. The instruction to avoid implementation details is intentional: a PRD should define what and why, leaving the how to engineering's design doc.

What you can expect back

1. Problem Statement
Daily power users manually re-run identical searches to catch new listings, missing time-sensitive items and creating repeat low-value sessions. Affected: ~8% of MAU who account for a high share of transactions.

2. Goals & Success Metrics
- Goal: notify users of new matches without manual re-searching.
- Metrics: % of saved searches that produce a click-through; reduction in repeat searches; alert opt-in rate.

3. Non-Goals
- Push and SMS channels (email only for v1).
- Recommending searches the user hasn't created.

4. User Stories
- As a power user, I can save a search so I don't re-enter filters.
- As a user, I receive an email when a new item matches, so I act first.

5. Functional Requirements
5.1 User can save a named search from any results page.
5.2 System checks saved searches for new matches and emails the user.
5.3 User can pause or delete an alert.

6. Non-Functional
- Alerts delivered within 15 min of a match; no duplicate emails; respect unsubscribe/CAN-SPAM.

7. Open Questions
- Max alerts per user? Digest vs. per-match email?

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Front-load the context with a real metric or user quote — a PRD grounded in 'support gets 40 of these tickets a week' produces sharper problem statements than an abstract description.
• 02Explicitly list what's out of scope in your context; the model writes much stronger non-goals when you seed one or two, which is where scope discipline actually comes from.
• 03Ask it to phrase success metrics as 'baseline -> target' pairs so they're measurable rather than aspirational adjectives like 'improve engagement.'
• 04If reviewers keep asking 'why now,' add a section for prioritization rationale and competitive context.
• 05Keep it honest about open questions — tell the model not to invent answers it can't know, so the Open Questions section flags real decisions for the team.

Adapt it for your case