You’ve almost certainly heard of the book, the 5 Dysfunctions of a Team by Patrick Lencioni. It’s a fairly popular book in technology organizations and provides some great advice in identifying and addressing key issues found in ANY team.

The 5 dysfunctions that Lencioni cites are:

1: Absence of Trust

2: Fear of Conflict

3: Lack of Commitment

4: Avoidance of Accountability

5: Inattention to Results

These 5 dysfunctions, as Lencioni states in the video, are broadly applicable to ALL teams:

“whether you’re in a church or a school or a corporation or a department within that corporation; any kind of setting where you’re working as a team.”

i.e. the dysfunctions are horizontal, applicable regardless of the type of team, industry, size etc.

Product Management Teams

In my work with Product Management teams, I’ve seen elements of all of Lencioni’s dysfunctions. i.e. Product teams are not immune to the above dysfunctions though Absence of Trust and Avoidance of Accountability seem to be most common in my experience.

But, I’ve also seen a number of common dysfunctions that are more specific to Product Management teams, and significantly hamper them in effectively executing work and making significant contributions to their companies.

These dysfunctions exist for a number of reasons, including lack of company/management understanding of Product Management and the evolution of the role in the company.

Without editorializing too much, a lot of the grief hurled towards Product Management by other teams and leaders in companies can be traced to the impacts of these dysfunctions.

Let me say that these aren’t the only dysfunctions I’ve seen, but these are the major ones, and the ones that would have the highest positive impact for the company, if addressed.

The 5 Product Management Team Dysfunctions are:

1. Poor Job Definitions

2. Under-skilled Product Managers

3. Poor Processes

4. Unclear Objectives

5. Weak Product Leadership

From my experience, these 5 dysfunctions are VERY common with some amount of ALL of them in most Product Management organizations.

Given how widespread these dysfunctions are, think about the level of underperformance of Product Management teams, or more positively, the ENORMOUS potential for improvement, better outcomes and real impact that would be possible if these can be addressed!

The biggest issue is that most product management organizations aren’t explicitly aware of these problems, let alone focussing on them and addressing them.

And yet, you would almost never see the same extent of issues in a Sales, Marketing or Engineering teams, for example. Job definitions, skills, processes etc. are much more well-defined in those functions, and lack of them is not tolerated (for long).

So why are they so widespread in Product Management teams?

There are many reasons and I will get into them in this post, so let’s dig into each dysfunction.

1. Poor Job Definitions

First, notice I said job *definitions*, and not job descriptions. I’ll get into job descriptions in a bit. A job definition is exactly what it sounds like; a definition of the duties, deliverables, goals and expectations for a job. It’s what you expect a Product Manager to do and is the basis of how you measure and evaluate them.

Job definitions are very clear in Sales, Finance, Engineering, even Marketing and Support/Success. Is there any question about what a Salesrep’s duties are, or how they are measured? The same hold true for an Accountant in Finance and a Growth Marketer in Marketing. But when it comes to Product Management, clear defintions seem almost non-existent.

i.e. people can *describe* what they expect of Product Managers, but it usually comes with a lot of blurry edges and an almost complete lack of meaningful measurability.

The worst situations are when Product Managers are viewed as glue or gap filler, helping out wherever needed — product testing, demos, internal product training etc. This is, of course, on top of their “regular” job which is often focussed on feeding the Engineering machine with “prioritized requirements” in some form or another.

I’ve seen this first hand in several companies. The lack of clear job definition means Product Managers are pulled in different directions by the organization, focusing primarily on tactical work, fulfilling urgent requests (firefighting) with a bias on “delivery” and “assisting” other organizations. This is NOT the sign of a well defined role.

And when it comes to job descriptions, many companies crib them from some other Product Manager job descriptions they’ve found on Internet Job Boards, or simply copy/paste and slightly update old ones they’ve used. The job description often looks for a unicorn candidate who is technical but business savvy, strategically minded but can execute like a pro, etc. etc. etc.

Now think about this situation. What does it tell you about a company that hires and staffs a Product Management organization, but doesn’t have the understanding to properly define the job or create a job description that truly describes what the person will do and how their contribution will be measured?

It means those Product Managers will be far less focused and far less effective than they could be. It also means lost opportunity and delays in driving product success. If the company can’t define the job well, how can the employee do it well?

2. Under-skilled Product Managers

This dysfunction is far too common in companies. From one perspective, it is understandable given the very loose definition of the role in many companies, but the fact that it is very common to this day and companies don’t actively and systematically work to address it is a problem.

Now, we all know that unlike, say Engineering or Marketing, there are VERY few formal education programs to develop the skills and knowledge to be a product manager.

e.g. There are some emerging programs at Carnegie Mellon, Cornell, Northwestern University, UC Berkeley, University of Washington, as well as a handful of programs in Europe.

But, these are tiny numbers when compared to programs in software development or marketing which are offered by virtually every university and college.

There are, of course, a growing number of private programs that offer training in product management. These are usually very short in duration — from a few of days to a few weeks maximum — and often are very generic or simply touch the surface of what is a complex, multi-disciplinary role.

