Prd

CONTEXT LOADING

Before generating a PRD, load product.local.md for product context, personas, engineering team details, and stakeholder map. If not configured, ask the user for product name, personas, and engineering context.

PRD WORKFLOW

When to Write a PRD (vs. a Feature Spec)

Write a SPEC when: One feature, one team, one-to-three sprints Write a PRD when: Multiple features, multiple teams, major platform change, new product area, or executive alignment required

If unsure, ask the user: "Is this one feature for one team (use /write-spec) or a multi-team initiative (use /prd)?"

PRD Sections -- Full Template

SECTION 1: EXECUTIVE SUMMARY [3-4 sentences only] What: [What are we building -- in plain language] Why: [What commercial or user problem does it solve] When: [Target delivery -- quarter, not date unless confirmed] Win: [How we will know it worked -- headline metric]

SECTION 2: BUSINESS CONTEXT Problem statement: [The specific user pain or business gap -- with evidence]

Commercial evidence (use what is available):

• Lost deals: "[N] deals cited [issue] as blocker in [period]"
• Customer requests: "[N] requests logged; [source]"
• Competitive gap: "[Competitor] offers [feature]; we do not"
• Revenue opportunity: "[Estimate] ARR blocked or at risk"
• Support cost: "[N] tickets / [hours] PM support time per [period]"

Strategic fit: [How this initiative connects to the company/product strategy. One sentence. If you cannot write this sentence, the initiative may not belong in the roadmap.]

Success metrics: Primary (measure at 6-12 months post-launch): [Specific, measurable outcome: not "improve NPS" but "enterprise NPS from 42 to 52 within 6 months of launch"]

Secondary (measure at 30-90 days):
  [Leading indicators: adoption rate; support volume change;
   sales cycle impact]

Failure threshold:
  [What outcome would cause us to reconsider or change direction?
   Define before launch, not after.]

SECTION 3: USER REQUIREMENTS Primary persona: Name: [Persona name from product.local.md] Role: [Job title / function] Current state: [How they handle this today -- the workaround] Desired state: [What "10/10" looks like for them] Key user stories: [Top 3 as "As a... I want... So that..."]

Secondary persona (if applicable): [Same structure -- brief]

User journey map: Current state: [Step-by-step of how they do it today] Pain points: [Where the friction is in the current flow] Future state: [Step-by-step with the new product in place]

SECTION 4: FUNCTIONAL REQUIREMENTS For each feature/capability in scope:

Feature [N]: [Name] Priority: MUST / SHOULD / COULD (MoSCoW) Description: [What it does] Key flows: [Primary user flows] Dependencies: [Other features or teams this depends on] Spec ref: [Link to individual spec if exists]

Rule: Every item labelled MUST must ship before launch. If more than 60% of items are labelled MUST, the scope is too large.

SECTION 5: NON-FUNCTIONAL REQUIREMENTS Performance: [Page load time; API response time; export generation time -- with numbers]

Reliability: [Uptime SLA; error rate tolerance; recovery time objective]

Security: [Authentication requirements; data encryption; audit requirements; penetration testing if required]

Compliance: [GDPR / CCPA data handling; SOC 2 implications; HIPAA if applicable; sector-specific regulations]

Accessibility: [WCAG standard; keyboard navigation; screen reader requirements]

Scalability: [Expected load at launch; growth assumptions; capacity planning notes]

SECTION 6: TECHNICAL ARCHITECTURE NOTES [High-level approach -- not implementation detail]

• Key technical decisions already made
• Platform or infrastructure dependencies
• Third-party integrations required
• Data model changes (high level)
• Migration requirements (existing users / data)
• Feature flags required

Note: This section is written by PM in collaboration with engineering. It must be reviewed and confirmed by the engineering lead before the PRD is marked as REVIEW-ready.

SECTION 7: GO-TO-MARKET REQUIREMENTS Documentation: [Customer-facing docs required; doc owner; due date]

Customer Success enablement: [What CS needs to know before launch; training requirements]

Sales enablement: [What sales needs to demo/discuss this feature; talking points]

Pricing: [Is this in the current plan? New tier? Add-on? Pricing team review needed?]

Beta programme: [Which customers; how many; invite criteria; beta start date; GA date]

Customer communication: [Announcement channel; timing; who sends it]

SECTION 8: LAUNCH PLAN Phased rollout: Phase 1 -- Beta: [Audience; dates; success gates for Phase 2] Phase 2 -- GA: [Full availability; announcement plan] Rollback plan: [How to undo if critical bug discovered post-launch]

Feature flags: [Required flags; rollout percentages; sunset plan]

Monitoring: [What metrics are watched in the first 48 hours post-launch; who is on-call; escalation path]

SECTION 9: DEPENDENCIES AND RISKS External dependencies:

Top risks:

SECTION 10: OPEN QUESTIONS [Numbered; owner; due date] All questions must be resolved before PRD moves to REFINED status.

APPENDICES (include as available) A. Competitive analysis B. User research excerpts C. Technical discovery notes D. Prior art / related specs

PRD Status Gates

DRAFT: All sections present; some may be incomplete REVIEW: All sections complete; open questions have owners and dates; engineering lead has confirmed architecture notes REFINED: All open questions resolved; effort estimated by engineering; GTM requirements confirmed by CS/Sales APPROVED: CPO/CEO sign-off; ready for sprint planning SHIPPED: Feature live; success metrics being tracked

COMPLEMENTARY WORKFLOWS

This skill handles multi-team PRDs. For related PM workflows:

• Single-feature specifications: use official /write-spec
• Decomposing PRD into user stories: use /stories from this plugin
• Roadmap placement: use official /roadmap-update
• Sprint planning from PRD: use official /sprint-planning

NEVER DO THESE

• NEVER approve a PRD for sprint planning without engineering lead sign-off on the architecture notes section
• NEVER mark a PRD REVIEW-ready with empty sections -- a gap in the PRD is a gap in the product thinking
• NEVER define success metrics after launch -- they must be in the PRD before the first sprint starts
• NEVER omit the failure threshold -- knowing when to change direction is as important as knowing when to celebrate
• NEVER list a MUST requirement you would actually ship without -- if you would ship without it, it is a SHOULD
• NEVER use "a user" as the persona -- always reference named personas from product.local.md

ALL OUTPUTS REQUIRE REVIEW BY THE PM AND ENGINEERING LEAD BEFORE APPROVAL.