product-workflow

Create Product Requirements Document (PRD)

You are tasked with creating a comprehensive Product Requirements Document (PRD) for a feature or project.

PRD Structure

A well-structured PRD includes:

1. Overview

Product Name: [Feature/Project Name]

Version: 1.0

Date: [Current Date]

Author: [Name/Team]

Status: Draft | In Review | Approved

Executive Summary: 1-2 paragraphs summarizing:

• What is being built
• Why it's important
• Expected impact

2. Problem Statement

Current Situation: Describe the existing problem or opportunity:

• What pain points exist?
• Who is affected?
• What's the business impact?

User Needs:

• What do users need?
• Why do they need it?
• What alternatives are they using?

Example:

## Problem Statement

Users currently struggle to export their data from the platform. They have
to manually copy-paste information or take screenshots, which is:
- Time-consuming (30+ minutes for 100 records)
- Error-prone (manual entry mistakes)
- Frustrating (users complain in 15% of support tickets)

Business impact: We lose ~5 customers per month to competitors who offer
export functionality, representing $60K ARR.

3. Goals and Success Metrics

Business Goals:

• What business objectives does this support?
• Expected revenue impact
• Cost savings
• Market positioning

User Goals:

• What will users be able to do?
• How will their experience improve?
• What problems will be solved?

Success Metrics (SMART):

• Specific: Clearly defined
• Measurable: Quantifiable
• Achievable: Realistic
• Relevant: Tied to goals
• Time-bound: Deadline specified

Example:

## Goals and Success Metrics

### Business Goals
- Reduce customer churn by 2% (from 5% to 3%)
- Decrease support tickets related to data access by 50%
- Increase user satisfaction score from 7.2 to 8.0

### User Goals
- Export data in < 30 seconds
- Support multiple formats (CSV, JSON, Excel)
- Schedule automated exports

### Success Metrics (6 months post-launch)
- 60% of active users use export feature monthly
- Average export time < 10 seconds
- Support tickets about data access reduced by 50%
- NPS increase of 10+ points

4. Target Users

Primary Users:

• Who will use this feature most?
• What are their characteristics?
• What's their skill level?

Secondary Users:

• Who else will benefit?
• How will they use it?

User Personas:

## Target Users

### Primary: Data Analysts
- Role: Analyze user behavior and generate reports
- Technical skill: Medium-high
- Frequency: 10-15 exports per week
- Pain point: Manual data extraction takes too long
- Goal: Quick access to raw data for analysis

### Secondary: Business Managers
- Role: Review performance metrics
- Technical skill: Low-medium
- Frequency: 1-2 exports per week
- Pain point: Difficulty understanding data format
- Goal: Simple exports for presentations

5. Requirements

5.1 Functional Requirements

Must Have (P0): Critical requirements for launch:

- [ ] FR-001: User can select data range (date range, filters)
- [ ] FR-002: User can choose export format (CSV, JSON)
- [ ] FR-003: System generates export file within 30 seconds
- [ ] FR-004: User can download generated file
- [ ] FR-005: System validates user has permission to export

Should Have (P1): Important but can be deferred:

- [ ] FR-006: User can save export templates
- [ ] FR-007: User can schedule recurring exports
- [ ] FR-008: System emails export file when ready

Nice to Have (P2): Future enhancements:

- [ ] FR-009: User can export to Excel with formatting
- [ ] FR-010: User can create custom export views

5.2 Non-Functional Requirements

Performance:

• Export generation: < 10 seconds for 10K records
• File download: Start within 1 second
• Concurrent exports: Support 100 simultaneous exports
• File size limit: Up to 100MB per export

Security:

• Authentication required
• Authorization check before export
• Audit log all exports
• No sensitive data in URLs
• Encrypted file transfer

Reliability:

• 99.9% uptime for export service
• Graceful failure handling
• Retry failed exports automatically
• Data integrity validation

Usability:

• Intuitive UI requiring no training
• Clear error messages
• Progress indication for long exports
• Accessible (WCAG 2.1 AA compliance)

Scalability:

• Handle 10x current user base
• Support up to 1M record exports
• Queue system for large exports

6. User Stories

Write user stories in the format: As a [user type], I want to [action], so that [benefit]

Examples:

## User Stories

### Must Have
1. As a data analyst, I want to export filtered data to CSV, so that
   I can analyze it in Excel or Python

2. As a business manager, I want to schedule weekly exports, so that
   I have fresh data without manual effort

3. As an admin, I want to see who exported what data, so that I can
   audit data access for compliance

### Should Have
4. As a power user, I want to save export templates, so that I don't
   have to configure the same export repeatedly

5. As a mobile user, I want exports emailed to me, so that I can
   access data on my phone

7. User Experience (UX)

