First-draft PRDs that keep your assumptions honest
Writing the PRD is the classic blank-page tax, and it's one of the tasks PMs report AI saving the most time on. A model is good at structure and completeness, prompting you for the edge cases and non-goals you'd otherwise forget. It's dangerous at exactly one thing: quietly inventing user counts, metrics, and research findings to fill the template. The prompt forces it to mark what it doesn't know.
You are a senior product manager drafting a PRD for team review. Produce a first draft I will edit, not a final document. Problem to solve: {{problem}} Target user and their job-to-be-done: {{target_user}} Primary success metric and target: {{goal_metric}} Known constraints and context: {{constraints_context}} Structure the PRD: - One-line summary - Problem and why now - Goals and explicit non-goals - Target user and the job-to-be-done - Proposed approach at a high level (leave room for eng to shape the how) - User stories, each with acceptance criteria - Success metrics and guardrail metrics - Risks and open questions Rules: - Use only facts I provided. Do not invent user numbers, revenue figures, market sizes, or research findings. Where the draft needs a number or a fact I didn't give, insert "[NEEDS DATA: what to find]"; where you make a working assumption, label it "[ASSUMPTION]". - Write at least three open questions a reviewer would raise. - Keep the proposed approach solution-agnostic where the problem allows more than one path. - Label the top "DRAFT — for review". Keep it under 700 words.
Fill in your details and the prompt updates live — then copy.
DRAFT — for review Summary: Reduce first-session drop-off by guiding new users to connect one data source fast. Goals: Lift day-1 activation from 34% to 50%. Non-goals: redesigning the connector library; multi-source setup. User story: As an evaluating analyst, I can pick a recommended first integration and see sample data, so I reach value before configuring anything. Acceptance criteria: a recommended source is preselected; a sample dashboard renders pre-connection. Open questions: Does drop-off differ by connector? [NEEDS DATA: activation by source type]. Assumed the OAuth flow itself isn't the blocker [ASSUMPTION].
The full workflow
- Gather the real problem statement, metric baseline, and constraints before prompting
- Generate the draft, then resolve every [NEEDS DATA] flag with actual numbers from your analytics or research
- Pressure-test the non-goals and open questions with engineering and design
- Rewrite the proposed approach in your own words so the judgment is yours
Watch out for
Unreleased product plans are confidential and often covered by your NDA. Don't paste a roadmap, revenue target, or strategy into a consumer AI account; models can retain inputs, and this is exactly the trade-secret exposure that led Samsung to ban public chatbots internally.
The model will happily fill your template with plausible fake metrics and 'research shows' claims. Every number and finding in the final PRD must trace to a real source you can cite.
A generated PRD reads complete but reflects no user contact. It's a scaffold; the prioritization, scope, and trade-offs are still your call to defend.
Where this comes from
Every use case on this site is grounded in real reports from working product managers — not invented by us.