But the reality is that most product managers don’t have ANY formal or even semi-formal training in product management, and they must learn it on the job.

For example, tasks such as qualitative and quantitative research, product strategy, roadmapping, negotiation, prioritization, business planning, pricing, packaging and licensing models etc. are learned informally on the job, often in the context of a hectic, fast moving startup. There is little time for formalism and understanding the underlying principles and repeatable models.

On top of this, add the lack of structured education programs WITHIN companies to teach these underskilled product managers how to do the job well.

Many companies do provide funding for training, workshops, conferences etc. And that is of course, a good thing. But those budgets are often spent in an adhoc manner, tied to very tactical or subjective needs, as opposed to a more formal, longer term view of employee development.

Another challenge is that the skills needed to be an effective product manager are just about as diverse as the job is. Many people have created frameworks to try to document this diversity of skills.

• Product Manager Skills by Seniority Level — A Deep Breakdown
• What’s Your Shape? A Product manager’s Guide to Growing Yourself and Your Team
• How to Assess Product Management Skills and Competencies

Here’s the one I use.

There are 5 main categories:

• Business & Strategy
• Domain Knowledge
• Technology & Design
• Leadership & Communication
• Other Skills/Abilities

These cover a broad swath of skills and knowledge that Product Managers need. I’ve listed a number of those skills/abilities in each category, but in no way is this meant to be completely comprehensive.

Think of the lists as representative of what each category covers. Not every product manager needs to have all of these, but most PMs should have strengths in several of the categories if they want to be successful.

It’s clear that most people will NOT have depth in a large number of the skills and knowledge listed above. Some of it, such as the various aspects of Domain Knowledge can be and should be learned on the job. Skills such as leadership can be taught and learned over time.

NOTE: I use this framework and some associated exercises with my clients to help them define Product roles, create candidate interview and assessment guides and perform skills assessments and improvement plans with Product Managers.

The net result of this dysfunction is that individual contributor Product Managers struggle to perform their jobs well, treading water, moving from one task to the next, and learning in an adhoc manner as they go.

Combine this with poor job definitions and it’s clear why so many teams that work with Product Management have negative views of Product Managers and their contributions.

3. Poor Processes

Oh no, not the dreaded P-word. People seem to have a strong reaction to the word “Process”, to the point of actively pushing back when the concept is discussed or plans are made to create processes to use.

But it’s understandable given how most people’s experience with “process” is often terrible, with cumbersome processes imposed from above that hinder more than they help.

And yet, if nothing else, Product Management is a profession that needs process.

There is regular business planning, strategy, customer and market discovery, roadmapping, product planning, prioritization, launch, operations, product/feature retirement etc.

In all of the aforementioned processes, the goal should be repeatability and confidence in achieving the desired results. Two quotes from Deming come to mind in this context:

“If you can’t describe what you’re doing as a process, you don’t know what you’re doing.”

And

“A bad system will beat a good person every time.”

The first quote, while blunt, states the obvious, and is a common symptom in many product management organizations. If you ask them to describe their discovery process, or their roadmapping process etc. it’s often a vague, somewhat hand-wavy exercise that varies from person to person.

The second quote contains a good insight and alludes to the problems just stated. i.e a process (system) must be there to support the people using it. The existence of a process (system) is necessary, but not sufficient.

i.e. a bad process is a barrier to success.

And unfortunately, many processes created and implemented (or imposed) in companies are bad. They’re often designed to serve management (oversight, accountability, governance etc.) as opposed to those who are part of the process and doing the work.

The dictionary defines “process” as follows:

Process: n, a series of actions or steps taken in order to achieve a particular end

It’s that “particular end” (or outcome) that is the focus for a lot of people. Outcomes over outputs as the mantra now goes. But outcomes don’t just happen. Consistently achieving positive outcomes, whether in sports, school, business or elsewhere, comes through practice and understanding. And that’s where processes come in.

Another great quote to consider is this one by Seth Godin.

Focus on process, not solely on outcomes. If the process is right, the outcome will inevitably follow

And so, in regards to Product Management, here are some questions to ask yourself.

• What roadmapping process does your Product Management organization use?
• How does the org create and implement product strategy?
• How is discovery performed and how are insights identified, shared and utilized?
• How well structured are each of these processes (roadmapping, prioritization, strategy, discovery etc.)?
• Are they documented somewhere, even at a high-level, describing the major steps in the process, useful techniques, key outputs etc.?
• Can the processes be performed in a consistent and repeatable way by different Product Managers in your organization and deliver positive outcomes?
• If someone new comes on board, can they learn these processes and perform them as well as the rest of the team?

The goal here is to ensure that the Product Management organization can work both consistently in a coordinated manner, minimizing waste and driving the business forward; not simply driving delivery of features or putting out fires.

4. Unclear Objectives

Here’s a little exercise. Ask yourself the following questions.

1. What is the objective of Sales?
2. What is the objective of Marketing?
3. What is the objective of Engineering?
4. What is the objective of Product Management?

