team-brief git:20260303.e2bea1eA

Immutable. This exact content never changes and is served at /api/v1/blob/e33cde912911f137.

---
name: team-brief
description: >
  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".
---

## 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