| name | prd |
| description | Activate for: PRD, product requirements document, product requirements, full requirements, initiative doc, initiative requirements, platform change, new product, product launch, major release, quarterly initiative, program brief, product vision doc, comprehensive requirements, cross-functional alignment doc, launch plan requirements, multi-team initiative. NOT for: single-feature specifications (use official /write-spec), roadmap planning (use official /roadmap-update), sprint planning (use official /sprint-planning).
|
| license | Apache-2.0 |
| argument-hint | <initiative name> |
| metadata | {"author":"Panaversity","version":"1.0","plugin-commands":"/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:
| Dependency | Owner | Status | Risk if delayed |
|---|
| [Third party / platform team] | [Name] | [On track / TBD] | [Impact] |
Top risks:
| Risk | Likelihood | Impact | Mitigation |
|---|
| [Risk description] | H/M/L | H/M/L | [Specific mitigation action] |
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.
