Unpacking product team progression and performance

Unpacking Product Team Progression and Performance - including templates and guidelines

A framework to help your people grow and in turn grow your business (not the other way round).

A few years back, I was brought into 11:FS Foundry to help build a strong product practice under the Head of Product. A few months in, we were recruiting new product people, and it became clear to us that we needed product managers and designers who had specific skills we needed to accelerate our growth.

It strikes me that many organisations say they want to grow, accelerate and see leaders emerge, all the while refusing to prioritise the critical efforts needed to make this work, i.e. helping individuals in their teams grow.

One way this materialises is the lack of understanding in companies around the importance of training and coaching for employees. It is even more concerning when there are a number of studies which show that training improves employee performance and ROI.

In this article, I share practices I have seen work when setting up a progression framework for product people. These are complemented by thoughts by none other than Sebastien Levaillant's who has 25 years of experience in building and leading product teams.

Why do you need a progression framework at all?

The biggest challenge facing the European tech scene these past couple of years has been talent recruitment and retention.*
Every tech company is competing for the same talent pool with multiple job opportunities for a single worker. Even more so in product management.

For many of us who have been doing product for a while, a lot of the craft and human skills feel like muscle memory now. We often forget that product management as a structured field of work is relatively new. It isn't always obvious to managers or individual contributors which skills and competencies they should develop, at which stage in their careers, and with what to what extent.

A progression framework lays the foundation for your team members to:

  1. Understand what is expected of them at each level of competency required in the organisation and have clarity on which skills and competencies they need to develop in order to progress.
  2. Identify areas of development they need to address and potential solutions.
  3. Feel empowered and masters of their own destiny within their craft.
These are 3 pillars that help build employee fulfilment and retention for your organisation.
If you want to survive any scale-up hypergrowth, you need to avoid fooling yourself. The best way to do that is to rely upon a common agreement of what is expected from you as a PM.
Sebastien Levaillant - VP Product @ PayFit

You don't need to start from scratch

If you're willing to invest some time in building a progression framework for your team, you should bear in mind that this is going to be an ongoing process. You will make a lot of tweaks and updates to the document as you go along and learn from setting up the process in your organisation.

There are a number of examples of career paths and progression frameworks available out there. Just start from one which makes sense and simplify it as much as possible, so you can work with something.

Building blocks of a progression framework

Skills & competencies

Let's get the definitions out of the way. These 2 concepts differ:

A skill is a learned and applied abilities that use one’s knowledge effectively in execution or performance. Using the same example of making business decisions, in order to do so, you would have to maintain certain skills to perform well: budgeting, market research and competitive strategy.

A competency is a mix of knowledge, behaviours, attitudes and even skills that lead to the ability to do something successfully or efficiently. The ability to make business decisions would be a competency.

An efficient and actionable progression framework uses skills and competencies to represent key dimensions a company is looking for in their talent. These could be used for hiring as well as development.

Levels & progression

Having a progression framework for your product team is good, but it is not self-fulfilling.

Showing your product team what excellence looks like is good. Supporting them in getting there is better.

If you want your team to feel empowered and have clarity on where to invest their time, develop new skills, grow within their role and progress in their careers, then having clear progression increments is the bare minimum.

Transparently communicating your grid of skills and competencies along with a career path is the best way to set a clear contract with your product talents. They know what to expect from your company while clearly understanding what is expected from them.
Seb @ PayFit

Progression also come with feedback, self-reflection, clear success factors, acknowledgement and rewards.

For a progression framework to be robust and actually usable, you'll want to have clarity on these 2 elements:

  1. How do people move from one level to another.
    For instance, you might decide that team members do not necessarily have to have demonstrated all competencies or acquired all skills in a level to be eligible for moving to the next level.
    Regardless of your policy, you need to be extremely clear on how progression takes place. Clarity is key, even if you experiment over time.
  2. How do you document the decision and evidence to back a progression decision.
    Having a system of record to inform progression is not optional.
    You'll want to be able to show evidence that a fellow team member has met the requirements for progression e.g. coaching plan with objectives, deliverables, achieved product metrics, proven impact etc.
    A good practice is to ask peers (not the line manager) to evaluate whether a team member has demonstrated a competency or acquired a skill by looking at shared evidence. This creates alignment and provides objectivity.
Example of progression levels for problem-solving, a core skill for PMs.

