product-brief

name	product-brief
description	Extract product ideas through guided questions and generate PRD

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]


[Early signals of success/failure]

---




 [Assumption 1]
 How to validate: [Test method]
   
 [Assumption 2]
 How to validate: [Test method]


  — [Mitigation strategy]
  — [Mitigation strategy]

---




 [System/API/service dependency]


 [Who needs to be involved]


 [Third-party dependencies]

---



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

---



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

---



 Type  to rank features by effort/impact
 Type  to create detailed user flows
 Type  to generate final PRD
 Type  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]

**Estimated Effort:** [X weeks/sprints]

---

**Next:**
- Type `design flows` to create user flows
- Type `create prd` to generate final PRD
- Type `back` to revise spec

---

Phase 6: Design Flows (Optional)

User triggers with: design flows

Create detailed user flows and screen specs:

## User Flows & Screen Specifications

### Flow 1: [Primary User Journey]

**Entry Point:** [How user arrives]

**Steps:**

#### Step 1: [Screen Name]

**Layout:**
- [Header elements]
- [Main content area]
- [Actions/buttons]

**User Actions:**
- Click [X] → [Outcome]
- Enter [Y] → [Validation rules]
- Cancel → [State change]

**Navigation:**
- Success → [Next screen]
- Error → [Error state]
- Back → [Previous screen]

**Validation Rules:**
- [Field 1]: [Rules]
- [Field 2]: [Rules]

**States:**
- Default: [Description]
- Loading: [What user sees]
- Error: [Error message]
- Success: [Confirmation]

---

#### Step 2: [Next Screen]

[Same structure as Step 1]

---

### Flow 2: [Secondary Journey]

[Same structure as Flow 1]

---

**Next:**
- Type `create prd` to generate final PRD
- Type `back` to revise flows

---

Phase 7: Final PRD

User triggers with: create prd or generate prd

Generate comprehensive PRD combining all previous phases:

# Product Requirements Document
## [Product/Feature Name]

**Author:** [User name]
**Date:** YYYY-MM-DD
**Status:** Draft
**Last Updated:** YYYY-MM-DD

---

## Document Control

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | YYYY-MM-DD | [Name] | Initial draft |

---

## Executive Summary

[2-3 paragraphs covering: what, why, who, success]

---

## Background & Context

### Current State
[What exists today]

