#prd template

Product Requirements Document (PRD) Writer

Turn a product idea into a complete PRD: problem, users, scope, user stories, acceptance criteria, metrics, and launch risks.

Act as a senior product manager writing a PRD that engineering, design, and GTM can actually execute. Be precise about what is in, what is out, and what is still unknown. Do not dress guesses up as facts. Inputs: - Product / feature: [Name and one-line idea] - Problem: [Who hurts and how] - Users: [Primary and secondary] - Platform: [Web / iOS / Android / API / internal] - Business goal: [Revenue, retention, expansion, cost, compliance] - Constraints: [Time, stack, legal, dependencies] - Known unknowns: [List, or "none yet"] - Success metric I care about: [North-star or proxy] Generate: 1. Summary: 8-12 sentences. What we are building, for whom, why now, and what "done" means for v1. Flag any Input that is still vague. 2. Problem and context: Current workaround. Cost of the workaround. Why existing tools or the current product fail. Evidence: separate Provided (from Inputs) vs Assumed (label each assumption). 3. Goals and non-goals: - Goals (3-6): Outcome-based, testable. - Non-goals for v1: Explicit cuts. Include at least two tempting features we will refuse. 4. Users and JTBD: Primary user, secondary user, anti-user (who this is not for). For the primary user: job-to-be-done statement, trigger, desired outcome, current alternatives. 5. Scope: In-scope list. Out-of-scope list. Open questions with an owner suggestion (PM / Eng / Design / Legal / GTM). 6. User stories (8-12): Format "As a [user], I want [action], so that [outcome]." Tag each P0 / P1 / P2. P0 must be a shippable vertical slice, not a layer of polish. Include 1-2 negative stories (what the system must not do). 7. Acceptance criteria for every P0 story: Given / When / Then. Include empty, error, permission, and mobile/narrow-viewport cases where relevant. No "should feel fast" without a number or a qualitative test method. 8. UX notes: Happy path in 6-10 steps. Empty states. Edge cases. Key copy (buttons, errors). What must be designed vs. what can ship with existing patterns. 9. Analytics and success metrics: Leading and lagging metrics. Event names (object_action). Guardrail metrics that would make us roll back. How we will decide to iterate vs. kill after launch. 10. Launch plan: Feature flag / staged rollout sketch. Internal dogfood. Beta criteria. Support and docs needed. GTM one-pager bullets (who we tell, what we claim, what we will not claim). 11. Risks and unknowns: Table: risk | likelihood (Low/Med/High, labeled as judgment) | impact | mitigation | trigger to escalate. Include at least one dependency risk and one "we might be solving the wrong problem" risk. Constraints: - No fake certainty. If Inputs do not include a number, write "unknown, need [source]" instead of inventing a TAM or conversion rate. - Do not invent APIs, vendors, or legal positions. - Stories must be independently testable. No "and also make it beautiful." - Write for a staff engineer who will challenge scope. Short sentences. Named sections. No vision-deck fluff.