User Flows: Describe step-by-step how users will interact:

## Primary Flow: Basic Export

1. User clicks "Export" button on data table
2. System shows export dialog with options:
   - Format selection (CSV, JSON, Excel)
   - Date range picker
   - Column selector
   - Preview (first 10 rows)
3. User configures options and clicks "Generate Export"
4. System shows progress indicator
5. System generates file and shows download button
6. User clicks download and receives file
7. System shows success message with file details

## Alternative Flow: Scheduled Export

1. User navigates to Export Settings
2. User clicks "Schedule Export"
3. System shows scheduling form:
   - Export configuration
   - Frequency (daily, weekly, monthly)
   - Delivery method (download, email)
4. User saves schedule
5. System confirms and shows next run time

Wireframes/Mockups: Include sketches or descriptions of key screens:

## Export Dialog Mockup

┌─────────────────────────────────────┐
│ Export Data                      [X] │
├─────────────────────────────────────┤
│                                     │
│ Format: [CSV ▼]                    │
│                                     │
│ Date Range:                        │
│ [2024-01-01] to [2024-12-31]      │
│                                     │
│ Columns: [All Columns ▼]          │
│                                     │
│ Preview (10 of 5,234 rows):       │
│ ┌─────────────────────────────┐   │
│ │ Name    │ Email   │ Date    │   │
│ │ John    │ j@...   │ 1/1/24  │   │
│ └─────────────────────────────┘   │
│                                     │
│     [Cancel]  [Generate Export]    │
└─────────────────────────────────────┘

8. Technical Considerations

Architecture:

• High-level technical approach
• Key components
• Third-party services
• Data flow

Dependencies:

• External APIs
• Internal services
• Infrastructure requirements
• Library requirements

Risks and Mitigation:

## Risks

| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| Large exports crash system | High | Medium | Implement queue system, file size limits |
| Data privacy concerns | High | Low | Audit logging, access controls, encryption |
| Poor performance | Medium | Medium | Optimize queries, caching, async processing |

9. Timeline and Milestones

Phases:

## Timeline (12 weeks)

### Phase 1: Design and Planning (2 weeks)
- Finalize requirements
- Create detailed designs
- Technical architecture review
- Get stakeholder approval

### Phase 2: Development (6 weeks)
- Week 1-2: Backend export service
- Week 3-4: Frontend UI
- Week 5-6: Scheduling system

### Phase 3: Testing (2 weeks)
- Unit and integration tests
- User acceptance testing
- Performance testing
- Security review

### Phase 4: Launch (2 weeks)
- Beta release to 10% of users
- Monitor metrics and gather feedback
- Fix critical bugs
- Full rollout

### Milestones:
- [ ] 2024-03-01: PRD approved
- [ ] 2024-03-15: Design complete
- [ ] 2024-04-30: Development complete
- [ ] 2024-05-15: Testing complete
- [ ] 2024-06-01: Launch to production

10. Open Questions

Track unresolved questions:

## Open Questions

1. **File retention:** How long should we keep generated export files?
   - Options: 24 hours, 7 days, 30 days
   - Need to decide: Week of 3/15

2. **Rate limiting:** Should we limit exports per user?
   - Need input from infra team
   - Decision needed by: 3/20

3. **Pricing:** Should large exports be a paid feature?
   - Need product/finance alignment
   - Decision needed by: 3/25

11. Out of Scope

Explicitly state what's NOT included:

## Out of Scope (for v1)

- Real-time data streaming
- Export to Google Sheets API
- Custom report builder
- Mobile app export functionality
- Bulk export via API (planned for v2)

12. Appendix

References:

• Market research
• User research findings
• Competitive analysis
• Technical specs

Glossary:

• Define technical terms
• Clarify acronyms

Begin by gathering information about the feature or project and creating a comprehensive PRD following this structure.

Add Changelog

You are tasked with creating or updating a CHANGELOG.md file following the Keep a Changelog format.

Changelog Format

Follow the Keep a Changelog specification:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added
- New features that have been added

### Changed
- Changes in existing functionality

### Deprecated
- Features that will be removed in upcoming releases

### Removed
- Features that have been removed

### Fixed
- Bug fixes

### Security
- Security vulnerability fixes

## [1.0.0] - 2024-01-15

### Added
- Initial release
- User authentication
- API endpoints for CRUD operations

[Unreleased]: https://github.com/user/repo/compare/v1.0.0...HEAD
[1.0.0]: https://github.com/user/repo/releases/tag/v1.0.0

Process

1. Analyze Changes

Review recent commits, pull requests, and changes to understand:

• What features were added
• What was changed or improved
• What bugs were fixed
• What was deprecated or removed
• Any security fixes

2. Categorize Changes

