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:

• "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:

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:

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:

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