Claude Code Setup for Product Managers

# CLAUDE.md — Product Manager
> Version: 2026-02-17 | Difficulty: intermediate

## What Your AI Can Now Do
- Draft a full PRD from a problem statement — complete with bet, success metric, scope, and non-goals
- Break any PRD into engineering tickets with acceptance criteria and story points
- Generate sprint status reports by pulling data from GitHub issues and PRs
- Pre-load customer context before every call so you walk in prepared
- Flag scope creep early by comparing sprint commitments against actual progress

---

## Quick Start
1. Define your team and product area in the About Me section below
2. Run `/prd` with a problem statement to see a full PRD draft in seconds
3. Connect GitHub and Google Drive in `.env` for live data pulls
4. Add your current roadmap to `product/roadmap/` so Claude knows your priorities
5. Run `/status` on Monday morning to get your first automated sprint report

---

## About Me
B2B SaaS product manager owning roadmap, sprint planning, and activation/retention metrics.
Team: 2 designers, 8 engineers, 1 data analyst. We ship bi-weekly.
I think in bets, not features — every initiative ties to a measurable outcome.

---

## Pre-Built Commands

| Command | What It Does |
|---------|-------------|
| `/prd` | Draft a PRD from a problem statement — bet, metrics, scope, non-goals, and open questions |
| `/tickets` | Break a PRD into engineering tickets with acceptance criteria and story points |
| `/status` | Generate sprint or release status from GitHub issues and merged PRs |
| `/customer-prep` | Pull account context and recent support tickets before a customer call |
| `/release-notes` | Draft user-facing release notes from shipped PRs and closed issues |

---

## How Claude Connects to Your Tools

| Tool | Why You Need It |
|------|----------------|
| GitHub | PR and issue tracking — the source of truth for what actually shipped |
| Google Workspace | PRDs, research docs, stakeholder updates, competitive analysis |
| Google Calendar | Sprint ceremonies, customer calls, design reviews |
| Memory | Customer patterns, team velocity history, stakeholder preferences |

### Setup
```bash
# Required in .env
GITHUB_TOKEN=your-token
GOOGLE_WORKSPACE_EMAIL=your-email@company.com
```

---

## Product Rules
- **MUST:** Every PRD starts with a one-line "bet we're making" before any feature detail
- **MUST:** Tag every feature with the metric it moves — no metric, no prioritization
- **MUST:** Talk to at least 3 customers before writing any PRD — internal intuition is not validation
- **SHOULD:** Keep tickets under 300 words — if it needs more, the scope is wrong
- **MUST:** Answer engineer questions in PR reviews within 2 hours, not "next sync"
- **SHOULD:** Write the problem and acceptance criteria in tickets — let engineers design the solution
- **MUST:** Customer quotes go in verbatim — never paraphrase pain
- **SHOULD:** Lead stakeholder emails with the decision needed, not the background

---

## Project Structure
```
product/
  roadmap/
  prds/
  research/
  competitive/
  releases/
  metrics/
```

### What These Folders Mean
- `roadmap/` — Quarterly roadmap and prioritization frameworks tied to business goals
- `prds/` — All PRDs organized by quarter (e.g., 2026-Q1-feature-name.md)
- `research/` — Customer interviews, survey results, and analytics deep dives
- `competitive/` — Competitor teardowns and market positioning analysis
- `releases/` — Release notes drafts and changelog history
- `metrics/` — Dashboard definitions, experiment results, and metric baselines

---

## Automation

| When | What Happens | If It Fails |
|------|-------------|-------------|
| PRD saved to Drive | Auto-extract open questions and create a checklist issue in GitHub | Manually review PRD for unresolved questions and create issue |
| Sprint ends (bi-weekly) | Pull shipped PRs and closed issues into draft release notes | Export PR list from GitHub and draft notes manually |
| Customer call on calendar | Pre-load account context and recent support tickets | Check CRM and support tool manually before the call |
| GitHub PR merged | Update relevant PRD status from "In Development" to "Shipped" | Manually update PRD status during weekly review |
| Monday morning | Generate sprint status with at-risk items highlighted | Review GitHub project board and flag blockers in standup |

---

## Gotchas
- **MUST:** "Fast follow" is a lie — if it matters, put it in v1. Fast follows ship 30% of the time
- **MUST:** Metrics without baselines are decoration — measure current state before launching any "improvement"
- **SHOULD:** Bi-weekly shipping means cutting scope, not cramming — if it's Wednesday and scope is at risk, cut
- **MUST:** Never confuse shipping with impact — track the metric after launch, not just the deploy
- **SHOULD:** Roadmap is a communication tool, not a commitment — update it when reality changes

---

## Memory & Learning
Claude builds context over time:
- Product domain knowledge and team velocity patterns across sprints
- Recurring stakeholder preferences and communication styles
- Customer pain points and feature request patterns from logged calls
- What slipped in past sprints and why — used to flag scope creep early
- PRD structure preferences and which formats get engineering buy-in

To save something important: just say "remember that [fact]" in conversation.
To review saved memories: use the `/memory` command to open the memory editor.