A Step-by-Step Guide to Building a Product Management Competency Framework in Your Organization
A recent survey conducted by Product Management Festival found that the number one reason why PMs leave their roles is because of a lack of opportunities to grow. Worse only 15.5% of respondents stated that developing people and capabilities was a top focus of their organization.
Couple this with 35% of Product Managers stating that a ‘lack of role clarity’ was one of their top 3 challenges it would suggest that one of the most impactful things you can do as a Product Leader for your team and organization is to provide clarity around roles and career progression.
One of the best tools in my experience for this is having a solid competency framework.
I’ve worked with half a dozen Product Leaders to help implement competency frameworks in their organization.
There is always a temptation to take some of the good public examples (like this one and that one) and not “reinvent the wheel”. However, Product Management in my experience is very contextual and therefore, what it means to be a PM in your organization is likely a bit different from another.
Therefore in my experience the best competency frameworks are the ones that you have created for your context.
As a Product Coach, I won’t and never will pull out a generic competency framework and sell it to you — rather what I will do (and have done) is help facilitate the process for you to create one of your own.
Here’s a walk through of the typical process that I take clients through if you’re interested in trying to create one of your own.
Note: I have deliberately put ‘Product Manager’ in brackets in the title. This is because this process can be followed for building out a competency framework for any role, I am just speaking from my experience in Product Management.
Step 1: Define the career ladder for a PM in your org
Don’t worry too much about whether they are the right roles or not, that can come later — just map what you have today.
Once you’ve got those now begin to consider what you are missing or would like to remove or need — how might the ideal structure of Product Management roles look like in your company?
This is an ideal time to start to look forwards a little too.
If you are a startup or a company that is scaling fast it's best to plan with the future in mind here — do you think you’ll add an APM program sometimes soon? How might you support scale? Will do you need to introduce Group Product Managers or Principle Product Managers? What about specialist PM roles, Platform Management, etc?
You might end up with something that looks similar to the following:
Note: That there is a split between what I’ve called ‘Team Contributor’ (thanks John Cutler for that naming) often referred to as an ‘Individual Contributor’ and people-management.
This is because of the ‘Peter Principle’ and the fact that people management is a different skill altogether, one which not everyone wants or is suited for.
The idea behind splitting the two tracks is to allow people to remain as a ‘Team Contributor’ (aka doing what they’re good at) and still have a career path as opposed to hitting a glass ceiling because they don’t want to become a people manager…or worse taking the promotion to get a pay rise when really the best place for their skills was to remain a Team Contributor.
Step 2: Brainstorm competency themes/areas
Once you have the roles sorted out, the next step is to begin brainstorming the competency areas you want your framework to have.
You can do this in any way you wish. But as an example, I have done this previously by:
-
Getting all the PMs in the company to brainstorm the skills they think we Product Managers should have and then synthesizing them into themes.
-
Synthesize a number of existing frameworks out there into common themes and start with them.
-
Brainstorming skills with a small group (perhaps even just the VP of Product and myself) and then synthesize them into groups
This step in the process is the ideal opportunity to begin to involve your peers and if you’re a Product Leader to involve your team (if you haven’t included them at since the beginning).
You might end up with something that looks like this:
Pro tip: Including the wider team and other PMs earlier the better. By doing so you have the opporutnity to co-create the matrix with them and this helps create alignment and buyin to the new framework which will help later on with adoption when rolling the tool out.
Step 3: Decide on your competency areas and plot your matrix
The next step is to take that brainstorm and to distill it down into a concise set of competence areas that you wish to use in your competency framework.
If you’re doing this step as a group, a round or two of dot-voting can do the trick. However you may also just want to talk it out and mix and match them — i.e. ‘teamwork’ and ‘communication’ might make a logical pairing to you, or perhaps ‘leadership’ and ‘communication’ do. It’ll be depended on personal preferences and your context.
Once decided on the competence areas that you think you’re going to use it’s time to construct your matrix.
You might end up with something that looks similar to this:
Step 4: Fill out your matrix
We have a matrix! Hurrah!
This means breaking down each competency area into a subset of skills for each of the different Product Management levels in your company.
During this step you will no-doubt do some iterating.
You will mostly iterate on two things in my experience. The first being the competency areas you have down the y-axis. As you move into that next level of detail you will no doubt want to make tweaks to them — that’s ok.
The second will be on the role levels you have along the x-axis.
As you build the matrix out it’s worth considering if you want there to be a 1:1 mapping of roles to levels, or whether you want to have a one to many mapping.
There’s no right or wrong on this — I’ve done both — it will be more dependent on how nuanced you want/need the levels and skill break down to be. This is why there will be a level of iterating as you begin to break the skills down and map them against the levels you will again no doubt add or remove levels.
Again, if you haven’t involved a wider group until now, this is the time. By doing so you will help to generate buy-in to the framework but also allow for disagreements and discussion to happen. This will lead to further iterations and ultimately really strengthen your competency framework.
Pro tip: Don’t get caught up trying to make it perfect you will add, modify and remove things over time as you use it and your team grows.
I will also note that it is absolutely critical that you get buy-in and allow for the Product Managers in your company to have a say and input into what is expected of them at each level in each competency area of the matrix. The successful implementation and adoption of the framework hang on there being buy-in and mutual agreement on what is expected of them as Product Managers in the organization.
In the end, you’ll likely have something that looks similar to this:
Note: You’ll notice in the example above the VP of Product and I decided to not have a 1:1 mapping for all the roles:levels. Rather we had add two levels for both PM and Senior PM.
This was because the company had the most people in either a PM and Senior PM role and therefore having additional nuance between those who recently got promoted to Senior vs those who have been there for a while and those who are getting close to being promoted to PM vs more junior people was something we thought was necessary in their context.
As a comparison you can see for the ‘People leader’ track we had opted for a 1:1 mapping. This was because the company was still growing and there were actually only currently 3 Product Leaders in the org.
Although appropriate for now that doesn’t mean it wont change in the future. In fact, as part of thinking ahread we had added in the Director of PM level, something that doesn’t exist for them today althought they are growing rapidly and believe they’ll be needing that role soon.
Step 5: Formalise, communicate and begin using the matrix
And that’s it. The final step is to then take those messy post-it notes (or however you chose to construct it) and formalize it. For example you may want to package it up in a spreadsheet or formal document. However, you choose to package it be sure that it’s easy to read and access.
But the end product has always been worth it in my experience. The value it provides in terms of clarity on roles, expectations and facilitating career conversations cannot be overstated.
And with a lack of career clarity being the top reason why product managers leave their jobs, solving that alone is an easy return on investment as a product leaders (assuming you want to keep those people!)
Once you had it remember that the final yards communicating and using it.
There's no point in putting in all this effort if no one knows about it!
