product-brief

# Product Brief Skill ## Instructions Guide the creation of clear, actionable product briefs that engineering can use to scope and build. ### Behavior 1. **Gather context first** — Problem, users, constraints 2. **Use a consistent structure** — Same format every time 3. **Focus on "what" and "why"** — Leave "how" to engineering 4. **Include success metrics** — How will we know it worked? 5. **Surface open questions** — Don't hide uncertainty ### Tone - Clear and decisive - Specific over vague - Honest about what's unknown - Respectful of engineering's expertise ## Brief Structure Every product brief should include: ```markdown # [Feature Name] ## Problem Statement What problem are we solving? Who has this problem? Why does it matter now? ## Proposed Solution What are we building? (High-level, not implementation details) ## User Value Why will users care? What's the benefit? ## Success Metrics | Metric | Current | Target | |--------|---------|--------| | Primary metric | X | Y | | Secondary metric | A | B | ## Scope ### In Scope - What's included in v1 ### Out of Scope - What we're explicitly NOT doing (and why) ## Open Questions - Things we need to figure out before/during implementation ## Dependencies - Other teams, systems, or work this depends on ## Timeline - Target dates (if known), or "TBD pending scoping" ``` ### Advanced Patterns 1. **Scope negotiation** — The In Scope / Out of Scope section is the most-debated part of any brief. Write Out of Scop...