| 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]
[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:
-
Save the document:
- Create folder:
04-Projects/[Product Name]/
- Save as:
04-Projects/[Product Name]/PRD.md
-
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
-
Link to 03-Tasks/Tasks.md:
- If user mentioned any immediate actions, suggest creating tasks
- Link tasks to the project
-
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 phaseskip to prd — Jump directly to final PRDrevise [section] — Edit specific sectionstart over — Begin from scratchsave — 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:
If any are missing, prompt user to fill gaps before finalizing.
Track Usage (Silent)
Update System/usage_log.md to mark product brief as used.
Analytics (Silent):
Call track_event with event_name product_brief_created.
This only fires if the user has opted into analytics. No action needed if it returns "analytics_disabled".
