PRD Development – Structured Product Requirements Document (PRD) Writing Workflow

Skill Overview

PRD Development is a structured PRD (Product Requirements Document) writing workflow for product managers. It organizes problem statements, user personas, solution overviews, success metrics, and user stories into a complete document that engineering teams can use directly.

Applicable Scenarios

1. Writing a complete PRD from scratch: Build a comprehensive requirements document for a major feature or product initiative, such as writing a PRD for a new AI recommendation feature on an e-commerce platform.
2. From research and discovery to engineering handoff: Organize scattered findings from user research or a Discovery Sprint, along with Slack discussions, into a PRD that engineers can execute directly.
3. Team alignment and decision documentation: Clarify what to build, what not to build, and how success will be measured before development begins, reducing scope creep and “build it the way I imagined it” communication.

Core Features

1. An 8-stage structured workflow: Progress through “Executive Summary → Problem Statement → Target Users → Strategic Context → Solution Overview → Success Metrics → User Stories and Requirements → Boundaries and Dependencies.” Each stage includes objectives, participants, and suggested timelines (approximately 2–4 days overall), along with a standard 10-section PRD template.
2. Sub-skill orchestration: Automatically connects 15 specialized skills, including problem statement development, user persona creation, Epic hypothesis formation, user story decomposition (including Richard Lawrence’s nine splitting patterns), and TAM/SAM/SOM market sizing. These skills are combined by stage without repeating questions.
3. Gap labeling and self-assessment: During the writing process, mark each unvalidated item with a 🔶 Assumption or 🔵 To Be Discovered label. Perform cross-section consistency checks after completing each section, and provide a final self-assessment covering the strongest and weakest sections, assumptions requiring validation, and next steps before sharing the PRD.

Frequently Asked Questions

What sections should a standard PRD include?

This workflow is organized into ten sections: Executive Summary, Problem Statement, Target Users and Personas, Strategic Context, Solution Overview, Success Metrics, User Stories and Requirements, Out of Scope, Dependencies and Risks, and Open Questions. Each section in the template includes completion guidance and examples.

Can this skill be used to write a PRD from scratch without discovery notes?

Yes. The workflow builds the PRD layer by layer, starting with problem definition. If you already have research data, metrics, or constraints, paste them in directly. The workflow will place the content in the appropriate stages, skip questions that have already been answered, and ask only about missing information.

What is the difference between a PRD and a detailed design specification (Spec)?

A PRD focuses on “why build it, who it is for, and what success looks like,” while keeping the solution description at a high level. It does not prescribe UI details or pixel-level interactions; those are part of the design collaboration process. Nor is it a fixed contract—it is a living document that evolves as development generates new insights. Small bug fixes or small features with fully defined requirements do not need this process, helping avoid unnecessary overhead.