Goal: Guide product teams through creating a comprehensive Product Requirements Document using a structured 8-section template.Documentation Index
Fetch the complete documentation index at: https://docs.getcore.me/llms.txt
Use this file to discover all available pages before exploring further.
Tools Required
This skill runs using CORE memory only. No integrations required.Step 1: Gather PRD Context
Ask for:- Initiative name — What are we building?
- Why now — What’s the business/customer driver?
- Key stakeholders — Who needs to sign off or contribute?
- Rough timeline — When does this need to launch?
- Target customer segment — Who benefits?
Step 2: Outline the 8 Sections
Walk through each section, gathering information:- Summary (2-3 sentences)
- Contacts (stakeholders, owners)
- Background (why we’re doing this)
- Objective (goals and success metrics)
- Market Segment (target audience)
- Value Proposition (customer benefits)
- Solution (features, UX, tech approach)
- Release (timeline, versioning)
Step 3: Draft Section by Section
For each section, gather input and guide the user toward clear, actionable language. Section 1: Summary- 2-3 sentences capturing what this feature/product does and why it matters
- Should be readable by an executive unfamiliar with the context
- Product owner
- Design lead
- Engineering lead
- Stakeholders (executives, partner teams)
- Context: what led to this initiative
- Market condition or customer feedback driving it
- Any prior attempts or related features
- Timeline/dependencies
- Primary goal (1 sentence)
- Success metrics (OKRs or KPIs)
- Definition of success
- Constraints or assumptions
- Target customer segment
- Job-to-be-done or primary use case
- Size of opportunity (if known)
- Any personas or segment characteristics
- Customer problem being solved
- How this solution addresses it
- Competitive advantages or differentiation
- Any switching costs or network effects
- High-level feature set
- User flows or screenshots/mockups (link to Figma)
- Technical architecture (if complex)
- Any assumptions or open questions to validate
- Phasing or rollout plan (MVP vs. full release)
- Planned launch date
- Rollout strategy (phased, beta, full)
- Success metrics and tracking plan
- Post-launch support or follow-ups
Step 4: Ask for Clarity on Ambiguities
For any vague sections, ask:- “Can you give me a specific example?”
- “What does success look like for this metric?”
- “What’s the biggest risk here?”
- “What could go wrong?”
Step 5: Present the Full PRD
PRD: [Initiative Name] Summary [2-3 sentences describing the feature and its purpose] Contacts
- Product Owner: [Name]
- Design Lead: [Name]
- Engineering Lead: [Name]
- Stakeholders: [Names]
- Primary Goal: [1 sentence]
- Success Metrics:
- [Metric 1]: Target from [X] to [Y]
- [Metric 2]: Target from [X] to [Y]
- [Metric 3]: Target from [X] to [Y]
- Definition of Success: [Qualitative description]
- Target Customer: [Segment name, size]
- Job to Be Done: [1-2 sentences]
- Key Persona(s): [Name, role, use case]
- Problem: [What are they struggling with?]
- Solution: [How we solve it]
- Differentiation: [Why we’re different]
- Core Features:
- [Feature 1]: [Brief description]
- [Feature 2]: [Brief description]
- User Flows: [Link to Figma or description]
- Technical Approach: [If complex, explain the architecture]
- Phasing:
- MVP (v1.0): [Features]
- v1.1: [Follow-up features]
- Assumptions to Validate:
- [Assumption 1]
- [Assumption 2]
- Timeline: [Launch target date]
- Rollout Strategy: [Phased, beta, full]
- Success Metrics: [What we’ll track post-launch]
- Follow-ups: [Next steps or related work]
Edge Cases
- Not enough information: Ask: “What’s your top constraint—is it time, team capacity, or uncertainty about the approach?” Focus the PRD on what matters most.
- Too broad/ambitious: Ask: “If you had to ship this in 2 weeks with minimal scope, what stays?” Build the MVP first; document future phases.
- Misaligned with stakeholders: Note the disagreement explicitly in the PRD. Ask: “Let’s resolve this before we build.” Escalate if needed.
- No metrics defined: Suggest KPIs based on similar features or industry benchmarks. Ask the team to confirm targets.
