qa-aman 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