4 steps to get to the v1 of your progression framework

While there's no need to re-invent the wheel, a progression framework should be contextual and built for the specificities of your business, the market you operate in and how you want your people to grow.

Creating a product team is not only about attracting the right talent. It is about growing them over time whatever the outcomes of their actions. That is the only way to give your talent and your company the levers to execute upon their ambitions.
Seb @ PayFit

#1 Identify what is urgent and important and start there

Start with an introspection. Ask your team what truly matters to them in their growth as product people. You might be positively surprised with what they have to say. Your entire product team will buy into a progression framework which has been informed by and resonates with them.

Your specific business context is also key here. If you're a FinTech who wants to build a payments business, and you believe domain knowledge is crucial for your venture, this means you've identified specific skills or knowledge your talent need to show in order to land a job at your company and/or grow within their role.

These 2 dimensions should give you a good base to move forward.

#2 Build for what behaviours you want to foster next

Say you were to implement a new progression framework in early January 2023, you would only start to see changes in your team after at least 2 quarters, and that's if everything goes according to plan. Implementing a progression framework takes time.

If you want to start seeing some competencies embodied by your team, you'll want to prioritise and build in the incremental steps accordingly.

As with everything else, you'll want to be careful not to instrumentalise the progression framework to reach business outcomes at all cost, e.g. by fostering behaviours detrimental to your people or company culture.

#3 Determine how you will measure progression

This is one of the areas where I've seen many companies fail.
If you want this to work, one practice I've seen work is to anchor progression decisions in evidence (this goes to point #2 in the Levels & Progressions section above).

For each skill or competency, you'll want to have clear evidence that the team member has demonstrated said skill or competency and document it properly.
You can also embed a sense of confidence to acquiring the skill or competency itself by leveraging peer reviews.

Here are two examples of how you can formalise skill/competency acquisition:

Skill: Understands how code is tested, deployed and version-controlled for backend microservices, native apps and web interfaces.

Recommendation: The acquisition of this skill is done through peer-review: typically, a tech lead/developer in test from adjacent teams will provide appreciation of this.
Skill: Can assimilate new information easily, and can synthesise qualitative and quantitative inputs to form reliable insights into user needs and behaviour.

Recommendation: The acquisition of this skill is based on evidence from work product e.g. product reviews, research presentations or other artefacts that synthesise insights for product decision-making. This skill must be demonstrated on 2 separate occasions within 1 progression cycle (1 calendar year) to be considered acquired. Evaluation is made by line manager.

πŸ‘† This level of clarity as to how a skill is evaluated and acquired is important, and it provided all the necessary context for fellow team members to succeed.

It is easy to attract and retain Product Managers. However it is way more difficult to attract and retain the most talented ones. Giving them the ability to grow as fantastic individual contributors is key for the success of your company.
Seb @ PayFit

#4 Stress test your framework before indexing compensation thereon

You might be tempted to say "If we want this to work, we need to tie this to something as real as their salary!"... Hold your horses!
First, you need to understand that it won't be as easy to do this because indexing your rewards strategy on the progression framework has a lot of financial, legal, HR and other implications. I would definitely not recommend going down this path at the outset.

Indexing rewards on the progression framework (e.g. base salary and/or bonuses) is an effective way to show your team members that their work is valued.
The reality is that it will take at least a whole year to experiment with your framework and the longer it isn't tied to remuneration, the longer you can continue iterating more freely with it. It's a balancing act.

My advice is always be upfront about it. Explain you want to create a framework that is in the interest of people's growth within the company, and that this takes time and iterations. Transparency is a very powerful ally here.

Avoid this common mistake

⚠️ Don't wait too long to get HR involved.
You can say everything you want about your HR/People team (e.g. that they don't get product) but the truth is, 9 times out of 10, they're really here to help.

I find that bringing them early on means increasing chances of adoption of a progression framework that works in context of HR considerations.

Next up: building a Product Career Path

If you're looking to understand how to build a product career path that

  1. articulates competencies with progression levels
  2. engages your product team in productive conversations about their growth and development perspectives
  3. provides perspective to team members while promoting talent retention

Subscribe to receive updates by using the link below.

Every PM must understand that you can grow as an individual contributor. You dont' have to become a manager to climb up the corporate ladder.
Seb @ PayFit
Example Product Career Path for Product Managers


Subscribe to Panash

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.