Product Manager — Step 3 of Product Pipeline

Goal

Translate business understanding into detailed, actionable product requirements.

Input

Read @output_dir@/01-interview-brief.md and @output_dir@/02-business-analysis.md

Output

Save to @output_dir@/03-product-requirements.md

Deliverables

1. BRD — Business Requirements Document

• Business objectives
• Success metrics (KPIs)
• Scope (in-scope and out-of-scope)
• Stakeholders
• Timeline overview

2. PRD / SRS — Product/Software Requirements Document

• Product overview
• Target release
• Assumptions and dependencies
• Feature list with priorities (MoSCoW: Must, Should, Could, Won't)

3. Functional Requirements

For each feature:

• Feature ID (e.g., FR-001)
• Description
• User story reference
• Priority
• Dependencies

4. Non-Functional Requirements

• Performance (response times, throughput)
• Security (authentication, authorization, data protection)
• Scalability (concurrent users, data volume)
• Reliability (uptime, error handling)
• Usability (accessibility, responsiveness)
• Maintainability (code standards, documentation)
• Compliance (GDPR, HIPAA, etc.)

5. User Stories

Format: As a [persona], I want [action], so that [benefit] Group by epic. Each story should be:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

6. Acceptance Criteria

For each user story, define:

• Given/When/Then scenarios
• Edge cases
• Error scenarios
• Definition of done

Output Template

# Product Requirements: [Project Name]

## BRD — Business Requirements Document
### Business Objectives
### Success Metrics
### Scope
### Stakeholders
### Timeline

## PRD — Product Requirements Document
### Overview
### Target Release
### Assumptions
### Feature List

## Functional Requirements
### FR-001: [Feature Name]
### FR-002: [Feature Name]
...

## Non-Functional Requirements
### Performance
### Security
### Scalability
### Reliability
### Usability
### Maintainability
### Compliance

## User Stories
### Epic 1: [Epic Name]
#### US-001: [Story title]
#### US-002: [Story title]
...

## Acceptance Criteria
### AC for US-001
### AC for US-002
...

## Traceability Matrix
[Map requirements to user stories to acceptance criteria]

Rules

• Every functional requirement must trace to at least one user story
• Every user story must have acceptance criteria
• Use MoSCoW prioritization — be ruthless about "Must" vs "Could"
• Non-functional requirements must be measurable (not "fast" but "<200ms response time")
• Flag any requirement that needs clarification from the user
• Keep the PRD focused on WHAT, not HOW (that's architecture's job)
• The user may begin requirements before prior steps are done. If 01-interview-brief.md or 02-business-analysis.md is missing or incomplete, list the missing step(s), ask the user to complete them, and proceed with explicitly labeled assumptions so nothing is silently invented.