Organize changes into categories:

Added - New features

• New API endpoints
• New components
• New functionality
• New configuration options

Changed - Modifications to existing features

• Updated dependencies
• Refactored code
• Modified behavior
• Performance improvements

Deprecated - Features marked for removal

• APIs being phased out
• Configuration options being replaced
• Functions marked as deprecated

Removed - Deleted features

• Removed APIs
• Deleted files or modules
• Dropped support for versions

Fixed - Bug fixes

• Corrected behavior
• Resolved issues
• Patched errors

Security - Security-related changes

• Vulnerability patches
• Security improvements
• Authentication fixes

3. Write Clear Entries

Each entry should:

• Start with a verb (Added, Fixed, Updated, etc.)
• Be concise but descriptive
• Include reference to issues/PRs if applicable
• Be user-focused, not implementation-focused

Good Examples:

### Added
- Added user profile page with avatar upload (#123)
- Added support for PostgreSQL database
- Added `/api/v1/users/export` endpoint for CSV export

### Fixed
- Fixed memory leak in WebSocket connection (#456)
- Fixed incorrect calculation in discount logic
- Fixed authentication failure with special characters in password

### Changed
- Updated minimum Node.js version to 18.x
- Improved query performance for user search (50% faster)
- Changed default timeout from 30s to 60s

Bad Examples:

### Added
- Stuff (#123)
- New feature

### Fixed
- Bug fix
- Fixed issue

### Changed
- Updated code

4. Version and Date

Semantic Versioning:

• MAJOR (1.0.0 → 2.0.0): Breaking changes
• MINOR (1.0.0 → 1.1.0): New features, backward compatible
• PATCH (1.0.0 → 1.0.1): Bug fixes, backward compatible

Date Format: YYYY-MM-DD (ISO 8601)

5. Update Links

Add comparison links at the bottom:

[Unreleased]: https://github.com/user/repo/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/user/repo/compare/v1.1.0...v1.2.0
[1.1.0]: https://github.com/user/repo/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/user/repo/releases/tag/v1.0.0

Complete Example

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added
- Added dark mode support with system preference detection
- Added export functionality for user data in JSON and CSV formats

### Changed
- Improved dashboard loading time by 40% through query optimization
- Updated UI components to use new design system

### Fixed
- Fixed issue where notifications weren't displaying on mobile devices (#789)

## [2.1.0] - 2024-03-15

### Added
- Added real-time collaboration features
- Added webhooks for order status updates
- Added TypeScript types for all API responses

### Changed
- Migrated from REST to GraphQL for better query flexibility
- Updated authentication to use JWT tokens instead of sessions

### Deprecated
- Deprecated `/api/v1/users/list` endpoint (use `/api/v2/users` instead)

### Fixed
- Fixed race condition in payment processing (#567)
- Fixed incorrect timezone handling for scheduled tasks
- Fixed memory leak in WebSocket connections

### Security
- Updated dependencies to patch security vulnerabilities
- Added rate limiting to prevent brute-force attacks

## [2.0.0] - 2024-02-01

### Added
- Added support for multiple organizations per user
- Added role-based access control (RBAC)
- Added audit logging for all administrative actions

### Changed
- **BREAKING:** Changed API response format to standardize error handling
- **BREAKING:** Renamed environment variables for consistency
- Updated minimum Node.js version to 18.x

### Removed
- **BREAKING:** Removed deprecated v1 API endpoints
- Removed support for Internet Explorer 11

### Fixed
- Fixed data corruption issue in batch operations (#345)

## [1.0.0] - 2024-01-01

### Added
- Initial release
- User authentication and authorization
- CRUD operations for core resources
- RESTful API with OpenAPI documentation
- Admin dashboard
- Email notifications

[Unreleased]: https://github.com/user/repo/compare/v2.1.0...HEAD
[2.1.0]: https://github.com/user/repo/compare/v2.0.0...v2.1.0
[2.0.0]: https://github.com/user/repo/compare/v1.0.0...v2.0.0
[1.0.0]: https://github.com/user/repo/releases/tag/v1.0.0

Guidelines

• User Perspective: Write for users, not developers
• Be Specific: Provide context and details
• Group Related: Related changes go together
• Link Issues: Reference issue/PR numbers
• Breaking Changes: Clearly mark with "BREAKING:"
• Keep Updated: Update with each release
• Unreleased Section: Track ongoing work

Process Steps

1. If CHANGELOG.md doesn't exist, create it with the standard header
2. Review git history or changes since last version
3. Categorize changes appropriately
4. Write clear, user-focused descriptions
5. Add or update version section with date
6. Update comparison links
7. Ensure breaking changes are clearly marked

Begin by analyzing the project changes and creating or updating the CHANGELOG.md file.