Having a well-crafted charter can diminish common problems such as conflicts with other teams.
When your team has a well-crafted charter, you’ll be able to mitigate some of the issues that would otherwise cause conflict. Conflicts with other teams can occur if they’re not properly aligned with what your product team needs. The same goes for conflicts with other functions or departments, as well as conflicts with the organization’s culture or mission.
The best way to avoid these problems is by ensuring that all parties involved in developing your product are on the same page and understand their roles in making it happen successfully. A product team charter provides this clarity because it outlines exactly how decisions are made and who will be responsible for them.
1. Have a clear and concise product mission.
The product team charter is your roadmap to building a successful product. It defines the responsibilities of each team member, but it should also provide a clear and concise mission statement that guides the direction of your product.
With this in mind, we’ve crafted an example of what a good product mission statement might look like:
- The goal is to increase user retention by 20% by December 1st.* This statement has several key elements: it’s clear and concise; it’s specific (it sets a goal); it answers why we’re doing this (increase user retention) and how we’ll do it (by December 1st). A well-written mission statement can be used as reference for individual tasks or decisions made throughout the development process.
- Yours might look different depending on whether you’re aiming for growth, retention or something else entirely!
2. Goals and objectives are based on your product mission.
Goals and objectives are the foundation of your product team charter. They describe what you want to achieve, how you will measure it, and when you hope to accomplish it by. They should be specific, measurable, and achievable with a reasonable amount of effort. If your goal is vague or open-ended (e.g., “improve the user experience”), then it’s difficult for anyone on the team to get behind it because they won’t know how their work contributes specifically to that goal.
You can think about goals as “what” statements—the end result of what you want to achieve—and objectives as “how” statements—the steps you need to take in order for your goal(s) to happen successfully (see Figure 1). As an example, let’s say that one of your goals is improving conversion rates by 10%. Then one way that might help contribute towards this goal would be setting a higher conversion rate objective: increasing A/B testing experiments from two per month up into the five-to-ten range each month starting in March 2020.* We’ll talk more about A/B testing later; but at this point all we’re trying do is illustrate how both types of statements relate directly back down again through our product mission statement; which brings us nicely onto…
3. Identify who should be part of the team.
In addition to the product team charter, you’ll also need to identify who should be on your team. The right people will help you create a winning product. Consider:
- Include the right people with the right skills—no matter what kind of product you’re creating, it’s important that everyone on your team has at least basic knowledge of whatever they’re working on. This means that if you’re building something new (like me), each member of my team should have some background in data science or machine learning before we begin working together and sharing ideas.
- Include people with experience—your job as a manager is to understand which employees have been successful at past projects and build teams around them. This enables faster learning through collaboration because others are able to learn from their peers’ successes and failures rather than having every single person learn independently from scratch every time something new comes along..
- Include people who are available, willing, and able to contribute—the most obvious way someone might become unavailable is by leaving unexpectedly due an emergency situation like illness or injury–but even those situations can be planned for if there’s enough advanced notice given beforehand so everyone knows what tasks may need reallocating accordingly once things settle down again after some time passes by later down the road.”
4. Define how you’re going to measure success.
You will also need to define how you are going to measure success. This can be done by defining it in terms of product usage, revenue, growth, and customer satisfaction. If your charter is focused on a specific problem that needs solving or an opportunity that needs creating, then you might want to look at metrics such as number of users or revenue generated by the team. You may also want to define what constitutes success for individual components within the charter (e.g., “how many people were impacted?”).
In addition to these more traditional metrics that are usually used in Agile teams (such as velocity), there are some metrics that might be important for your team but don’t always get measured:
- Learning: How much did our engineers learn during this iteration? What kind of knowledge did they gain? How will this impact their ability to perform well in future?
- Communication: What level of communication was achieved among technical roles? Were there any red flags here? What should we do better next time?
- Diversity: Are we increasing diversity among our engineering culture over time with positive results like more inclusive projects/roles/leveraging different perspectives etc.?
5. Lay out the process for how you’re making decisions as a team (and how those decisions will ultimately impact users).
One of the most important parts of a product team charter is outlining how the team will make decisions. This should include how you’re going to handle disagreements, how decisions will be made once they’ve been made and who is responsible for each decision.
How you make decisions as a product team will directly affect your users and their experience with your product. It also sets an example for other teams within the company that they should follow when making their own decisions (or explain why they shouldn’t).
For example: “We use a voting process where all members are required . . . [fill in here]. We have one person from each stakeholder group vote on every issue until we reach consensus. If there is more than one option presented at this time, then we allow everyone else on board to vote for which option best represents their needs/expectations from us as developers/designers/content creators/etc. If there are still no clear winners, then we move forward with whichever option was selected by most people during round 1 (this would be our default position). In cases where there has been disagreement among team members over whether an item warrants being addressed now or later (i.e., if some feel strongly it should happen immediately while others believe it can wait), we give each side 5 minutes apiece to present their case before moving forward with the majority-rule process described above.”
6. Getting more specific about team roles and responsibilities can improve focus and accountability (while also helping to eliminate unnecessary confusion).
Once you have a product team charter in place, it’s important to keep it up-to-date and accessible for all team members. As time goes on, your company will continue to grow and change. Your charter should reflect those changes as well. Regularly reviewing your charter can help ensure that everyone is on the same page—and avoid unproductive disagreements down the line.
If you want to go above and beyond with your product team charter, consider sharing it with other key stakeholders in your company’s success: investors (if applicable), board members and leadership at larger companies that are using or considering using your products/services (e.g., customers).
7. Work to break down any internal silos that might be getting in the way of progress or success by generating a shared sense of ownership for the success of the team, overall goals, and/or end-users/customers.
As you work to break down silos and generate a shared sense of ownership, you might find that some areas need more attention than others. The following list provides examples of where this can be useful:
- A sense of ownership for the success of the team overall may be needed if there are one or more members who aren’t fully engaged in working towards that goal.
- If there are issues with how individual teams operate, fostering an environment that encourages collaboration between them should help find solutions to these issues. For example, if one team doesn’t feel comfortable interacting with another due to political reasons or cultural differences, finding ways for members from both groups to interact on a regular basis (such as standing meetings) will encourage better communication across organizational boundaries.
8. Highlight how often communication will happen — along with how it’s going to happen (e.g., Slack, email, Google Docs, etc.).
It’s important to establish how often you plan on communicating with each other. What is the most effective method of communication? Is it email (which has its own issues), or is it some sort of collaborative platform like Slack? How about a project management tool?
If you’re not sure what will work best for you, I recommend testing out different tools and seeing which one works best. If your team is remote, there are many different options available to you that can help facilitate better collaboration between employees (and reduce siloing).
A team charter is a document that defines and guides a team’s behavior while working toward an agreed-upon goal.
A team charter is a document that defines and guides a team’s behavior while working toward an agreed-upon goal. It helps the team stay focused on their work, and helps them understand how they fit into the broader company strategy.
A concise, well-written product team charter should include:
- An overview of why you’re building your product (aka your “why”)
- A clear mission statement that summarizes what you’re trying to accomplish with this product
- A set of core values that describe how you will operate as an organization
Conclusion
The best thing about your product team charter is that it can be iterated on over time. The more you build up this document, the more it will become a tool for helping your team make progress and stay focused on the big picture.
No Comments