Why a Product Team Charter Will Accelerate Your Team
We’ve all been there.
Our mom (or anyone else) asks, “What do you do?”, and we respond with “I’m a product manager”. Next we see a facial expression that clearly means “What is that?”. Then we struggle to explain what a product manager is, usually surrendering after a minute or two when it becomes clear that we’ve done nothing to improve their understanding.
This happens all the time.
After we’ve done this dance 20-30 times, most of us start to punt with “I’m in software” or something similarly vague to save time.
We don’t get the question of ‘what is a product manager’ from coworkers very often. Hopefully that’s because our coworkers, leadership team, and product managers all have a common set of expectations for product.
But what if they don’t?
If the company is not aligned on what to expect from the product team, there will be tremendous friction that reduces the team’s ability to efficiently and effectively create great products.
Though it may seem surprising, this misalignment of expectations and the subsequent friction happens more often than we might think.
Why would there be any confusion?
It seems counter-intuitive that there could be confusion about why such an important team exists and what their role at the company is, but there are several key reasons this can happen.
The Product Role Is Inherently Hard to Understand
To start with, Product is a hard role to understand - at least, more difficult than other typical roles. We can be doing something different every day, and the number of variant activities could be any one of 100 things. Even for Product Managers, it’s hard to explain all the things you do in a way that people understand it.
Most People Only Observe A Small Part of the Product Role
Non-product roles who work with product can easily misunderstand what a product person is responsible for because they only see a small slice of what Product does. We are working with people from almost every discipline at the company in service to creating a great product that serves customers in a way that makes the business successful. As the ‘hub of the wheel’ working with all of these spokes, few of these peers will observe and understand the full range of activities we are involved in. This can lead many to believe they understand when they truly only understand the small subset they have observed.
Product Roles Are Inconsistent Across Companies
Adding to the confusion is the fact that more than almost any other role Product is wildly divergent at different companies, with different roles, responsibilities, and even titles.
A Product Manager at Amazon is fundamentally different than a Product Manager at Oracle, yet they both have the same title. There is so much divergence that the titles have mostly become meaningless - you can’t know what someone was responsible for based on title or company.
What this means is any knowledge or expectations that a product manager or their peers bring from prior companies is almost guaranteed to be wrong. The definition of what Product is and does is company-specific.
We Assume Everyone Understands
Many organizations assume everyone understands what product is and what they do without ever specifically defining it, communicating it, or repeating it.
Defining roles is not something that most organizations routinely do; we can safely define the role/org once and rely on assumptions and observations most of the time.
We don’t need to define what Sales is, we don’t need to define what Engineering is. There is not muscle memory around defining roles and responsibilities at smaller more innovative companies - that feels like something for huge companies or older-guard companies like IBM.
Without defining what Product means at our company, everyone is left to define it for themselves.
How Inconsistent Expectations Slow Us Down
The product team always has too many things to do, so it is critical that they prioritize their time effectively or they can easily miss important work or burn out trying to do it all.
Intentional Over-Investment
Without a clear definition of the charter of the Product team, the team will prioritize based on their internal definition of what a product manager is and how to most effectively succeed at that definition. If their definition is different than the company expects, they will be perpetually off-course.
For example, maybe a product manager believes that they need to define the market segmentation, but at our organization the Marketing team does that. They will spend far too much time researching marketing segments and trying to define them, when they could easily partner with marketing.
Or maybe the PM believes that their job is to ‘drive engineering team growth’, but at our organization the Engineering manager does that. They will spend a lot of time understanding each person on the engineering team, their desires and objectives and trying to service those desires with their prioritization when they could just partner with the engineering manager on those things.
Unintentional Over-Investment
Our product team will also struggle to de-prioritize the many requests they get from their counterparts in other functional areas like Sales, Success, Marketing, Engineering, or Design.
Why not get on every sales call that involves your product? Why not spend 3 days per week with the success team auditing cases? Why not sit in on every code review or design working session? Isn’t that your job?
All of the time spent with these teams will reduce the time that product spends on the other critical functions of their role.
Extra Friction
Even if our product team has an accurate idea of where they should focus their time, if their peers aren’t on the same page there will be a lot of friction day in and day out.
For example, if the both the product team and design team believe they own customer research, waste surrounding research activities. We may have duplicated efforts, where both teams research the same topics, and then struggle to align on results. We may have disagreement on what to research, when, and how. These disagreements will slow the team in making decisions, and make it harder and harder for design and product to work together.
Imagine this happening with potentially every single person a product manager works with: it would be and is exhausting.
All of which is wasted time that could be resolved with a clear definition, aligned across organizations and clearly communicated.
Poor Communication Channels
Because the product manager role is cross-functional, they rely heavily on their cross-functional peers to loop them into the right information at the right time. If these partner functions (sales, engineering, marketing, etc) don’t understand the product function, they won’t know what is relevant or what is not.
For example, if the support team doesn’t understand that product is always looking for the underlying ‘why’ behind a customer need. In that case, when a customer asks for a capability, the support team may not ask about the why - and product will either not know, or have to go back and talk with the customer again. The support team may not capture the why, or share it with product.
If the other functional teams have clarity about product, they can identify opportunities to collect and share helpful information, which saves time and drives better informed decisions.
Poor Morale and Product Team Churn
All of the struggles above paint a picture of a role and organization that is hard to work in.
Imagine facing pushback on the concept of your role in the organization in nearly every interaction. Such an environment can exist, and it drives low morale on the product team and eventually product team churn.
There is nothing that slows us down as much as product team churn. I have long thought that it takes 12mos before a new product manager is at their best: when they know the people, product, and processes at the company and can make good judgements quickly. When we lose a product manager, we have to start again building that amazingly efficient and effective capability, and in the interim everything is slower and less optimal.
The cost of product team churn is probably the most under-appreciated cost on a product team’s speed and effectiveness. Every decision takes longer, every decision is less optimal, and the result is worse product slower - not what anyone wants.
tl;dr: Save your product team!
Scaling Worsens The Problem
All of the struggles above will be on display as soon as our company has a single product person, and will grow exponentially as more product people are hired.
As more product people join, they will have different methods for prioritizing their time, and the org will start to have different expectations for product based on whom they’ve worked with.
As we introduce intermediate managers of product managers into the org, they may start to set different expectations for product managers on their teams. This leads to product fiefdoms - a product manager could mean different things based on who their manager is.
The Solution: Defining Product Expectations
The solution to these challenges is to intentionally define what product is at our company, align that definition at every level, provide clarity to our teams about it, and reinforce it as part of our daily activities.
An intentional definition can take many forms, my personal favorite is define a product team charter that spells out the team mission, core principles, and measures of success.
Intentionality
The first step is to be intentional about why the Product function exists at our company.
Making an explicit, thoughtful decision about the mission and writing it down. Writing down both the what and the why: what is the mission of product, and why is that their mission? What are the core principles of our product function, and why? What are our measures of success for the product function?
Some questions that can help spark these answers:
When the CEO hired the first product person at the company, why did they do that? What were they looking for? What are they looking for now?
You are the first Product person hired at a company, and charged with creating the product function. Your peers in other functional areas don’t know how you fit into their world, which never included product people before. How would you tell them what you are there to do? What would you tell them your Product core operating principles are?
Imagine it’s the end of the first year that the company has had a product function, and you are preparing a readout of how your team has performed for the year. What evidence would you share that signals the performance of your product department?
The first step is writing down what you think the mission, principles, and measures of our product team are. Imagine we are sharing this document with new hires and using it as a basis for improving our team.
Alignment
It doesn’t matter what our definition is unless it is something that is deeply understood and aligned with the leadership team.
It’s critical to be aligned with leadership so that friction gets eliminated for us and our team in how we prioritize our time. These functional leaders can then cascade expectations about our team to their teams with our help. As expectations get more aligned, it gets easier for us and our teams to do a great job.
A first step is to talk to the heads of customer success, sales, marketing, engineering, design, finance, and the CEO. Ask them what they need from product, what they see as the product mission. Listen, take notes, and share with them our intention to create a clear charter. Then we should come back and share our draft charter with them and gather feedback.
This can be a difficult process.
These leaders will almost certainly have a different definition than us, especially if we don’t have an existing charter. That’s great to find out as soon as possible so that we can work to refine our definition and adjust expectations as soon as possible. Once we are aligned with these leaders, there will be continuous benefits to us and our teams and this effort will be well worth it.
Clarity
Once we’ve reached alignment with leadership, it’s critical that we provide clarity to our team and the functional teams surrounding them by continuously communicating and reinforcing our product team charter
The goal is not a document.
The goal is alignment and a common understanding that is at the forefront of the minds of our team and those they work with. The document is just a tool that provides the shorthand for that deeper understanding.
It is a failure and an empty exercise if the only time that a product manager sees or hears about this charter and the defined mission, principles, and measures is when they start the job, or at the end of the year.
To reach true clarity, it needs to be built into the fabric of our operating structure. Build it into how we interview, how we assess our team, how our leadership assesses the product function, how our team grows and learns, and the questions we ask every day.
Our team doesn’t care what we write down in a document - they care about what they see us do every day. If our team doesn’t see, smell, and feel the presence of our mission and principles routinely, then the charter will just be yet another empty and forgettable document.
Getting Started
How would we possibly start? This doesn’t need to be daunting.
Write It Down
If we don’t have anything akin to a product charter written down, we should just write down our impression of what it is, and what we want it to be (they might not be the same thing).
Align It Locally
Talk to the product managers on the team, and refine what we wrote down as our first draft. Once we have a refined draft, we should review it again with our product team, and say this is our operating charter while we continue to refine it with the broader organization.
Don’t Worry about Measures (at First)
Until we feel good about mission and principles, it doesn’t make much sense to measure. That said, it’s critical to define measures, because whether we know it or not we are being measured by everyone already - just with measures we don’t know and aren’t written down.
Iterate
We check in on our charter on a weekly or bi-weekly basis, and see if it still makes sense. Does it represent what we and our team have done in the last week(s)? Refine it, align it with our team, and run with it again. Once we notice it is not changing, we can expand the group we are aligning with to leadership. Rinse and repeat.
We want to expand the alignment to leadership as quickly as possible, to ensure if there are big gaps in alignment that we find them as soon as possible.
Summary
Any lack of clarity on the expectations for the product function at our company will drive inefficiency and ineffectiveness in how we create product every day. Each of those micro-frictions will slow us down.
Giving our team clarity about their mission at the company, the core principles that we believe in, and how to measure them will help us create better products faster.
It might even help us explain our jobs to our moms.
