Create PRD Skill

Purpose

Create comprehensive Product Requirements Documents (PRD) from high-level product ideas. This skill guides systematic requirements gathering, market analysis, feature definition, and success metrics documentation to produce PRDs ready for architecture design or epic breakdown.

Core Principles:

•Structured requirements elicitation
•Market-driven feature prioritization
•Clear success metrics and KPIs
•User-centric design approach
•Supports both greenfield (new products) and brownfield (existing systems) contexts

Prerequisites

•Product vision or initial concept defined
•Access to stakeholder input (if available)
•Understanding of target market and users
•workspace/ directory exists for PRD storage

Workflow

Step 1: Requirements Gathering

Action: Elicit product vision, objectives, and constraints through structured inquiry.

Key Activities:

•
Product Vision & Value Proposition
- •What problem does this solve?
- •What value does it provide to users?
- •What makes it unique or different?
•
Target Users & Personas
- •Who are the primary users?
- •What are their goals, needs, pain points?
- •What user segments exist?
•
Business Objectives
- •What are the business goals?
- •How does this align with strategy?
- •What's the expected ROI or impact?
•
Constraints & Considerations
- •Timeline constraints
- •Budget limitations
- •Technical constraints
- •Regulatory requirements
- •Team capabilities

Example Questions:

code

- "What problem are we solving for users?"
- "How will users discover and access this?"
- "What success looks like in 6 months?"
- "What are we explicitly NOT building?"

Output: Core requirements documented (vision, users, objectives, constraints)

See: references/elicitation-guide.md for comprehensive elicitation techniques

Step 2: Market Analysis

Action: Analyze competitive landscape and market positioning.

Key Activities:

•
Competitive Landscape
- •Who are the direct competitors?
- •Who are indirect competitors or alternatives?
- •What are their strengths/weaknesses?
•
Market Positioning
- •How do we differentiate?
- •What's our unique value proposition?
- •What market segment do we target?
•
Go-to-Market Considerations
- •Distribution channels
- •Pricing strategy (if applicable)
- •Marketing approach
- •Launch strategy
•
Market Trends
- •Relevant industry trends
- •Technology trends
- •User behavior trends

Example Analysis:

code

Competitive Landscape:
- Direct: [Competitor A] (strength: enterprise features, weakness: poor UX)
- Indirect: [Alternative B] (users use spreadsheets instead)

Differentiation:
- Simple, intuitive UX (vs competitor complexity)
- Mobile-first design (vs desktop-only competitors)
- AI-powered automation (unique capability)

Output: Market analysis section for PRD

See: references/market-analysis-template.md for detailed framework

Step 3: Feature Definition

Action: Define and prioritize features using MoSCoW method.

Key Activities:

•
Identify Core Features
- •What must the product do? (Must-haves)
- •What should it do? (Should-haves)
- •What could it do? (Could-haves)
- •What won't it do? (Won't-haves)
•
Feature Specifications
- •Brief description of each feature
- •User value/benefit
- •Dependencies between features
- •Technical complexity estimate (if known)
•
MoSCoW Prioritization
- •Must Have: Critical features, MVP blockers
- •Should Have: Important but not launch blockers
- •Could Have: Nice-to-haves, future enhancements
- •Won't Have: Explicitly out of scope
•
Feature Validation
- •Does each feature solve user problem?
- •Is each feature aligned with objectives?
- •Are must-haves achievable within constraints?

Example Feature Definition:

code

MUST HAVE (MVP):
1. User Registration & Login
   - Users can create accounts with email/password
   - Enables personalization and data security
   - Depends on: Database, authentication service

2. Dashboard Overview
   - Users see key metrics at a glance
   - Provides immediate value on login
   - Depends on: Data collection, visualization

SHOULD HAVE:
3. Advanced Filtering
   - Users can filter data by multiple criteria
   - Improves data discovery
   - Depends on: Dashboard, search infrastructure

COULD HAVE:
4. Data Export (CSV, PDF)
   - Users can export reports
   - Convenience feature, not core value
   - Depends on: Dashboard, report generation

WON'T HAVE (v1):
5. Real-time Collaboration
   - Out of scope for v1, planned for v2
   - Significant technical complexity

Output: Prioritized feature list with specifications

See: references/moscow-prioritization-guide.md for detailed prioritization framework

Step 4: Success Metrics

Action: Define measurable success criteria and KPIs.

Key Activities:

•
User Adoption Metrics
- •Sign-ups, active users (DAU/MAU/WAU)
- •User retention (D1, D7, D30 retention)
- •User engagement (sessions, time-on-site)
- •Feature adoption rates
•
Business Impact Metrics
- •Revenue (if applicable)
- •Conversion rates
- •Cost savings
- •Market share
- •Customer satisfaction (NPS, CSAT)
•
Technical Performance Metrics
- •Page load time
- •API response time
- •Uptime/availability
- •Error rates
- •Scalability metrics
•
Success Criteria
- •Specific targets for each metric
- •Timeframes for achievement
- •How metrics will be measured
- •Baseline vs target values

Example Success Metrics:

code

USER ADOPTION:
- 1,000 sign-ups in first month
- 60% D7 retention
- 40% MAU engagement

