team-brief

---

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