| 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