Was one of them much harder than the others? Which one? ????

Most Product Managers do not have clear objectives for their roles. Similar to Job Definitions, people can roughly describe what they expect Product Managers to do, but when it comes to clear, measurable and consistent objectives, the answers don’t come easily.

On one hand, it is understandable why. Product Management is not about delivering immediate results. As someone once said:

“Sales is responsible for this year’s revenue; Product Management is responsible for next year’s revenue.” (source unknown)

While Sales (and Marketing) are driving results in the now (“this year”), Product Management must focus on what will help the company succeed in the future (“next year”). Now this is not to say that Product Management doesn’t spend some of their time focusing on the present (i.e. working cross-functionality etc.), but the real value of Product Management lies in that forward looking work and impact.

And so, we get back to the question about objectives, but articulated slightly differently:

How do you measure the contribution and success of Product Managers?

What are the business goals that Product Management can be measured against?

In my previous life as a Product Manager, I was often given revenue targets for my products (for the current year) that my work was measured against. Revenue is an easy business goal to measure against, but it is also challenging for Product Managers.

Obviously I wasn’t working directly on revenue — Sales and Marketing were — but there was a clear implication that I was expected to make a significant contribution to help Sales/Marketing and other teams in achieving that number, WHILE still doing the other parts of my job that focused on the future.

To a certain extent, it was also a recognition that the work I did in the past needed to bear fruit in the present. i.e. I couldn’t just move on and continue focusing on the future.

Having said that, it was an imperfect measure IMHO, and maintaining future focus while helping in the now became especially difficult when product sales were lagging or the economy hit a bump, or a major market shift happened or …

But, it was a clear business measure, it was unambiguous, and my actions (past and present) could be tied to it. So while imperfect, it was not terrible.

When business goals are missing

But MANY product managers don’t have a revenue objectives, or growth objectives, or customer acquisition objectives or retention objectives etc. that they are measured against. They are given delivery targets (deliver the plan or deliver the roadmap etc).

And so, on what do they align their focus? A delivery target is NOT a strong business objective for a product company. What part of the product is the product manager actually managing? Perhaps they should be called delivery managers instead?

Objectives — good, clear, well defined business objectives — align people, organizations and companies towards common goals. Product Managers are cross-functional leaders. At least that’s what they should be. And if they have unclear or weak objectives, the needed alignment will not occur and the true benefit of Product Management’s work will not be had.

5. Weak Product Leadership

This 5th dysfunction is probably the one that impacts Product Management teams the most.

Here is something to ponder:

Have you ever known of a VP of Sales that has never been a Salesperson before; or a VP of Engineering who wasn’t formerly a software developer or engineer; or a VP of Marketing who had no background in Marketing?

The answer is almost certainly no to all of those questions. And if you did answer yes, it was likely a rare occurrence. For me the answers were No, No, and Yes.

i.e. I knew of a VP of Marketing that had no background in Marketing. He was a friend of the CEO. He lasted about a year, and it didn’t end well.

Now answer this question:

Have you ever known of a VP of Product Management (or VP Product/CPO etc.) who has never been a Product Manager?

The answer is almost certainly yes. It’s quite common to see a Head of Product, VP Product or Chief Product Officer who was never an individual contributor Product Manager or even led product teams in their career.

Why is that?

It’s not that having been an individual contributor Product Manager is an absolute necessity to being a successful Product Leader, but it certainly does help.

Every function, Sales, Engineering, Finance, Marketing, Product etc. is complex. There are skills, knowledge, patterns, situations and insights gained through “doing the work” as an individual that leaders can leverage when they lead those teams.

• How can a VP Product help their Product Managers excel at discovery, planning, roadmapping, strategy, prioritization etc. etc. if they’ve never done ANY of it themselves.
• How can they help bridge gaps with Engineering if they’ve not thought about it and done it in previous roles?
• How can they define REAL product strategy — not the weak attempts that often masquerade at it — if they’ve never attempted it before?
• How can they define proper Product Management jobs, assess skills, implement proper processes and define clear objectives if they’ve never been in that role?

It’s not that all of these people will be as horrible in their roles as that VP Marketing I mentioned earlier. But, their lack of “on the ground” experience will create friction and slow down the team’s progress.

I’ve seen it first-hand in companies I’ve worked in and worked with. And not only does this lack of product leadership experience impact the team, it impacts the company as a whole. How can the company move fast and address market needs if the Product organization itself doesn’t have the leadership to make that happen?

In Summary

These 5 dysfunctions are both common and highly detrimental to the performance of Product Management teams. Addressing them and creating environments where Product Managers have:

• clearly defined roles and responsibilities,
• receive focused training and skills improvement
• have well defined processes and objectives
• and are led by experienced Product leaders

will deliver significant benefits to not only the Product organization, but to Product outcomes and company objectives as a whole.

In upcoming posts, I’ll dig deeper into some of these dysfunctions and discuss ways to address them. Feel free to share your thoughts and let me know which ones are most common or are impacting you or your Product Management team.