/product-brief

name: product-brief
description: "Extract a product idea through guided questions and generate a PRD. Use when the user says 'write a PRD', 'spec this feature', 'turn this idea into a brief'. Not for a non-product initiative like hiring or partnerships (use `initiative-kickoff` once shipped); not for checking existing projects' status (use `project-health`)."

Purpose

Extract product ideas from your head through guided questioning, then generate a detailed Product Requirements Document (PRD). Designed for product people who have a vision but need help articulating it clearly.

The Problem This Solves

You have an idea for a product or feature in your mind, but struggle to explain it comprehensively. This command acts as your product thought partner — asking the right questions to extract what you're envisioning, then structuring it into a PRD ready for a team to execute.

Usage

/product-brief [initial idea]

**Examples:**

• `/product-brief Add a notification system to our app`
• `/product-brief Build a customer feedback portal`
• `/product-brief Create an onboarding flow for new users`
• `/product-brief` (prompts you for the idea)

---

Process Flow

Phase 1: Capture Initial Idea

**If no idea is provided:** Ask: "What product or feature are you thinking about?"

• Wait for their description (1 sentence to several paragraphs)
• Capture it as the starting point

**If idea is provided:** Start with whatever the user provides:

• Could be 1 sentence or 5 paragraphs
• Capture it as the starting point
• Don't judge, just absorb

Display:

## Initial Idea

[User's description]

---

**Next:** I'll ask a few questions to understand this better.

---

Phase 2: Clarifying Questions (Conversational)

**Important:** Ask questions conversationally, not as a survey. 2-3 questions at a time, then wait for answers before asking more.

**Question Strategy:**

**Round 1 (Critical Context):**

• What problem does this solve?
• Who is this for?
• What success looks like?

**Round 2 (Constraints & Scope):** Based on Round 1 answers, ask about:

• Timeline expectations
• Technical constraints
• Existing systems to integrate with
• What's explicitly out of scope

**Round 3 (User Experience):**

• How do users discover this?
• What's the core user journey?
• What actions should be easy vs hard?

**Round 4 (Success & Validation):**

• How will we know this succeeded?
• What are we assuming that needs validation?
• What dependencies exist?

**Adaptive questioning:** If user mentions stakeholders, budget, or other context early, adjust questions accordingly. Don't ask what you already know.

After each round, acknowledge answers briefly and transition naturally: > "Got it. That helps me understand [X]. A few more questions about [Y]..."

---

Phase 3: Understanding Summary

Before moving forward, confirm you captured the vision correctly:

## What I Heard

**The Problem:**
[Synthesized problem statement]

**Target Users:**
[Who this is for]

**Core Value:**
[The main benefit/outcome]

**Key Constraints:**
[Timeline, technical, scope boundaries]

**Assumptions to Validate:**
[Things we're assuming but should test]

---

**Does this capture your vision? Type "yes" to continue or correct anything above.**

If user corrects, update and re-confirm.

---

Phase 4: Spec Doc

User triggers with: `spec doc` or `create spec`

Generate structured product spec:

# Product Spec: [Feature/Product Name]

**Date:** YYYY-MM-DD
**Owner:** [User's name]
**Status:** Draft

---

## Executive Summary

[2-3 sentence pitch: what this is and why it matters]

---

## Problem Statement

### Current Situation
[What exists today]

### Pain Points
- [Specific pain 1]
- [Specific pain 2]
- [Specific pain 3]

### Impact of Inaction
[What happens if we don't build this]

---

## Target Audience

### Primary Users
[Who will use this most]

### Secondary Users
[Who else benefits]

### User Characteristics
- [Key trait 1]
- [Key trait 2]
- [Key trait 3]

---

## Solution Overview

[High-level description of what we're building]

---

## Key Features & Functionality

### Must Have (MVP)
1. **[Feature 1]**
   - Description
   - Why it's critical
   
2. **[Feature 2]**
   - Description
   - Why it's critical

### Should Have (Phase 2)
1. **[Feature 3]**
   - Description
   - Why it's valuable

### Nice to Have (Future)
1. **[Feature 4]**
   - Description
   - Why it's desirable

---

## Success Metrics

### Primary Metric
[The one number that matters most]

### Secondary Metrics
- [Metric 2]
- [Metric 3]

### Leading Indicators
[Early signals of success/failure]

---

## Assumptions & Risks

### Key Assumptions
1. [Assumption 1]
   - How to validate: [Test method]
   
2. [Assumption 2]
   - How to validate: [Test method]

### Risks
1. **[Risk 1]** — [Mitigation strategy]
2. **[Risk 2]** — [Mitigation strategy]

---

## Dependencies

### Technical
- [System/API/service dependency]

### Team
- [Who needs to be involved]

### External
- [Third-party dependencies]

---

## Out of Scope

Explicitly not included:
- [Thing 1]
- [Thing 2]
- [Thing 3]

---

## Open Questions

- [ ] [Question 1]
- [ ] [Question 2]
- [ ] [Question 3]

---

**Next Steps:**

- Type `prioritize` to rank features by effort/impact
- Type `design flows` to create detailed user flows
- Type `create prd` to generate final PRD
- Type `back` to revise anything above

---

Phase 5: Prioritization (Optional)

User triggers with: `prioritize`

Create effort/impact matrix:

## Feature Prioritization

| Feature | Impact | Effort | Priority | Rationale |
|---------|--------|--------|----------|-----------|
| [Feature 1] | High | Low | P0 | [Why] |
| [Feature 2] | High | Medium | P0 | [Why] |
| [Feature 3] | Medium | Low | P1 | [Why] |
| [Feature 4] | Low | High | P2 | [Why] |

### Recommended MVP Scope

Based on high impact + reasonable effort:
1. [Feature 1]
2. [Feature 2]
3. [Feature 3]

**