Product Team Charter Template for Product Teams

Write a charter when a new team forms, when a team's mission or scope changes significantly, when new members join (use it as an onboarding tool), or when the team is experiencing recurring friction around roles, decisions, or communication. If the team is working well without a charter, you do not need one. But most teams benefit from making implicit agreements explicit, especially as they scale beyond 4-5 people. The [Stakeholder Management Handbook](/stakeholder-guide) covers how to align external relationships alongside your internal team agreements.

A team charter defines how the team works together. A [product brief](/templates/product-brief-template) defines what the team is building next. The charter is stable across projects (it changes when the team changes, not when the project changes). The brief changes with each initiative. The charter answers "how do we work?" The brief answers "what are we building?"

No. The charter defines team-level agreements, not individual performance criteria. Individual expectations belong in 1:1 conversations between the team member and their manager. The charter may reference team-level success criteria (sprint accuracy, cycle time), but individual goals are out of scope.

Address it in a 1:1 conversation first. The charter is a social contract, not a legal document. If someone is not following the working agreements, the first question is whether the agreement is reasonable. If the team agreed to core hours of 10am-3pm and someone consistently misses morning standups, that is a 1:1 conversation. If multiple people are ignoring the same agreement, the agreement needs to be revisited in the retro.

2-3 pages. If it is longer, you are over-specifying. Focus on the areas where clarity prevents friction: mission, scope, decision-making, and communication norms. Cut anything that the team already implicitly agrees on. ---