Product Manager Skill
Core Design Principles
- Reality First: Ensure solutions are feasible in terms of technology, time, and budget; avoid idealized assumptions
- User Detail Focus: Capture subtle user behaviors and psychological needs through user personas and scenario analysis
- Humanistic Care Integration: Reflect inclusivity (accessibility), emotional support (friendly feedback), and ethical responsibility (privacy protection)
Workflow
Select the corresponding workflow based on user requirement type:
Requirements Analysis Type → Execute Steps 1-2
Product Design Type → Execute Steps 1-4
Document Output Type → Execute Steps 1-5
Step 1: Understand Requirement Background
Confirm with the user:
- What are the business goals? What problem needs to be solved?
- What are the constraints? (Technical capabilities, time, budget)
- Who are the target users?
Step 2: User Research
Build user personas including:
- Basic information (age, occupation, technical proficiency)
- Goals and motivations
- Pain points and challenges
- Behavioral characteristics
See
references/user-persona-templates.md
for detailed templates
Step 3: Feature Design
Output content:
- Feature list (with priorities P0/P1/P2)
- Core user flow
- Exception scenario handling
- MVP scope recommendations
Step 4: Humanistic Care Design
Every solution must include:
Accessibility Design
- Visual: High contrast, adjustable fonts, screen reader support
- Operation: Keyboard navigation, simplified gestures, error-tolerant click areas
- Cognitive: Clear hierarchy, progressive disclosure, consistency
Emotional Design
- Friendly error prompts (no blame on users)
- Positive progress feedback
- Appropriate success celebrations
Privacy and Ethics
- Minimize data collection
- Transparent authorization explanations
- User-controllable data management
Step 5: Document Output
Generate corresponding documents based on requirements and save them to the project directory.
5.1 Output Directory Convention
Recommended Solution (Following Claude Code Official Specifications):
All product documents are saved to the
outputs/<project-name>/docs/
directory:
outputs/
└── <project-name>/ # Project name (e.g., task-management-app)
└── docs/
├── prd.md # Product Requirements Document
├── user-personas.md # User Persona Document
├── feature-specs.md # Feature Specification
├── user-stories.md # User Story Collection
└── requirements.md # Requirements Analysis Report
Example:
outputs/
├── task-management-app/
│ └── docs/
│ ├── prd.md
│ ├── user-personas.md
│ └── mvp-plan.md
└── e-commerce-platform/
└── docs/
├── prd-v1.0.md
└── feature-priority.md
Alternative Solution (Traditional Project Structure):
If your project already has a fixed directory structure, you can also use:
project-root/
└── docs/
├── prd.md
├── user-personas.md
└── requirements-analysis.md
5.2 Output File List
Generate the following documents based on user requirement type:
Requirements Analysis Type Outputs:
- - Requirements Analysis Report
- - User Persona Document
Product Design Type Outputs:
- - Complete Product Requirements Document
- - Feature Specification
- - User Story Collection
Rapid Iteration Type Outputs:
- - MVP Scope Plan
- - Feature Priority List
5.3 File Naming Convention
- Use kebab-case naming convention:
user-authentication-flow.md
- Include version or date (optional): or
- Use descriptive names:
e-commerce-platform-prd.md
5.4 Document Templates
See
references/document-templates.md
for detailed templates, including:
- Complete structure of PRD (Product Requirements Document)
- User story templates
- Feature priority explanations
5.5 Output Summary
After generating documents, provide a brief summary:
- Explanation of document types and purposes
- Number of core features and priority distribution
- Overview of key user personas
- Next-step suggestions (e.g., database design, UI design, etc.)
- Confirmation of file storage location
Output Quality Standards
Every product solution must include:
- Clear problem definition
- At least one user persona
- Priority-ranked feature list
- Humanistic care design points
- Feasibility assessment
Avoid:
- Idealized solutions that ignore constraints
- Designs that ignore edge users
- Feature descriptions without acceptance criteria