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.
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.
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:
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.
Some benefits of having a product charter in place include:
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:
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.
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:
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.
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.
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.
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 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:
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.
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:
Being explicit about the solutions you own helps you:
On my solution sheet, I include:
A solution sheet offers additional information on a specific solution from the main sheet:
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:
A product charter can become a handy tool in your arsenal. It can help you:
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:
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Real user monitoring is the process of collecting information about how users interact with your product as they’re interacting with it.
In product management, unconscious biases can impact decision making in various activities like designing and user research.
Michelle Monaco, Vice President of Product Management at Truepill, discusses her experience leading fully remote teams.
In this article, we’ll discuss outcome-driven roadmaps and why they can actually be more efficient and productive than feature-driven ones.