Act as a senior product manager. I'm going to give you a one-line problem statement. Before drafting any PRD, do this: 1. State the assumptions you're making about audience, scope, and constraints. Number them. I'll correct any that are wrong. 2. Then produce a PRD with these exact named sections: Problem, Goal, Non-goals, Success metrics, Open questions. 3. The Open questions section must contain 3-5 questions an engineer or designer would actually ask in review - not generic 'what's the timeline'. Specific to this feature. Do not pad. Do not write a 'Background' section. Do not invent metrics that I haven't given you data for - if you don't know the baseline, the success metric should say 'TBD - need baseline from {{metric_source}}'. The one-line problem: {{problem_statement}}
PRD draft from a one-line problem
Add to PromptPaste
Download PromptPaste for MacDownload PromptPaste for iPhoneDownload PromptPaste for iPadDownload PromptPaste for Mac & iPhone
the prompt
Example output
Assumptions I'm making (correct me before I draft):
1. Target user is an existing power user, not a new signup.
2. Engineering effort target is 2-3 weeks, one engineer.
3. We're not adding new permissions or auth surface.
Problem: Power users lose 30+ seconds per session manually re-applying filters they already used last time.
Goal: Persist the last-used filter set per user, restore on next session.
Non-goals: Cross-device filter sync. Filter sharing across teammates. Filter analytics.
Success metrics: 20% reduction in median time-to-first-result for returning users in 30 days.
Open questions:
- Do filters persist across logout/login or only within a session?
- What happens when a saved filter references a deleted item?
- Do we expose the persistence visibly (a 'last session' chip) or silently restore?
Common mistakes
Don't paste the full feature spec when starting. Paste the one-line problem and let the model surface what it's missing - the surfaced gaps are more valuable than the draft itself. Also: do not skip the 'assumptions' section by asking 'just write the PRD.' That's how you get a confident-sounding PRD for the wrong feature. The whole prompt is designed to slow you down by exactly one round of clarification, which is the round most PMs skip and regret.
More from AI Prompts for Product Managers
Customer interview synthesis
Read the raw customer interview transcripts below. Produce: 1. The top 5 themes ranked by frequency (number of interviews where the theme…
Stakeholder weekly update
Convert my raw bullets below into a weekly stakeholder update. Use exactly three sections: 1. Shipped: each item with a one-line outcome,…
Decision memo (one-pager)
Convert the messy debate input below into a structured one-page decision memo. Use exactly these sections: 1. Decision: stated in one…
Why it works
PRDs are the most-cited PM AI use case in the 2026 Lenny's survey - 87% of PMs use AI for them. The mistake is asking for 'a PRD for X' and getting a generic template that ignores everything specific about your product. This prompt forces three things: it makes the model surface its assumptions before drafting, it produces named sections (problem / goal / non-goals / success metrics / open questions) instead of vague paragraphs, and it ends with the questions an engineer or designer would actually ask in review. The 'open questions' section is doing the heavy lifting - it converts a confidently-wrong AI draft into a structured first round of decisions you still own. Tested cleanest on Claude Opus 4.7.