# Team Brief

> Write an empowered team brief. Use when the user says "team brief", "product brief", "give the team a problem", "empowered team", "how do I brief engineering", "delegate to the team", "product mission", or wants to give a team clear goals without dictating the solution - even if they don't say "team brief".

- Skill: `qa-aman/team-brief` (Agent Skill)
- Install (CLI): `npx skillmds@latest add qa-aman/team-brief`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qa-aman/team-brief/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: qa-aman (https://skillmd.com/u/qa-aman)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qa-aman/team-brief

---


## Overview

Based on **Empowered** by Marty Cagan. The difference between a feature team and an empowered product team is what they're asked to deliver. Feature teams get a roadmap of features to build. Empowered teams get a problem to solve and the autonomy to figure out how.

A team brief is the artifact that makes empowerment concrete. It gives the team a clear outcome to own, context to understand the problem, and constraints to work within - without prescribing the solution.

## Workflow

### Step 1: Define the team's mission (one sentence)
The mission is why this team exists. It should be stable for 12-24 months.
Format: "Enable [user type] to [achieve outcome] so that [business result]."

Example: "Enable [your product] users to onboard independently so that time-to-first-value drops under 3 days."

### Step 2: Set the objective (this quarter)
One specific outcome the team owns this quarter. This is NOT a feature - it's a measurable change in user or business behavior.

Bad: "Build a new onboarding flow"
Good: "Increase onboarding completion rate from 45% to 70%"

### Step 3: Provide context
Give the team what they need to make good decisions:
- **Customer insight** - what you know about the problem from discovery
- **Business context** - why this matters to the company now
- **Constraints** - technical, legal, or business limits they must work within
- **What's already been tried** - avoid sending them down known dead ends

### Step 4: Define success metrics
Quantify the objective:
- Primary metric (the one that matters most)
- Guard metrics (things the team must NOT break)

Guard metrics are as important as success metrics. A team that hits the primary metric by breaking something else hasn't succeeded.

### Step 5: Set the time horizon
How long does the team have to achieve this objective? Cagan's guidance: long enough to make meaningful progress (a quarter minimum), short enough to create accountability.

### Step 6: State what's NOT their problem
Explicit scope boundary. Prevents teams from expanding into adjacent problems and losing focus.

## Anti-Patterns

**1. Briefing solutions, not problems**
Bad: "Your brief is to build a dashboard with these 5 widgets."
Good: "Your brief is to help [user type] track their progress. You decide how."

**2. Too many objectives**
Bad: Team brief with 4-5 objectives.
Good: One primary objective per quarter. Cagan: focus is the most important gift you can give a team.

**3. No guard metrics**
Bad: Brief with only success metric.
Good: Always include what must NOT get worse. Teams optimize for what's measured.

**4. Brief without context**
Bad: Handing a team a metric without customer insight.
Good: Brief includes what you know from discovery so the team doesn't start from zero.

## Quality Checklist

- [ ] Mission is stable (12-24 months), objective is this quarter
- [ ] Objective is an outcome (behavior change), not an output (feature shipped)
- [ ] Context includes customer insight, business reason, and constraints
- [ ] Primary success metric is defined and measurable
- [ ] Guard metrics listed (what must not break)
- [ ] Out-of-scope boundary is explicit
- [ ] Time horizon is clear