pm checklists
This commit is contained in:
Brian Madison
266
CURRENT-V2/docs/templates/pm-checklist.md
vendored
Normal file
266
CURRENT-V2/docs/templates/pm-checklist.md
vendored
Normal file
@@ -0,0 +1,266 @@
|
||||
# Product Manager (PM) Requirements Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
|
||||
|
||||
## 1. PROBLEM DEFINITION & CONTEXT
|
||||
|
||||
### 1.1 Problem Statement
|
||||
|
||||
- [ ] Clear articulation of the problem being solved
|
||||
- [ ] Identification of who experiences the problem
|
||||
- [ ] Explanation of why solving this problem matters
|
||||
- [ ] Quantification of problem impact (if possible)
|
||||
- [ ] Differentiation from existing solutions
|
||||
|
||||
### 1.2 Business Goals & Success Metrics
|
||||
|
||||
- [ ] Specific, measurable business objectives defined
|
||||
- [ ] Clear success metrics and KPIs established
|
||||
- [ ] Metrics are tied to user and business value
|
||||
- [ ] Baseline measurements identified (if applicable)
|
||||
- [ ] Timeframe for achieving goals specified
|
||||
|
||||
### 1.3 User Research & Insights
|
||||
|
||||
- [ ] Target user personas clearly defined
|
||||
- [ ] User needs and pain points documented
|
||||
- [ ] User research findings summarized (if available)
|
||||
- [ ] Competitive analysis included
|
||||
- [ ] Market context provided
|
||||
|
||||
## 2. MVP SCOPE DEFINITION
|
||||
|
||||
### 2.1 Core Functionality
|
||||
|
||||
- [ ] Essential features clearly distinguished from nice-to-haves
|
||||
- [ ] Features directly address defined problem statement
|
||||
- [ ] Each feature ties back to specific user needs
|
||||
- [ ] Features are described from user perspective
|
||||
- [ ] Minimum requirements for success defined
|
||||
|
||||
### 2.2 Scope Boundaries
|
||||
|
||||
- [ ] Clear articulation of what is OUT of scope
|
||||
- [ ] Future enhancements section included
|
||||
- [ ] Rationale for scope decisions documented
|
||||
- [ ] MVP minimizes functionality while maximizing learning
|
||||
- [ ] Scope has been reviewed and refined multiple times
|
||||
|
||||
### 2.3 MVP Validation Approach
|
||||
|
||||
- [ ] Method for testing MVP success defined
|
||||
- [ ] Initial user feedback mechanisms planned
|
||||
- [ ] Criteria for moving beyond MVP specified
|
||||
- [ ] Learning goals for MVP articulated
|
||||
- [ ] Timeline expectations set
|
||||
|
||||
## 3. USER EXPERIENCE REQUIREMENTS
|
||||
|
||||
### 3.1 User Journeys & Flows
|
||||
|
||||
- [ ] Primary user flows documented
|
||||
- [ ] Entry and exit points for each flow identified
|
||||
- [ ] Decision points and branches mapped
|
||||
- [ ] Critical path highlighted
|
||||
- [ ] Edge cases considered
|
||||
|
||||
### 3.2 Usability Requirements
|
||||
|
||||
- [ ] Accessibility considerations documented
|
||||
- [ ] Platform/device compatibility specified
|
||||
- [ ] Performance expectations from user perspective defined
|
||||
- [ ] Error handling and recovery approaches outlined
|
||||
- [ ] User feedback mechanisms identified
|
||||
|
||||
### 3.3 UI Requirements
|
||||
|
||||
- [ ] Information architecture outlined
|
||||
- [ ] Critical UI components identified
|
||||
- [ ] Visual design guidelines referenced (if applicable)
|
||||
- [ ] Content requirements specified
|
||||
- [ ] High-level navigation structure defined
|
||||
|
||||
## 4. FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 4.1 Feature Completeness
|
||||
|
||||
- [ ] All required features for MVP documented
|
||||
- [ ] Features have clear, user-focused descriptions
|
||||
- [ ] Feature priority/criticality indicated
|
||||
- [ ] Requirements are testable and verifiable
|
||||
- [ ] Dependencies between features identified
|
||||
|
||||
### 4.2 Requirements Quality
|
||||
|
||||
- [ ] Requirements are specific and unambiguous
|
||||
- [ ] Requirements focus on WHAT not HOW
|
||||
- [ ] Requirements use consistent terminology
|
||||
- [ ] Complex requirements broken into simpler parts
|
||||
- [ ] Technical jargon minimized or explained
|
||||
|
||||
### 4.3 User Stories & Acceptance Criteria
|
||||
|
||||
- [ ] Stories follow consistent format
|
||||
- [ ] Acceptance criteria are testable
|
||||
- [ ] Stories are sized appropriately (not too large)
|
||||
- [ ] Stories are independent where possible
|
||||
- [ ] Stories include necessary context
|
||||
|
||||
## 5. NON-FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 5.1 Performance Requirements
|
||||
|
||||
- [ ] Response time expectations defined
|
||||
- [ ] Throughput/capacity requirements specified
|
||||
- [ ] Scalability needs documented
|
||||
- [ ] Resource utilization constraints identified
|
||||
- [ ] Load handling expectations set
|
||||
|
||||
### 5.2 Security & Compliance
|
||||
|
||||
- [ ] Data protection requirements specified
|
||||
- [ ] Authentication/authorization needs defined
|
||||
- [ ] Compliance requirements documented
|
||||
- [ ] Security testing requirements outlined
|
||||
- [ ] Privacy considerations addressed
|
||||
|
||||
### 5.3 Reliability & Resilience
|
||||
|
||||
- [ ] Availability requirements defined
|
||||
- [ ] Backup and recovery needs documented
|
||||
- [ ] Fault tolerance expectations set
|
||||
- [ ] Error handling requirements specified
|
||||
- [ ] Maintenance and support considerations included
|
||||
|
||||
### 5.4 Technical Constraints
|
||||
|
||||
- [ ] Platform/technology constraints documented
|
||||
- [ ] Integration requirements outlined
|
||||
- [ ] Third-party service dependencies identified
|
||||
- [ ] Infrastructure requirements specified
|
||||
- [ ] Development environment needs identified
|
||||
|
||||
## 6. EPIC & STORY STRUCTURE
|
||||
|
||||
### 6.1 Epic Definition
|
||||
|
||||
- [ ] Epics represent cohesive units of functionality
|
||||
- [ ] Epics focus on user/business value delivery
|
||||
- [ ] Epic goals clearly articulated
|
||||
- [ ] Epics are sized appropriately for incremental delivery
|
||||
- [ ] Epic sequence and dependencies identified
|
||||
|
||||
### 6.2 Story Breakdown
|
||||
|
||||
- [ ] Stories are broken down to appropriate size
|
||||
- [ ] Stories have clear, independent value
|
||||
- [ ] Stories include appropriate acceptance criteria
|
||||
- [ ] Story dependencies and sequence documented
|
||||
- [ ] Stories aligned with epic goals
|
||||
|
||||
### 6.3 First Epic Completeness
|
||||
|
||||
- [ ] First epic includes all necessary setup steps
|
||||
- [ ] Project scaffolding and initialization addressed
|
||||
- [ ] Core infrastructure setup included
|
||||
- [ ] Development environment setup addressed
|
||||
- [ ] Local testability established early
|
||||
|
||||
## 7. TECHNICAL GUIDANCE
|
||||
|
||||
### 7.1 Architecture Guidance
|
||||
|
||||
- [ ] Initial architecture direction provided
|
||||
- [ ] Technical constraints clearly communicated
|
||||
- [ ] Integration points identified
|
||||
- [ ] Performance considerations highlighted
|
||||
- [ ] Security requirements articulated
|
||||
|
||||
### 7.2 Technical Decision Framework
|
||||
|
||||
- [ ] Decision criteria for technical choices provided
|
||||
- [ ] Trade-offs articulated for key decisions
|
||||
- [ ] Non-negotiable technical requirements highlighted
|
||||
- [ ] Areas requiring technical investigation identified
|
||||
- [ ] Guidance on technical debt approach provided
|
||||
|
||||
### 7.3 Implementation Considerations
|
||||
|
||||
- [ ] Development approach guidance provided
|
||||
- [ ] Testing requirements articulated
|
||||
- [ ] Deployment expectations set
|
||||
- [ ] Monitoring needs identified
|
||||
- [ ] Documentation requirements specified
|
||||
|
||||
## 8. CROSS-FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### 8.1 Data Requirements
|
||||
|
||||
- [ ] Data entities and relationships identified
|
||||
- [ ] Data storage requirements specified
|
||||
- [ ] Data quality requirements defined
|
||||
- [ ] Data retention policies identified
|
||||
- [ ] Data migration needs addressed (if applicable)
|
||||
|
||||
### 8.2 Integration Requirements
|
||||
|
||||
- [ ] External system integrations identified
|
||||
- [ ] API requirements documented
|
||||
- [ ] Authentication for integrations specified
|
||||
- [ ] Data exchange formats defined
|
||||
- [ ] Integration testing requirements outlined
|
||||
|
||||
### 8.3 Operational Requirements
|
||||
|
||||
- [ ] Deployment frequency expectations set
|
||||
- [ ] Environment requirements defined
|
||||
- [ ] Monitoring and alerting needs identified
|
||||
- [ ] Support requirements documented
|
||||
- [ ] Performance monitoring approach specified
|
||||
|
||||
## 9. CLARITY & COMMUNICATION
|
||||
|
||||
### 9.1 Documentation Quality
|
||||
|
||||
- [ ] Documents use clear, consistent language
|
||||
- [ ] Documents are well-structured and organized
|
||||
- [ ] Technical terms are defined where necessary
|
||||
- [ ] Diagrams/visuals included where helpful
|
||||
- [ ] Documentation is versioned appropriately
|
||||
|
||||
### 9.2 Stakeholder Alignment
|
||||
|
||||
- [ ] Key stakeholders identified
|
||||
- [ ] Stakeholder input incorporated
|
||||
- [ ] Potential areas of disagreement addressed
|
||||
- [ ] Communication plan for updates established
|
||||
- [ ] Approval process defined
|
||||
|
||||
## PRD & EPIC VALIDATION SUMMARY
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
| -------------------------------- | ----------------- | --------------- |
|
||||
| 1. Problem Definition & Context | PASS/FAIL/PARTIAL | |
|
||||
| 2. MVP Scope Definition | PASS/FAIL/PARTIAL | |
|
||||
| 3. User Experience Requirements | PASS/FAIL/PARTIAL | |
|
||||
| 4. Functional Requirements | PASS/FAIL/PARTIAL | |
|
||||
| 5. Non-Functional Requirements | PASS/FAIL/PARTIAL | |
|
||||
| 6. Epic & Story Structure | PASS/FAIL/PARTIAL | |
|
||||
| 7. Technical Guidance | PASS/FAIL/PARTIAL | |
|
||||
| 8. Cross-Functional Requirements | PASS/FAIL/PARTIAL | |
|
||||
| 9. Clarity & Communication | PASS/FAIL/PARTIAL | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
- List all critical issues that must be addressed before handoff to Architect
|
||||
|
||||
### Recommendations
|
||||
|
||||
- Provide specific recommendations for addressing each deficiency
|
||||
|
||||
### Final Decision
|
||||
|
||||
- **READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design.
|
||||
- **NEEDS REFINEMENT**: The requirements documentation requires additional work to address the identified deficiencies.
|
||||
Reference in New Issue
Block a user