BUSINESS IMPACT:
- 70% conversion rate (free → paid)
- NPS score >40
- $100K ARR by month 6

TECHNICAL PERFORMANCE:
- <2s page load time (p95)
- 99.9% uptime SLA
- <1% error rate

Output: Success metrics and KPIs documented

See: references/success-metrics-framework.md for comprehensive metrics catalog

Step 5: PRD Document Generation

Action: Compile all gathered information into comprehensive PRD document.

Document Structure:

•
Executive Summary
- •Product overview (1-2 paragraphs)
- •Problem statement
- •Value proposition
- •Target users
•
Product Vision & Objectives
- •Vision statement
- •Business objectives
- •Success criteria
•
User Personas & Stories
- •Persona definitions
- •User journeys
- •Key use cases
•
Market Analysis
- •Competitive landscape
- •Market positioning
- •Differentiation strategy
•
Feature Specifications
- •Prioritized feature list (MoSCoW)
- •Feature descriptions and user value
- •Dependencies and relationships
•
User Flows & Journeys
- •Key user flows
- •Entry points and conversions
- •Edge cases
•
Non-Functional Requirements
- •Performance requirements
- •Security requirements
- •Scalability requirements
- •Accessibility requirements
•
Success Metrics & KPIs
- •Adoption metrics
- •Business impact metrics
- •Technical metrics
- •Success criteria with targets
•
Timeline & Milestones
- •High-level roadmap
- •Key milestones
- •Launch criteria
•
Assumptions & Constraints
- •Technical assumptions
- •Business assumptions
- •Known constraints
- •Dependencies
•
Open Questions & Risks
- •Unresolved questions
- •Identified risks
- •Mitigation strategies

File Location:

•Greenfield: docs/prd.md or workspace/prds/{product-name}-prd.md
•Brownfield: docs/brownfield-prd.md (if updating existing system)

Validation:

•All required sections present
•Features prioritized with clear MoSCoW categories
•Success metrics specific and measurable
•Assumptions and risks documented
•Ready for next phase (architecture or epic breakdown)

Output: Complete PRD document

See: references/prd-template.md for complete PRD template with all sections

Common Scenarios

Scenario 1: Greenfield Product (New Product)

Context: Creating PRD for entirely new product with no existing system.

Approach:

•Focus on user problem and market opportunity
•Emphasize differentiation and unique value
•Start with minimal MVP features
•Plan iterative releases

See: references/greenfield-examples.md for complete examples

Scenario 2: Brownfield Product (Existing System)

Context: Creating PRD for enhancements to existing product.

Approach:

•Document current state briefly
•Focus on gaps and improvements
•Consider migration and compatibility
•Balance new features with technical debt

Note: For comprehensive brownfield PRD generation from codebase analysis, use create-brownfield-prd skill instead.

Scenario 3: Insufficient Information

Context: Stakeholders haven't provided enough detail.

Approach:

•Document known information
•Create "Assumptions" section with reasonable assumptions
•Create "Open Questions" section with specific questions
•Mark PRD as "DRAFT - Pending Stakeholder Input"
•Share with stakeholders for feedback

Scenario 4: Too Many Features

Context: Stakeholders want everything in MVP.

Approach:

•Apply strict MoSCoW prioritization
•Identify true MVP (minimum viable)
•Create phased roadmap (v1.0, v1.1, v2.0)
•Use data/evidence to defend prioritization
•Escalate if stakeholder insists on unrealistic scope

See: references/scope-management-guide.md for scope negotiation strategies

Best Practices

•Be User-Centric - Always frame features in terms of user value, not technical implementation
•Keep It Clear - Use simple language, avoid jargon, be specific and concrete
•Prioritize Ruthlessly - Not everything can be "must have"; be honest about MVP scope
•Be Data-Driven - Use market research, user feedback, and metrics to validate decisions
•Document Assumptions - Make implicit assumptions explicit to avoid misalignment later
•Stay Flexible - PRD is a living document; expect it to evolve as you learn more
•Cross-Reference - Link to other documents (architecture, task specs, user research)
•Get Feedback - Share early drafts with stakeholders for validation and buy-in

Reference Files

•references/elicitation-guide.md - Techniques for gathering requirements
•references/market-analysis-template.md - Competitive and market analysis framework
•references/moscow-prioritization-guide.md - Feature prioritization methodology
•references/success-metrics-framework.md - Comprehensive metrics catalog
•references/prd-template.md - Complete PRD template with all sections
•references/greenfield-examples.md - Example PRDs for new products
•references/scope-management-guide.md - Managing scope and stakeholder expectations

When to Escalate

Escalate to stakeholders when:

•Critical information missing (target users, business objectives)
•Conflicting requirements or priorities
•Unrealistic scope or timeline expectations
•Budget constraints conflict with must-have features
•Regulatory or compliance requirements unclear

Escalate to architect when:

•Technical feasibility of features uncertain
•Significant architectural decisions needed
•Integration requirements complex

Use alternative skill when:

•Existing codebase needs analysis → Use create-brownfield-prd skill
•PRD too large (>100 features) → Use shard-document skill after creation
•Interactive validation needed → Use interactive-checklist skill for PO review

Part of BMAD Enhanced Planning Suite