### Problem Statement
[The problem we're solving]

### Opportunity
[Why now, why us]

---

## Goals & Success Metrics

### Primary Objective
[The main goal]

### Success Metrics

**Primary:**
- [Metric 1]: [Target]

**Secondary:**
- [Metric 2]: [Target]
- [Metric 3]: [Target]

**Leading Indicators:**
- [Early signal 1]
- [Early signal 2]

---

## Target Users

### Primary Audience
[Detailed description]

### Use Cases
1. **[Use Case 1]**
   - As a [user type]
   - I want to [action]
   - So that [benefit]

2. **[Use Case 2]**
   - As a [user type]
   - I want to [action]
   - So that [benefit]

---

## Solution Overview

[Comprehensive description of what we're building]

---

## Functional Requirements

### Must Have (P0)

#### Requirement 1: [Name]
-  [What it does]
 
 [ ] [Criterion 1]
 [ ] [Criterion 2]
 [ ] [Criterion 3]
  As a [X], I want [Y], so that [Z]


[Same structure]



[Same structure as Must Have]



[Same structure as Must Have]

---




[Reference to flows from Phase 6, or create if skipped]


[High-level screen descriptions]


[How users interact with the feature]

---




 [Requirement 1]
 [Requirement 2]


 [Requirement 1]
 [Requirement 2]


 [System 1]: [What needs to connect]
 [System 2]: [What needs to connect]


 [What data is collected]
 [Where it's stored]
 [How it's used]

---




 [Style guide compliance]
 [Responsive requirements]
 [Accessibility standards]


 [Copy needs]
 [Translation needs]
 [Asset requirements]

---




  [List]
  [Who needs to be involved]
  [Third parties]


  [Dates/milestones]
  [If applicable]
  [Platform limitations]

---




 [Assumption 1]
  [How to test]
  [Consequence]

 [Assumption 2]
  [How to test]
  [Consequence]



| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| [Risk 1] | High/Med/Low | High/Med/Low | [Strategy] |
| [Risk 2] | High/Med/Low | High/Med/Low | [Strategy] |

---



Explicitly not included in this version:
 [Item 1] — [Why/when it might be included]
 [Item 2] — [Why/when it might be included]
 [Item 3] — [Why/when it might be included]

---



 [ ] [Question 1] — Owner: [Name], Due: [Date]
 [ ] [Question 2] — Owner: [Name], Due: [Date]
 [ ] [Question 3] — Owner: [Name], Due: [Date]

---



| Milestone | Target Date | Status |
|-----------|-------------|--------|
| PRD Complete | [Date] | In Progress |
| Design Complete | [Date] | Not Started |
| Dev Complete | [Date] | Not Started |
| QA Complete | [Date] | Not Started |
| Launch | [Date] | Not Started |

---



| Name | Role | Involvement |
|------|------|-------------|
| [Name] | [Role] | [What they do] |
| [Name] | [Role] | [What they do] |

---




[Link to user research, competitive analysis, etc.]


[Links to designs when available]


[Links to technical documentation]

---

 Ready for Review


 [ ] Review with stakeholders
 [ ] Refine based on feedback
 [ ] Get approval to proceed
 [ ] Hand off to design/engineering

---

---

Phase 8: Save & Integration

After generating the PRD:

1. Save the document:

   • Create folder: 04-Projects/[Product Name]/
   • Save as: 04-Projects/[Product Name]/PRD.md

2. Create person pages (if stakeholders mentioned):

   • For each stakeholder mentioned, check if person page exists
   • Create/update pages in People/Internal/ or People/External/
   • Add note in their page referencing this project

3. Link to 03-Tasks/Tasks.md:

   • If user mentioned any immediate actions, suggest creating tasks
   • Link tasks to the project

4. Confirm completion:

## ✅ PRD Created

**Saved to:** `04-Projects/[Product Name]/PRD.md`

**Next Steps:**
1. Review and refine the PRD
2. Share with stakeholders for feedback
3. Use `/project-health` to track progress
4. Create tasks in 03-Tasks/Tasks.md when ready to execute

**Want to:**
- Revise any section → Just tell me what to change
- Create tasks from this PRD → Say "create tasks"
- Share with stakeholders → I can draft an email

---

Navigation Commands

At any phase, users can:

• back or previous — Return to previous phase
• skip to prd — Jump directly to final PRD
• revise [section] — Edit specific section
• start over — Begin from scratch
• save — Save current progress

---

Conversational Style

• Be a thought partner, not an interrogator
• Ask follow-up questions when answers reveal gaps
• Challenge assumptions constructively
• Suggest alternatives when you spot potential issues
• Keep momentum — don't let the process feel like homework

Good:

"Interesting. If this is for enterprise customers, how do we handle single sign-on? Or is that something we're punting to Phase 2?"

Bad:

"Question 7: Please describe your authentication strategy."

---

Tips for Effectiveness

For the User

• Start with whatever you have — even 1 sentence is enough
• Don't worry about being comprehensive upfront
• The questions will extract what's in your head
• You can always revise and refine

For Dex

• Listen for what's NOT being said
• If scope sounds too big, flag it early
• Connect this feature to their strategic pillars if relevant
• Update person pages for stakeholders mentioned
• Link to existing projects if this builds on something

---

Example Session

User: /product-brief Add notifications to our app

Dex:

## Initial Idea

Add notifications to our app

---

Great, let's flesh this out. A few questions to start:

1. What type of notifications are we talking about — push notifications, in-app alerts, email, or all three?
2. What specific events should trigger notifications?
3. Who are these notifications for — all users, or specific roles?

User: "Push notifications for now. We want to notify sales reps when a lead takes an action in the product."

Dex:

Got it — push notifications for sales reps when leads are active. That helps narrow it.

A few more questions:

1. What actions count as notification-worthy? (e.g., login, feature usage, upgrade intent)
2. Should there be any filtering or preferences? Like "only notify me about my accounts"?
3. What's the business outcome we're driving here — faster response time, more engagement, closing deals faster?

[Conversation continues through phases until PRD is complete]

---

Integration with Dex System

• Pillars: Link PRD to relevant strategic pillar
• Quarter Goals: If this supports a quarterly goal, note it
• Week Priorities: Suggest adding "finalize PRD" to this week if urgent
• People pages: Auto-update stakeholders mentioned in the PRD
• Tasks: Offer to create tasks from the PRD's next steps

---

When to Use This Command

Use /product-brief when:

• You have a product idea but struggle to articulate it
• You need to write a PRD and want help structuring it
• You're pitching an idea and need to flesh it out
• You want to validate your thinking with good questions

Don't use it for:

• Simple feature requests (just describe them normally)
• Already-written PRDs that need editing
• Technical implementation details (that's engineering's job)

---

Refinement After Creation

The PRD isn't set in stone. After creation:

• Say "refine the success metrics section" to iterate
• Say "add a section on localization" to expand
• Say "this scope is too big, help me cut it down" to trim

Dex will update the PRD file directly and maintain version history.

---

Output Quality Checks

Before finalizing the PRD, verify:

• Clear problem statement
• Specific target audience
• Measurable success metrics
• Prioritized feature list (MVP vs later)
• Explicit out-of-scope items
• Key assumptions identified
• Dependencies called out
• Open questions captured

If any are missing, prompt user to fill gaps before finalizing.