Generate Comprehensive Product Requirements Documents

Creates comprehensive Product Requirements Documents (PRDs) that serve as the authoritative source of truth for product development, translating business objectives into clear, actionable requirements for engineering teams.

Use this skill when writing a new PRD from scratch, structuring user stories with acceptance criteria, prioritizing functional requirements, defining technical specifications and success metrics, or adapting a PRD for an agile, iterative environment. Not a fit for lightweight feature tickets that don't need cross-functional alignment, or for purely technical design documents without a product/business framing.

Defines a nine-section PRD structure (background/context, goals/objectives, user stories/acceptance criteria, functional requirements, non-functional requirements, technical considerations, dependencies/assumptions, risk assessment, success metrics/KPIs) preceded by an executive summary (problem statement, solution overview, success metrics, timeline).

Provides a standard user story format ("As a [user type], I want [functionality], so that [benefit]") with Given/When/Then acceptance criteria and a Definition of Done checklist covering implementation, tests, code review, and documentation. Functional requirements use the MoSCoW method (Must/Should/Could/Won't Have) for prioritization. Non-functional requirements are templated across performance (page load, API response time, concurrent users), security (auth method, encryption, compliance standards), and scalability (horizontal scaling, auto-scaling triggers, database partitioning).

Technical requirements guidance includes a concrete API specification example (endpoint, response schema, error codes) to guide implementation. Success metrics follow the SMART framework with primary metrics (adoption, engagement, conversion) and secondary metrics (uptime SLA, error rate, support ticket reduction). Risk assessment uses an impact/probability matrix with named risks and mitigation plans for each quadrant.

Stakeholder communication guidance tailors PRD content per audience: engineering teams need technical specifications, API contracts, and integration points; design teams need user research references, wireframes, and accessibility requirements; business stakeholders need ROI framing, competitive positioning, and timeline/resources. A review checklist validates that the problem is clearly defined, requirements are testable, technical feasibility is confirmed, and success metrics are trackable, supported by validation techniques (user interviews, prototype testing, technical spikes, market research).

Lists common anti-patterns: solution-first thinking instead of starting from the problem, vague non-measurable requirements, missing rationale for requirements, over-specifying implementation ("how" instead of "what"), and treating the PRD as a static rather than living document. Covers agile PRD adaptation using epic-level PRDs for high-level features, story-level detail documents, regular updates reflecting learnings, and version control for decision tracking.

Produces documents intended for cross-functional consumption by engineering, design, and business stakeholders, with technical sections referencing API contracts and data models directly.

Product managers writing PRDs that need to serve as an authoritative, testable requirements source across engineering, design, and business audiences rather than an unstructured feature brief.

As a [user type],
I want [functionality],
So that [benefit/value].