Prompt details

Tested on

Claude Opus 5.5

Length

624 words · 3 fill-ins

Example input

[Feature idea and product context]: Product: Pantrly, an ordering app restaurants use to order supplies from their food distributors. About 2,400 restaurants and 14 distributors use it. Owners mostly use the web app; kitchen managers mostly use the iOS and Android apps. Each distributor sets its own delivery days and an order cutoff (for example 2 pm the day before delivery). Prices change weekly and items go out of stock. Feature idea: recurring orders. A kitchen manager sets up a standing order once (items, quantities, which delivery days). Before each cutoff the app creates that order automatically. The manager can edit it or skip a week, and it goes to the distributor unless they change it.

[User research and data]: Interviews: 9 kitchen managers and owners, last month. - "I order the same 30 items every Monday and Thursday. It takes me about 25 minutes each time." (kitchen manager, 2-location burger group) - "Last month I forgot the Thursday order and we ran out of fryer oil on a Friday night." (owner, pizzeria) - "Prices jump and I don't notice until the invoice." (4 of 9 said something like this) - "I don't want it to send by itself if something's out of stock. I need to swap it." (kitchen manager, cafe) - 2 of 9 said they would not trust anything that sends without them pressing a button. Order data, last 90 days: among restaurants with 8 or more orders, 68% of orders had at least 80% of the same items as their previous order on the same weekday. Support: 140 tickets last quarter about missed cutoffs. Distributors: 3 of 14 already take standing orders by phone or email; one, Coastline Foods, asked for it in the app. Churn survey: 11 of 40 restaurants that left said ordering takes too long.

[Team, deadline and constraints]: Team: 2 backend engineers, 1 mobile engineer, 1 designer, QA shared with another team. Release in 8 weeks, before the summer season. The distributor catalog API returns price and stock only at the moment of ordering; distributors confirm stock after the order is submitted and can reject lines. Restaurants pay distributors on account (net 30); no card is charged in the app. We have push and email notifications; no SMS. Legal: we must never submit an order the restaurant has not been told about. About 15% of accounts are multi-location groups. Roles: owner, manager, staff. Staff cannot submit orders today.

Example output

1. Summary

Kitchen managers rebuild largely the same supply order by hand before every cutoff, and when they forget, the restaurant runs short: 68% of repeat customers' orders reuse at least 80% of the previous same-weekday order, and support logged 140 missed-cutoff tickets last quarter. Recurring orders let an owner or manager set up a standing order once; before each cutoff Pantrly prepares that order, notifies them, and submits it unless they edit, skip or pause it. We will know it worked if restaurants using recurring orders file fewer missed-cutoff tickets [TBD: target], with no rise in unwanted or disputed orders and no order ever submitted without a notification on record.

2. Problem and evidence

Restaurants order many of the same items on the same days each week, yet Pantrly makes them rebuild each order from scratch before every distributor cutoff. This costs time, and when the order is forgotten or late the restaurant runs out of stock during service. Ordering effort is also a stated reason restaurants leave. Some distributors already handle standing orders by phone or email outside Pantrly, so that demand already exists. Any automation must work within two limits: prices change weekly and items go out of stock, and users must always know an order is about to be sent.

Repetition (order data, last 90 days): among restaurants with 8 or more orders, 68% of orders had at least 80% of the same items as their previous order on the same weekday.
Missed cutoffs (support): 140 tickets last quarter about missed cutoffs. One interviewee: "Last month I forgot the Thursday order and we ran out of fryer oil on a Friday night." (owner, pizzeria)
Time cost (interviews, 9 users): "I order the same 30 items every Monday and Thursday. It takes me about 25 minutes each time." (kitchen manager, 2-location burger group). This is one person's account, not a baseline.
Churn (exit survey): 11 of 40 restaurants that left said ordering takes too long.
Trust and change risk (interviews): 4 of 9 said price jumps go unnoticed until the invoice. One kitchen manager does not want an order sent automatically when an item is out of stock. 2 of 9 would not trust anything that sends without them pressing a button.

Claude Opus 5.5

Write a Product Requirements Doc – Product requirements document prompt for ChatGPT and Claude

^$9.99

Kept in your account
Copy filled in or download
Updates included

Pay once and keep it. Or get every premium prompt and skill with the plan, $19.99 a month. Payments are non-refundable. See our Terms.

votes views

Claude Opus 5.5

This prompt turns a feature idea, your research and your constraints into a full product requirements document: prioritized requirements with acceptance checks, edge cases, success and guardrail metrics, a staged rollout and open questions.

What you get

A full PRD in Markdown: the problem with sourced evidence, goals, non-goals, users and use cases
Numbered requirements with a P0, P1 or P2 priority, the evidence behind each and an acceptance check
An edge case table, success and guardrail metrics, and a staged rollout with rollback triggers
Every missing number left as {{TBD}}, every call it made marked [Proposed], and open questions with owners

How to use it

1
Paste the idea and the evidence
Give the feature in a few sentences, then your interview quotes, data and tickets with their sources, then the team, deadline and rules it has to live within.
2
Read the P0 list first
Check that the launch blockers fit your team and deadline, and that every requirement traces back to a note, a rule or a stated reason.
3
Settle the open items before kickoff
Take each {{TBD}} and [Proposed] to the role named in Open questions, fill in the answers and ask for the PRD updated.

Better results

Paste quotes with who said them and data with its source and time range. The PRD cites them next to each requirement, which shortens the review.
Once engineering has sized it, follow up with: "Our estimate for P0 is 11 weeks and we have 8. Cut P0 to fit and show what moves."
Ask for the requirements table as CSV with ID, Requirement, Priority and Acceptance check to import it into your tracker.

Questions

Can ChatGPT write a PRD?

Yes, ChatGPT can write a solid PRD when you give it the feature idea, your research and your constraints, and tell it not to invent numbers. Expect placeholders for baselines and targets you have not measured, and review every requirement with your engineers before kickoff.

How can product managers use AI?

Product managers use AI to draft PRDs, user stories and release notes, sum up research and feedback, and find edge cases before a sprint. It works best on your own material, such as interview notes, data and constraints. Priority and scope decisions still sit with you and your team.

What should a PRD include?

A PRD should include the problem and its evidence, goals and non-goals, users and use cases, prioritized requirements with acceptance checks, edge cases, success metrics with a guardrail, a rollout plan and open questions. This prompt writes all of them, in that order.

What are the best AI tools for product managers?

A general chat assistant such as Claude, ChatGPT or Gemini covers most product writing when you paste your notes. ChatPRD adds PRD templates and team features, and Productboard gathers customer feedback in one place. The quality still depends on the evidence you give it.

Updated 8 Nov 2026