Product charter: What’s included and how to create one (with examples)

Why is the internet buzzing about project charters, but no one talks about building a product charter?

Having a permanent, single source of information about the product that details the why, what, and how is a powerful resource for product teams and stakeholders alike.

What is a product charter?

Contrary to a product canvas, which tends to be a static representation of the product, a product charter is an adaptable representation of the current state of the product.

Having a product charter enables you to define your key goals and metrics in one central place, allowing everyone on your team to understand the long-term expectations and guidance practices for your product. This will help you hone in on your KPIs and set yourself up for success in the future.

What is included in a product charter?

The product charter can be as straightforward or as robust as your context requires. I like to treat it as a central point of contact for everything happening around the product, including:

• Problem definition
• Current strategy
• Changelog
• Roadmap
• Solutions we own
• Lessons learned
• Documentation

All of these would live within the product charter itself, or be linked there as a reference.

The general idea is to connect everything related to the product in a single place.

Benefits of creating a product charter

Some benefits of having a product charter in place include:

• Shared understanding
• Smoother stakeholder communication
• Inspectable artifact
• Learning experience

Shared understanding

Even the most mature product teams tend to drift when it comes to a high-level understanding of the product they are working on.

That’s natural — the day-to-day hustle makes people focus more on their specific area of expertise. You can’t expect the team to always be up-to-date; it’s hard enough for a product manager, let alone a backend engineer.

This is why you should have a single place that contains:

• The high-level vision of the product
• Key metrics
• Main solutions you are working on
• Changelog
• Essential references
• And whatever else you find useful for your team

These will help maintain a shared understanding of what you are working on and why. Personally, I like to rotate one person every sprint who is accountable for ensuring the product charter is up-to-date.

Smoother stakeholder communication

Since I started using a product charter, I’ve managed to save several hours each week that I would’ve previously spent talking to stakeholders.

Whenever I encounter a question such as:

• When did you release X?
• How is metric Y behaving?
• How does feature Z work?
• What are your key learnings from last quarter?

I can just point them to the product charter. Over time, they learn they have everything they need in this one place and don’t bother me with Slack pings as much.

Inspectable artifact

Given the complexity of product development, it’s often hard to get a cohesive picture of what’s happening. There’s just too much going on at the same time.

The product charter mitigates that pain. Having all essential product knowledge and data in one place creates a powerful and cohesive artifact that you can inspect and adapt regularly.

The ability to get a quick snapshot of the product is a good conversation and thought starter.

Learning experience

Creating a solid product charter was very challenging, but the process was a learning experience that gave me deeper insight into my product.

While mapping key metrics, I didn’t fully understand a few key metrics or know how good/bad they were. I started to have doubts about how to allocate part of the project to my team and other teams. I also struggled to think about how I would properly divide parts of the product into solutions that are truly MECE (mutually exclusive and collectively exhaustive).

I planned to spend a few hours putting all the knowledge in one place, but I spent a few days on a steep learning curve regarding the product.

How to create a product charter

There’s no fixed way to build a product charter. The way I approached it was by splitting it into three areas, namely:

• The main sheet with high-level product information
• Solution sheets containing information about solutions we own (features or sets of features)
• References (anything that is relevant but accessible from other places)

Main sheet

The main sheet gives a general overview of the product and works as a homepage connecting to other sources.

Here’s what to include in the main sheet:

1. Basic information  — What department does the product belong to? Who is the product manager of the product? Which team(s) contribute to the product? What’s the primary objective of the product?
2. Product strategy  — What’s the general strategy of the product? What are the main KPIs? What product principles do we adhere to? I like to depict product strategy on such a general level by listing out “key challenges” we are responsible for solving
3. Key metrics  — What are the metrics contributing to the main goals? What are the sub-metrics of these metrics? What are the current numbers? Here I like building a “metrics tree” showcasing the whole metrics ecosystem
4. Team boundaries  — What falls within the scope of the product team? It’s a good reference point whenever the team wants to develop some bottom-up initiative
5. Key user/market information  — Who is your ideal customer? What market do you target? How big is the market?
6. Solutions we own  — What solutions does the team work on to drive results?
7. Relevant references  — Where can I find additional information held in different places?

The main sheet gives an informative snapshot of the product as a whole:

The main sheet gives an informative snapshot of the product as a whole.

Solution sheets

A product is a set of particular solutions. By solutions, I mean features or a group of features.

For example, solutions you own might include:

• User onboarding
• Payment form
• Metering flow, the set of features for which might include:
  • Metering rules
  • Soft touch points included in the metering
  • Premium hardwall

Being explicit about the solutions you own helps you:

• Better understand what you are working on
• Inspect whether the team should exploit (improve current solutions) or expand (innovate new solutions)
• Structure the knowledge and key information in one place

On my solution sheet, I include:

1. Basic information – What’s the solution’s name, who is the target user, and what’s its goal?
2. Key metrics – What are the primary metrics for this solution? How does it contribute to product metrics? What other metrics contribute to the solution’s key metrics?
3. Specification – How exactly does the solution work? What are the user flows and edge cases? If a solution is complex, I keep high-level information here while keeping very detailed documentation as a reference
4. Changelog – How has the solution changed over time, why, and with what outcome?
5. Key learnings – What did we learn over time while iterating on and improving the solution?

A solution sheet offers additional information on a specific solution from the main sheet:

References

Include all relevant links, attachments, etc., in the product charter. The ultimate goal is to have a single source of truth regarding the product in one place.

It won’t work if key information is stored in other places and not connected to the product charter:

Summary

A product charter can become a handy tool in your arsenal. It can help you:

• Keep the team aligned
• Communicate with stakeholders
• Find out relevant information without the hassle
• Inspect and adapt the product from a bird’s eye perspective

There’s no prescribed way to do a product chart well. It depends on the particular context and type of product.

I like to approach creating a product charter by splitting it into three parts:

1. The main sheet includes all core and high-level information regarding the product
2. Solution sheets include detailed information regarding all the solutions we own
3. The references part directs to any external resources that shouldn’t be part of the main sheet for some reason

I strongly encourage you to try building your own product charter. Even if, for some reason, you don’t decide to use it, the process of creating it will boost your critical thinking skills and product knowledge.

Featured image source: IconScout