product-brief

name	product-brief
description	Structured product brief and PRD creation assistant. Use when the user needs to write a product brief, PRD, feature spec, or any document that defines what to build and why. Triggers include "product brief", "PRD", "spec", "feature doc", "write a brief", "define this feature", or when scoping work for engineering.
version	1.8.0
author	Ahmed Khaled Mohamed <[e-mail]>
license	MIT
allowed-tools	Read, Glob, Grep
argument-hint	feature name
tags	["productivity","product-brief"]
compatibility	Designed for Claude Code

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:

# [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 Scope as a decision, not a deferral: "We're not building desktop support because mobile accounts for 92% of this use case's sessions. Revisit threshold: if desktop sessions exceed 20%." This turns "why not?" conversations into data conversations
2. Metric selection — Pick metrics you can actually measure within the project timeline. "Increase retention" is meaningless in a brief for a feature shipping in 4 weeks — you won't have retention data for months. Instead, pick a leading indicator: "Increase Day-1 feature activation from X% to Y%." Every metric in the brief should have a known data source and a realistic measurement window