10 · Project — Product Team Charter & Rituals Plan¶
A single deliverable that combines everything from Level 1: your role clarity (Module 1), your team's vision (Module 3), how decisions get made (Module 4), how alignment happens across squads (Module 5), how you'll mentor your PMs (Module 6), your ritual calendar (Module 7), your org shape (Module 8), and how you'll grow the team through hiring (Module 9). The output is a Product Team Charter — a real document you could hand to a new PM joining your team on day one, or use to align your own manager on how you intend to run things.
What you'll build¶
A single document (aim for 2-4 pages, not a sprawling wiki) with these sections:
- Team mission and vision (from Module 3)
- Org shape — how the team is structured and why (from Module 8)
- Decision-rights map (from Module 4)
- Ritual calendar (from Module 7)
- Cross-team alignment plan (from Module 5)
- Mentoring & growth approach (from Module 6)
- Hiring plan for the next 2 quarters (from Module 9)
Step 1 — Pick your team¶
Use a real team you lead (or hope to), or invent a plausible one: 3-4 PMs, a clear product domain (e.g., "checkout," "search & discovery," "seller tools"), and a company context (stage, industry) specific enough that your answers below can be concrete rather than generic.
Step 2 — Write the mission and vision section¶
Using the Module 3 template, write the one-page vision: mission sentence, who you serve, the 2-3 year picture, why now, what's explicitly out of scope, and how each of your 3-4 squads ladders up to the mission.
Step 3 — Define the org shape¶
Using the Module 8 worksheet, state which model (by journey stage, segment, platform, feature area, or platform/product split) your team uses and why — tie it explicitly to your team's single biggest current friction point, not a generic justification.
Step 4 — Build the decision-rights map¶
Using the Module 4 template, list at least 8 decision types relevant to your team, their owner, and their delegation level (Tell/Sell/Consult/Delegate).
Step 5 — Lay out the ritual calendar¶
Using the Module 7 table, list every recurring ritual your team runs: cadence, purpose (one sentence, tied to a decision or output it produces), and attendees.
Step 6 — Describe your cross-team alignment plan¶
Using the Module 5 approach, describe how your squads stay aligned with each other (and, in one paragraph, with adjacent teams outside yours) — name the sync cadence and sketch a dependency log with at least 2 plausible entries for your team.
Step 7 — Describe your mentoring approach¶
Using Module 6, describe your 1:1 cadence/structure and how you'll use SBI feedback — include one example SBI statement you'd plausibly give a PM on this team in their first quarter.
Step 8 — Write the hiring plan¶
Using Module 9, state whether you're hiring in the next 2 quarters, and if so, write a short role scorecard (mission, 6-month outcomes, must-haves) for the next PM you'd bring on.
Cheat sheet — charter structure at a glance¶
| Section | Source module | Core question it answers |
|---|---|---|
| Mission & vision | Module 3 | Why does this team exist, and where is it going? |
| Org shape | Module 8 | How is work split, and why this way? |
| Decision rights | Module 4 | Who decides what? |
| Rituals | Module 7 | How does the team stay coordinated day to day? |
| Cross-team alignment | Module 5 | How do we avoid colliding with adjacent teams? |
| Mentoring & growth | Module 6 | How do PMs get better under this Lead? |
| Hiring plan | Module 9 | How does the team grow, and with what bar? |
How It Actually Works¶
A charter only changes team behavior if it gets invoked at the moment a norm is being tested — which means the real design work isn't writing the document, it's deciding which specific future conflicts the charter needs to pre-resolve, because a charter that answers questions no one was actually confused about is a filing exercise, and one that dodges the questions the team will actually fight over (who has final say on scope cuts near a deadline, what "done" means for a shared component) leaves the team exactly as unaligned as before, just with a nicer-looking document. Charters that stick share a structural habit: they get re-opened and amended the first time reality contradicts them, rather than being treated as a one-time artifact — because a charter no one has ever needed to argue about in month two is usually a sign it was never specific enough to bind anyone's behavior in the first place. The teams that actually reference their charter in a live disagreement ("per what we agreed, this decision is mine, not yours") are the ones where it was written by working through real, specific disputes in advance, not by filling in a generic template.
Exercise¶
Assemble the full Product Team Charter (all 7 sections from Steps 2-8) into one document, 2-4 pages. Then do one gut-check pass: read only the mission sentence and the decision-rights map, and ask whether a new PM joining this team would know, from those two things alone, what they own and what they don't. If not, tighten the decision-rights map until they would.
Completing this project means you're ready for Level 2 · Intermediate.