Product requirements document (PRD) from rough notes

You are a senior product manager. Write a product requirements document from my notes.

Product and context: [WHAT THE PRODUCT DOES, WHO USES IT]
Feature or change: [NAME AND ONE-LINE DESCRIPTION]
Evidence for the problem: [CUSTOMER QUOTES, SUPPORT TICKETS, DATA, SALES FEEDBACK]
Constraints: [DEADLINES, BUDGET, TECHNICAL OR LEGAL LIMITS]
Stakeholders: [TEAMS AND ROLES INVOLVED]

My rough notes:
"""
[PASTE NOTES]
"""

Produce a PRD with these sections:
1. Summary in three sentences.
2. Problem statement, with the evidence I provided.
3. Goals and non-goals (what this release will deliberately not do).
4. Target users and main use cases.
5. User stories in the form "As a [user], I want [action] so that [benefit]", each with testable acceptance criteria.
6. Success metrics, with a baseline if known and how each will be measured.
7. Dependencies, risks and mitigations.
8. Release plan: what is in the first version and what comes later.
9. Open questions, each with a suggested owner.

Rules: use only my notes and evidence. Where information is missing, write [TO DECIDE] or [NEEDS DATA] instead of filling the gap. Do not prescribe technical implementation unless my notes do.

Example (excerpt):
Non-goals: recurring invoices and multi-currency support are out of scope for v1.

User story: As a freelancer, I want to send a payment reminder from the invoice page so that I don't have to write the email myself.
Acceptance criteria: the reminder button appears only on invoices more than 7 days overdue; the email uses the client's saved language; the reminder date is logged on the invoice.

Success metric: share of overdue invoices paid within 14 days. Baseline: [NEEDS DATA].

When to use it

Use this prompt when an idea has been discussed in meetings, chats and documents, and the team now needs one shared description before design and development start. It suits product managers, founders and project leads in software and beyond, for example when specifying a new internal process or a service change.

How to customize it

• [EVIDENCE FOR THE PROBLEM] makes the PRD persuasive. A feature backed by customer quotes and data is easier to prioritize and to defend later.
• [CONSTRAINTS] sets realistic scope. A deadline or a legal requirement often decides what goes into the first version.
• [STAKEHOLDERS] helps the model assign open questions and spot missing reviewers, such as legal or support.
• If your company has a PRD template, paste its headings and ask the model to follow them instead.

Why it works

Most feature misunderstandings come from unclear scope and vague definitions of “done”. The prompt addresses both: non-goals make boundaries explicit, and acceptance criteria turn each user story into something that can be tested. Success metrics with baselines connect the work to results instead of output.

The placeholders for missing information are the most useful part. A PRD that looks complete but hides guesses misleads the team; visible gaps become an agenda for the review meeting. Keeping implementation details out leaves room for engineers and designers to propose the best solution.

Tips and variations

• Review the draft with engineering and design before sharing widely; they will spot missing edge cases and dependencies.
• Ask for a one-page version for leadership with only the summary, goals, metrics and timeline.
• Stress-test the plan with a pre-mortem, like our pre-mortem prompt of the day.
• Gather evidence first with our user interview script prompt.
• Start the project with our project kickoff brief.
• Keep the PRD alive after approval. Record decisions and changes in a short log at the top, so anyone joining later understands why scope changed and does not reopen questions the team has already settled with good reasons.
• Ask the model to list edge cases for each user story, such as empty states, errors and permissions, and add the ones that matter to the acceptance criteria.