Product Charter: Template & Writing Process Steps [with Examples]

Mission Statement

A product mission statement is a clear, short project description that explains the product's main goal. It makes clear who the product is for and what it offers to the target audience. It also includes unique selling points of the product and answers the question, "What do you hope your product will do to make the world a better place?"

Here are some tips on how to write a well-defined product mission statement:

• Make sure it is clear who is the target audience of your product and what it offers to them
• Use the present tense to explain the unique features of your product that others don't have
• Get feedback from your team, then make changes and tighten up.

Project charter example mission statement for Callendly:

We take the work out of connecting with others so you can accomplish more.

Objectives

Product objectives are for developing or managing a product. They usually come from the product strategy's higher-level goals. After that, more specific goals that follow the SMART principles: specific and measurable, achievable, relevant, and time-bound.

You should set at least 3 goals, but no more than 5. You should set expectations that can be met. Start with your product mission to reach your product goals. Then you can set product goals whose results show that you are meeting your product mission:

Say our product is a meetings scheduling application, like Callendly, your vision for the product could be:

The following are example product objectives:

• Book meetings quickly by embedding scheduling into websites
• Use personal calendars to get availability and automate scheduling
• Automatically create video conference link in Calendly events
• Allow tracking conversions from Calendly

Success metrics (KPIs)

We must make it easy for everyone to answer the question, "What does success look like for our product at the end of this cycle?" This can be difficult if they lack concrete guidance and that's why it's important to identify the most important business success metric for each goal.

The product team can use business success metrics to measure the effectiveness of the new product strategies. Success metrics are also known as key performance indicators (KPIs). There is no one-size-fits-all success number; most teams use several different solutions to determine success.

Example success metrics:

• Decrease average time for scheduling meetings to 5 seconds
• Increase monthly users using the reporting feature to 5000
• Reduce the number of ticket escalations to less than 20 a month

Assumptions

Assumptions are a factor in any project that is considered true, real, or certain without empirical proof or demonstration. They help define the boundaries of the product.

Keep in mind, that every project assumption poses a project risk. To effectively manage risk, every project manager needs to know how to properly assess, document, and communicate assumptions.

For example, if your company's brand is built on integrating with other software, you should emphasize this with principles like:

• Calendly helps you book better meetings faster by syncing and integrating everything in one intuitive platform.
• Calendly never stores passwords, content, or PII associated with your team’s accounts.
• Easily adjust as you grow and scale - embed Calendly into your team’s existing tools and processes.

Use Opportunity Solution Tree for visual clarity

An Opportunity Solution Tree (OST) is a visual tool that helps with the product discovery process by arranging ideation flows, experiments, and finding non-linear gaps.

Opportunity Solution Trees have four basic, connected components as follows:

• Outcomes - quantifiable success metrics
• Opportunities - customer problems, needs, desires, and pain points
• Solutions - Potential solutions you could build that exploit an opportunity in a way that delivers the outcome
• Experiments - Activities the team runs to test key assumptions

Ensure your team has a well-framed product outcome

Opportunity Solution Trees don't work without product outcomes. The tree doesn't make sense if a team doesn't use it to work toward a goal. That's the whole point.

The product team may struggle when an outcome is not clearly outlined. Check if it meets the following criteria:

• Connected to the Product Strategy
• Measurable
• Agreed upon at the beginning of the effort
• Reflects observable user behavior
• Not too broad
• Within the product team's control
• A leading indicator, not a lagging indicator

Share and collaborate

The problems we face today require more than an idea, they require collaboration with other organizations and the support of people who are part of the solution.

A successful product team should develop a high level of trust with peers, senior managers, and company leadership. In my experience, one of the most effective ways to develop trust is to explain the mindset, ask for feedback, and genuinely consider it.

Don't just set the product development charter upfront, keep this document in Google Drive or another shared solution where multiple people can view and edit it. This way teams who see the most impact from the project can put in their two cents before you present it to other stakeholders.

Engagement is needed with people who are delivering and receiving the ideas, as well as other partners who may have different ideas. Proactively scheduling a session to walk through an OST is a great way to facilitate that sort of conversation.

Whatever format you choose, make sure to share your project charter with everyone who plays a significant role once you finalize it and begin your project.

Communicate clearly the creative process to everyone

The work you'll perform when constructing your tree isn't done in isolation from the rest of your procedure. Depending on how you operate, there are certainly many instances when the work you perform with your tree connects to other parts of your workflow.

Good product discovery has a simple underlying structure:

• Start with an outcome (product mission statement/ project overview)
• Discover opportunities (worth pursuing)
• Decide how to measure success (KPIs)

The outcome of Opportunity Discovery is an opportunity, i.e. a user problem, that is worth pursuing instead of all the others. In this case, we have solid evidence that the outcome has strong customer value, can be built within our technical environment, and fits our business goals accordingly. After we've done all this research, we boil it all down (converge) into a clear Product Vision that guides our next planning steps.

The opportunity space is always evolving. Good product discovery teams engage in two key activities month after month: customer interviewing and assumption testing. Interviewing helps us discover opportunities and assumption testing supports us to discover new solutions.

Project risks should focus on customer value, business viability, and technical feasibility. These three are in a constant state of flux — de-risking a top assumption in the value bucket can change the viability entirely, and de-risking a top feasibility assumption may turn an aspect of the assumed value into a distant dream, and so on.

Consider replacing feature-based roadmap items with outcomes or opportunities from your tree, and align product development cycles to incorporate experiments to test your ideas.