295 lines
10 KiB
Markdown
295 lines
10 KiB
Markdown
# Product Manager (PM) Requirements Checklist
|
|
|
|
## Purpose
|
|
Comprehensive framework for the Product Manager to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development before handoff to architecture and development teams.
|
|
|
|
## Required Artifacts
|
|
Before proceeding, ensure access to:
|
|
- ✅ `docs/prd.md` - Product Requirements Document
|
|
- ✅ User research findings and market analysis documents
|
|
- ✅ Business goals and strategy documentation
|
|
- ✅ Epic definitions and user stories
|
|
- ✅ Competitive analysis (if applicable)
|
|
|
|
## Project Type Detection
|
|
**Business Application**: [ ] Yes [ ] No
|
|
**Consumer Product**: [ ] Yes [ ] No
|
|
**Technical Platform**: [ ] Yes [ ] No
|
|
**Integration Project**: [ ] Yes [ ] No
|
|
|
|
---
|
|
|
|
## 1. Problem Definition & Context
|
|
|
|
### Business Problem Validation
|
|
- [ ] Clear, specific problem statement articulated
|
|
- [ ] Target user segments specifically identified (not "everyone")
|
|
- [ ] Problem impact quantified with data or estimates
|
|
- [ ] Competitive differentiation clearly explained
|
|
- [ ] Business opportunity sized appropriately
|
|
|
|
### Success Framework
|
|
- [ ] SMART business objectives defined (Specific, Measurable, Achievable, Relevant, Time-bound)
|
|
- [ ] Key performance indicators (KPIs) established
|
|
- [ ] Success metrics directly tied to user and business value
|
|
- [ ] Baseline measurements identified where possible
|
|
- [ ] Timeline for achieving goals realistic and specific
|
|
|
|
### Market Context
|
|
- [ ] User research findings documented and synthesized
|
|
- [ ] Target personas detailed with specific characteristics
|
|
- [ ] User needs and pain points clearly mapped
|
|
- [ ] Competitive landscape analyzed with specific examples
|
|
- [ ] Market timing and opportunity validated
|
|
|
|
**Notes**: {{problem_context_notes}}
|
|
|
|
---
|
|
|
|
## 2. MVP Scope Definition
|
|
|
|
### Core Functionality Assessment
|
|
- [ ] Essential features clearly distinguished from nice-to-haves
|
|
- [ ] Each feature directly addresses the core problem statement
|
|
- [ ] Feature set represents true minimum for viability testing
|
|
- [ ] User value delivery prioritized over technical elegance
|
|
- [ ] Dependencies between features identified and managed
|
|
|
|
### Scope Boundaries Management
|
|
- [ ] Explicit "out of scope" items documented with rationale
|
|
- [ ] Future enhancement roadmap outlined
|
|
- [ ] Scope decisions justified with clear reasoning
|
|
- [ ] MVP complexity minimized while maximizing learning potential
|
|
- [ ] Scope reviewed and refined through multiple iterations
|
|
|
|
### Validation Strategy
|
|
- [ ] Clear method for testing MVP success defined
|
|
- [ ] User feedback collection mechanisms planned
|
|
- [ ] Criteria for transitioning beyond MVP established
|
|
- [ ] Learning hypotheses for MVP explicitly stated
|
|
- [ ] Success/failure decision framework defined
|
|
|
|
**Notes**: {{mvp_scope_notes}}
|
|
|
|
---
|
|
|
|
## 3. User Experience Requirements
|
|
|
|
### User Journey Mapping
|
|
- [ ] Primary user flows documented end-to-end
|
|
- [ ] All entry and exit points identified
|
|
- [ ] Critical decision points and branches mapped
|
|
- [ ] Happy path and alternative flows defined
|
|
- [ ] Edge cases identified (even if deferred)
|
|
|
|
### Usability Standards
|
|
- [ ] Accessibility requirements documented (WCAG 2.1 AA minimum)
|
|
- [ ] Platform and device compatibility requirements specified
|
|
- [ ] Performance expectations from user perspective defined
|
|
- [ ] Error state handling and user recovery planned
|
|
- [ ] User feedback and help mechanisms identified
|
|
|
|
### Interface Requirements
|
|
- [ ] Information architecture outlined clearly
|
|
- [ ] Critical UI components and interactions identified
|
|
- [ ] Content requirements and sources specified
|
|
- [ ] Navigation structure and patterns defined
|
|
- [ ] Responsive design requirements documented
|
|
|
|
**Notes**: {{user_experience_notes}}
|
|
|
|
---
|
|
|
|
## 4. Functional Requirements
|
|
|
|
### Feature Completeness
|
|
- [ ] All MVP features documented with clear descriptions
|
|
- [ ] Features written from user perspective (not technical implementation)
|
|
- [ ] Feature criticality and priority levels indicated
|
|
- [ ] Requirements are testable and verifiable
|
|
- [ ] Cross-feature dependencies explicitly mapped
|
|
|
|
### Requirements Quality
|
|
- [ ] Requirements specific and unambiguous
|
|
- [ ] Focus maintained on WHAT, not HOW
|
|
- [ ] Consistent terminology used throughout
|
|
- [ ] Complex requirements broken into manageable components
|
|
- [ ] Technical jargon minimized and explained where necessary
|
|
|
|
### User Stories & Acceptance Criteria
|
|
- [ ] Stories follow consistent format ("As a [user], I want [goal] so that [benefit]")
|
|
- [ ] Acceptance criteria are specific and testable
|
|
- [ ] Stories appropriately sized for development sprints
|
|
- [ ] Stories maintain independence where possible
|
|
- [ ] Sufficient context provided for implementation teams
|
|
|
|
**Notes**: {{functional_requirements_notes}}
|
|
|
|
---
|
|
|
|
## 5. Non-Functional Requirements
|
|
|
|
### Performance Standards
|
|
- [ ] Response time requirements defined with specific metrics
|
|
- [ ] Throughput and capacity expectations documented
|
|
- [ ] Scalability requirements appropriate for user base
|
|
- [ ] Resource utilization constraints identified
|
|
- [ ] Load handling expectations realistic and measurable
|
|
|
|
### Security & Compliance Framework
|
|
- [ ] Data protection requirements specified
|
|
- [ ] Authentication and authorization needs clearly defined
|
|
- [ ] Regulatory compliance requirements documented
|
|
- [ ] Security testing approach outlined
|
|
- [ ] Privacy considerations and GDPR compliance addressed
|
|
|
|
### Reliability & Operations
|
|
- [ ] System availability requirements defined
|
|
- [ ] Backup and disaster recovery needs documented
|
|
- [ ] Fault tolerance expectations established
|
|
- [ ] Error handling and logging requirements specified
|
|
- [ ] Maintenance and support operational considerations included
|
|
|
|
### Technical Constraints
|
|
- [ ] Platform and technology constraints documented
|
|
- [ ] Third-party service dependencies identified
|
|
- [ ] Integration requirements clearly outlined
|
|
- [ ] Infrastructure and hosting requirements specified
|
|
- [ ] Development environment needs documented
|
|
|
|
**Notes**: {{non_functional_notes}}
|
|
|
|
---
|
|
|
|
## 6. Epic & Story Structure
|
|
|
|
### Epic Organization
|
|
- [ ] Epics represent cohesive business value delivery
|
|
- [ ] Epic goals clearly articulated and measurable
|
|
- [ ] Epics appropriately sized for incremental delivery
|
|
- [ ] Epic sequence and dependencies logically organized
|
|
- [ ] Each epic contributes to overall MVP success
|
|
|
|
### Story Breakdown Quality
|
|
- [ ] Stories broken down to appropriate development size
|
|
- [ ] Each story delivers independent, demonstrable value
|
|
- [ ] Acceptance criteria comprehensive and testable
|
|
- [ ] Story dependencies minimize blocking relationships
|
|
- [ ] Stories aligned with broader epic and product goals
|
|
|
|
### Implementation Readiness
|
|
- [ ] First epic includes all necessary project setup
|
|
- [ ] Development environment setup addressed early
|
|
- [ ] Core infrastructure and scaffolding planned
|
|
- [ ] Local development and testing capabilities established
|
|
- [ ] Deployment pipeline considerations included
|
|
|
|
**Notes**: {{epic_structure_notes}}
|
|
|
|
---
|
|
|
|
## 7. Technical Guidance
|
|
|
|
### Architecture Direction
|
|
- [ ] High-level architecture approach recommended
|
|
- [ ] Critical technical constraints communicated clearly
|
|
- [ ] Key integration points and APIs identified
|
|
- [ ] Performance-critical areas highlighted
|
|
- [ ] Security requirements translated to technical needs
|
|
|
|
### Technical Decision Framework
|
|
- [ ] Criteria for technology selection decisions provided
|
|
- [ ] Key architectural trade-offs articulated
|
|
- [ ] Rationale for recommended approaches documented
|
|
- [ ] Non-negotiable technical requirements emphasized
|
|
- [ ] Areas requiring detailed technical investigation flagged
|
|
|
|
### Implementation Considerations
|
|
- [ ] Development methodology and approach guidance provided
|
|
- [ ] Testing strategy requirements clearly articulated
|
|
- [ ] Deployment and DevOps expectations established
|
|
- [ ] Monitoring and observability needs identified
|
|
- [ ] Technical documentation requirements specified
|
|
|
|
**Notes**: {{technical_guidance_notes}}
|
|
|
|
---
|
|
|
|
## 8. Cross-Functional Requirements
|
|
|
|
### Data Architecture
|
|
- [ ] Core data entities and relationships identified
|
|
- [ ] Data storage and persistence requirements specified
|
|
- [ ] Data quality and validation requirements defined
|
|
- [ ] Data retention and archival policies addressed
|
|
- [ ] Data migration needs documented (if applicable)
|
|
|
|
### Integration Requirements
|
|
- [ ] External system integrations clearly identified
|
|
- [ ] API requirements and specifications documented
|
|
- [ ] Authentication mechanisms for integrations defined
|
|
- [ ] Data exchange formats and protocols specified
|
|
- [ ] Integration testing approach outlined
|
|
|
|
### Operational Requirements
|
|
- [ ] Deployment frequency and process expectations set
|
|
- [ ] Development, staging, and production environment needs defined
|
|
- [ ] Monitoring, alerting, and observability requirements identified
|
|
- [ ] Support and maintenance operational requirements documented
|
|
- [ ] Performance monitoring and analytics approach specified
|
|
|
|
**Notes**: {{cross_functional_notes}}
|
|
|
|
---
|
|
|
|
## 9. Communication & Documentation Quality
|
|
|
|
### Documentation Standards
|
|
- [ ] Clear, jargon-free language used consistently
|
|
- [ ] Documents well-structured with logical flow
|
|
- [ ] Technical terms defined in glossary or context
|
|
- [ ] Diagrams and visual aids included where helpful
|
|
- [ ] Version control and change tracking implemented
|
|
|
|
### Stakeholder Alignment
|
|
- [ ] Key stakeholders identified with roles defined
|
|
- [ ] Stakeholder feedback incorporated and documented
|
|
- [ ] Potential disagreement areas proactively addressed
|
|
- [ ] Communication plan for ongoing updates established
|
|
- [ ] Clear approval process and sign-off requirements defined
|
|
|
|
**Notes**: {{communication_notes}}
|
|
|
|
---
|
|
|
|
## Final Validation Summary
|
|
|
|
### Overall Assessment
|
|
**PRD Completeness Score**: {{completeness_score}}/10
|
|
**MVP Scope Assessment**: {{scope_assessment}} (Focused/Appropriate/Over-Scoped)
|
|
**Implementation Readiness**: {{readiness_level}} (Ready/Nearly Ready/Needs Work)
|
|
|
|
### Critical Issues Identified
|
|
1. {{critical_issue_1}}
|
|
2. {{critical_issue_2}}
|
|
3. {{critical_issue_3}}
|
|
|
|
### Recommendations
|
|
[ ] **APPROVED** - PRD ready for architecture and development
|
|
[ ] **APPROVED WITH CONDITIONS** - Address listed issues before proceeding
|
|
[ ] **REQUIRES REVISION** - Significant gaps need resolution before handoff
|
|
|
|
### Next Steps
|
|
1. {{next_step_1}}
|
|
2. {{next_step_2}}
|
|
3. {{next_step_3}}
|
|
|
|
---
|
|
|
|
## Sign-off
|
|
|
|
**Product Manager**: {{pm_name}}
|
|
**Date**: {{validation_date}}
|
|
**PRD Version**: {{prd_version}}
|
|
|
|
**Final Notes**: {{final_validation_notes}} |