PRD Writer

Goal

Convert a rough feature idea into a complete, structured PRD covering goals, user stories, requirements, and success metrics.

Trigger

When a product manager, founder, or engineer has a feature idea they need to formalize into a documented spec for the team.

Steps

1. 1

   Analyze the raw feature idea below and extract the core problem being solved, the target user, and the proposed solution: $feature_idea

   • □Core problem is clearly identified
   • □Target user or persona is named
   • □Proposed solution is summarized

   Analyze the raw feature idea below and extract the core problem being solved, the target user, and the proposed solution:
   
   $feature_idea

2. 2

   Define the business and user goals for this feature. Write 2–3 business objectives and 2–3 user goals that this feature must satisfy. Make each goal specific and outcome-oriented.

   • □Business goals are measurable or outcome-oriented
   • □User goals reflect real user needs
3. 3

   Write 4–6 user stories in the format 'As a [user], I want to [action] so that [benefit].' Cover the primary happy path and at least one edge case or secondary user type.

   • □Each story follows As/I want/So that format
   • □At least one edge case or secondary user is covered
4. 4

   List functional requirements (what the system must do) and non-functional requirements (performance, security, accessibility, scalability). Use numbered lists with clear, testable statements.

   • □Functional requirements are testable
   • □At least one non-functional requirement is included
   • □No ambiguous language like 'fast' or 'easy'
5. 5

   Define the success metrics and acceptance criteria. Include 2–3 quantitative KPIs (e.g. adoption rate, task completion time) and specify what 'done' looks like for each major requirement.

   • □KPIs are quantitative and measurable
   • □Acceptance criteria map to functional requirements
6. 6

   Identify open questions, assumptions, out-of-scope items, and dependencies (teams, systems, or APIs). Flag any risks or decisions that need stakeholder sign-off before development begins.

   • □At least one assumption is documented
   • □Out-of-scope items are explicitly listed
   • □Risks or blockers are flagged

Output format

Return a single structured document with clearly labeled sections: 1) Overview (problem, user, solution), 2) Goals, 3) User Stories, 4) Requirements (Functional + Non-Functional), 5) Success Metrics & Acceptance Criteria, 6) Open Questions & Risks. Use headers, numbered lists, and bullet points for scannability. Keep language precise and free of jargon.