Defining Competency Expectations from Associate PM to Senior Product Manager
This skill teaches you how to build a calibrated competency matrix that specifies the expected proficiency level for every core PM competency at associate, mid-level, and senior product manager tiers, so promotions and hiring decisions become defensible and transparent.
Start by listing competencies across the four quadrants of strategic, tactical, internal, and external work. Then define three to five proficiency levels for each competency, anchored with observable behaviors. Map each PM level to expected proficiency targets per competency, ensuring that a senior product manager shows mastery in strategic and cross-functional areas while associate PMs focus on tactical execution.
Outcome: You produce a complete competency matrix that maps every core PM competency to a defined proficiency level for associate, mid-level, and senior product manager roles, with each cell anchored by observable behaviors rather than subjective judgments.
Prerequisites
- Familiarity with the four-quadrant competency model (strategic vs. tactical, internal vs. external)
- Access to existing PM job descriptions or role expectations at your organization
- Understanding of observable behavior-based rubrics vs. vague trait descriptions
- Completed mapping of PM competencies across the four quadrants (see mapping-competencies-across-strategic-tactical-axes)
Overview
Every product organization reaches a point where the question 'What does a senior product manager actually need to be better at than a mid-level PM?' gets asked, and nobody has a consistent answer. Promotion discussions become political. Hiring panels disagree on what 'ready for senior' means. Compensation decisions feel arbitrary. This skill solves that problem by giving you a repeatable process for defining exactly what proficiency looks like at each career level, for every competency in the Product Team Competencies Framework. The output is a competency matrix: a table where rows are competencies (grouped by quadrant), columns are career levels, and each cell contains a proficiency rating anchored by specific, observable behaviors.
The skill sits between two critical activities in the framework. Upstream, you need a completed competency map that identifies which competencies matter and where they sit on the strategic-tactical and internal-external axes (see mapping competencies across axes). Downstream, the matrix you produce feeds directly into career development plans, job descriptions, and interview rubrics. Without this calibration step, those downstream artifacts lack precision.
Success looks like this: when a PM manager and their skip-level leader independently rate whether a PM is ready for promotion, their assessments align within one proficiency level on every competency because the behavioral anchors are specific enough to constrain interpretation. The artifact you produce is a single spreadsheet or document containing 12-20 competencies, each with 3-5 proficiency levels, each level described in 2-3 sentences of concrete behaviors, and a mapping showing which proficiency level is the baseline expectation for associate PM, mid-level PM, and senior product manager roles.
This skill is especially valuable during three moments: building a new PM career ladder, onboarding a new PM manager who needs to calibrate quickly, and resolving disagreements during promotion or performance review cycles. Organizations that skip this calibration step typically discover the gap when their first controversial promotion decision sparks a debate that nobody can resolve with data.
How It Works
The mental model behind competency level calibration rests on three principles: observable behavior over inferred trait, progressive scope over added skills, and quadrant shift over uniform growth.
Observable behavior over inferred trait. Most failed competency frameworks define levels using adjectives like 'strong strategic thinker' or 'excellent communicator.' These are traits you infer from behavior, and two observers will infer differently from the same evidence. The fix is to describe the behavior itself. Instead of 'strong strategic thinker,' write 'Identifies market trends from customer data and competitive analysis, translates them into a 6-12 month product roadmap rationale, and presents trade-offs to leadership with quantified impact estimates.' Anyone watching the PM can verify whether that behavior occurred.
Progressive scope over added skills. The difference between an associate PM and a senior product manager is not that the senior PM has a longer list of skills. It is that the same skills operate at a wider scope. An associate PM runs discovery for a single feature. A mid-level PM runs discovery for a product area. A senior product manager runs discovery that spans multiple product areas or requires cross-team coordination. The proficiency scale captures this scope expansion. This is why a simple 1-5 numeric scale without behavioral anchors fails: it does not encode what 'more proficient' actually means in terms of scope, autonomy, and ambiguity tolerance.
Quadrant shift over uniform growth. The Product Team Competencies Framework maps competencies across strategic vs. tactical and internal vs. external axes. Career progression does not mean improving equally across all four quadrants. Associate PMs are expected to excel in the tactical quadrants (both internal and external). Mid-level PMs add proficiency in one strategic quadrant, typically the one closer to their specialization. A senior product manager is expected to operate at high proficiency across three or four quadrants. The matrix captures this shift explicitly by setting different proficiency targets per quadrant per level.
The structure works because it constrains subjective judgment. When a manager evaluates a PM against the matrix, they compare observed behaviors to written anchors rather than forming a gestalt impression. When two managers disagree, they can point to specific cells in the matrix and identify exactly where their observations diverge. This makes calibration conversations productive instead of circular.
One important assumption: the matrix assumes competencies are independent enough to rate separately. In practice, some competencies interact. A PM who is excellent at stakeholder management but weak at data analysis may appear strong in cross-functional collaboration simply because they are charming rather than persuasive with evidence. The matrix does not solve this automatically, but by rating competencies individually, it at least forces the rater to consider each dimension rather than letting a halo effect from one strong area mask weaknesses in others.
Step-by-Step
Step 1: Gather your competency list and quadrant assignments
Pull the completed competency map from your earlier work with the Product Team Competencies Framework. You need the full list of competencies (typically 12-20) and their quadrant assignments (strategic-external, strategic-internal, tactical-external, tactical-internal). If you have not completed this mapping, do it first using the mapping competencies across axes skill. Verify that every competency has a clear, one-sentence definition so that the people writing behavioral anchors share a common understanding of what each competency covers.
Remove any competencies that overlap significantly, because overlapping competencies create confusing double-counting during evaluation. The output of this step is a clean, deduplicated list of competencies organized by quadrant.
Tip: If your list exceeds 20 competencies, you are probably splitting too finely. Combine related items (e.g., 'user research' and 'customer interviewing' can be one competency called 'customer discovery'). A matrix with too many rows becomes unusable during real evaluations.
Step 2: Define your proficiency scale
Choose a proficiency scale that will apply uniformly across all competencies. A 4-level or 5-level scale works best. Common labels are Foundational, Developing, Proficient, Advanced, and Expert, but you can use any labels that resonate with your organization. The critical requirement is that each level must be defined by scope and autonomy, not by vague quality descriptors.
Write a 2-3 sentence generic description for each level that applies across competencies. For example, Foundational might be 'Executes defined tasks in this competency with guidance. Follows established processes and asks for help when encountering ambiguity. ' Proficient might be 'Independently applies this competency across a product area.
Adapts approach based on context and makes judgment calls without escalation. ' These generic definitions become the template for writing competency-specific behavioral anchors in the next step.
Tip: Avoid using numbers alone (1-5) without labels and descriptions. Numbers without anchors invite the 'everyone is a 3' problem, where raters cluster around the middle because they have no objective basis for distinguishing levels.
Step 3: Write behavioral anchors for each competency at each proficiency level
This is the most time-intensive step. For each competency, write 2-3 sentences per proficiency level describing specific, observable behaviors that demonstrate that level of proficiency. Use action verbs ('identifies,' 'leads,' 'coaches,' 'designs') rather than quality adjectives ('strong,' 'excellent,' 'deep'). Each anchor should describe what the PM does, at what scope, and with what level of independence.
For the competency 'product strategy,' a Foundational anchor might read: 'Articulates how their feature contributes to the product's current strategy. Can explain the team's strategic priorities when asked. ' An Advanced anchor for the same competency might read: 'Develops multi-quarter product strategy for their area by synthesizing market trends, competitive dynamics, and internal capabilities. Presents strategic trade-offs to senior leadership with supporting data.
' Write these anchors in a group of 2-4 people who manage PMs, not alone, because individual managers have blind spots about what behaviors actually differentiate levels.
Tip: Test each anchor with the 'photograph test': could a neutral observer, watching the PM work for a sprint, determine whether this behavior happened? If the anchor is too abstract to observe, rewrite it. 'Thinks strategically' fails the test. 'Presents a written strategy document with market analysis and trade-off rationale to leadership quarterly' passes.
Step 4: Map career levels to expected proficiency targets per quadrant
Create a matrix where rows are competencies grouped by quadrant and columns are career levels (associate PM, mid-level PM, senior product manager). In each cell, enter the proficiency level you expect as the baseline for that role. This is the minimum expectation, not a ceiling. The quadrant-shift principle guides your mapping: associate PMs should have their highest expected proficiency levels in tactical quadrant competencies (both internal and external).
Mid-level PMs should match associates in tactical areas and add higher expectations in one strategic quadrant. A senior product manager should have high proficiency expectations across three or four quadrants. A concrete example: for 'stakeholder management' (strategic-internal), you might set the expectation at Foundational for associates, Proficient for mid-level PMs, and Advanced for senior product managers. For 'user story writing' (tactical-external), you might set Developing for associates, Proficient for mid-level, and Proficient for senior (because this competency does not need to keep growing at senior levels).
Tip: Not every competency needs to increase linearly with seniority. Some tactical competencies plateau at Proficient for senior roles because the senior PM delegates that work. Forcing every competency to increase at every level creates unrealistic expectations and signals that you have not thought carefully about where senior PMs actually spend their time.
Step 5: Validate the matrix against real PMs
Take 3-5 PMs at different levels in your organization and rate them against the draft matrix. Do not tell them which level you are calibrating for. Rate them competency by competency using the behavioral anchors. Then compare the matrix's output (what level the PM 'scores' at across competencies) to your existing understanding of their performance and role level.
If a PM you consider a strong mid-level performer rates as Advanced across the board, your anchors are set too low. If a PM you consider a solid senior product manager rates as Developing in multiple strategic competencies, either your anchors are too aggressive or your perception of that PM needs updating. Adjust the anchors and the expected proficiency targets based on what you learn. This step typically requires 2-3 iterations before the matrix produces results that align with informed judgment.
Tip: Include at least one PM who recently got promoted and one who was considered for promotion but not promoted. The matrix should clearly distinguish between these two cases. If it cannot, your behavioral anchors in the differentiating competencies are not specific enough.
Step 6: Identify the 'promotion gap' competencies for each level transition
Review the matrix and highlight the competencies where the expected proficiency level increases between adjacent career levels. These are the competencies where a PM must demonstrate growth to earn a promotion. For the transition from mid-level PM to senior product manager, you might find that the biggest jumps are in product strategy (Developing to Advanced), cross-functional leadership (Proficient to Advanced), and organizational influence (Developing to Proficient). Document these 'promotion gap' competencies explicitly.
They become the focus areas for development plans and the key evaluation criteria for promotion decisions. ' This summary is the artifact that PM managers will reference most frequently.
Tip: Limit the number of promotion-gap competencies to 3-5 per level transition. If every competency must grow for a promotion, the message is 'get better at everything,' which provides no focus. Identify the competencies that most differentiate the levels and make those the explicit promotion criteria.
Step 7: Document the matrix in a format that supports ongoing use
Transfer the validated matrix into a durable, accessible format. A spreadsheet works well for the primary artifact: rows are competencies (grouped by quadrant with visual separators), columns are proficiency levels, and each cell contains the behavioral anchor text. Add a separate tab or section that maps career levels to expected proficiency targets, using conditional formatting or color coding to make the pattern visible at a glance. Add a third tab or section with the promotion-gap summaries from Step 6.
Store this document where PM managers can access it during performance reviews, hiring discussions, and 1:1 career conversations. Include a version number and last-updated date, because the matrix will evolve as your organization's expectations change.
Tip: Do not lock the matrix in a PDF or a presentation deck. It needs to be a living document that managers can reference and annotate during real conversations. A shared spreadsheet with comment permissions strikes the right balance between structure and flexibility.
Examples
Example: Early-stage B2B SaaS company with 3 PMs
A Series A B2B SaaS company has three PMs: one associate, one mid-level, and one recently promoted to senior product manager. The VP of Product wants to formalize expectations because promotion criteria have been ad hoc. The team uses 14 competencies mapped across the four quadrants.
The VP and the senior PM spend a half-day workshop defining a 4-level proficiency scale (Foundational, Developing, Proficient, Advanced) and writing behavioral anchors for all 14 competencies. They focus on making the tactical competencies concrete since most of the team's work is execution-heavy at this stage. For the competency 'product discovery' (tactical-external), they write: Foundational: 'Conducts user interviews using a prepared script. Documents findings in a structured format.
' Advanced: 'Designs and runs multi-method discovery programs combining interviews, surveys, and data analysis. Identifies non-obvious patterns that challenge existing assumptions. ' They set the associate PM expectation at Developing, mid-level at Proficient, and senior product manager at Advanced. After testing the matrix against their three PMs, they discover that the associate PM actually meets the Proficient bar for product discovery but falls short in 'stakeholder management' (strategic-internal), which was set at Foundational for associates.
This prompts a useful conversation about whether the associate is ready for mid-level promotion in some areas but not others, and leads to a focused development plan.
Example: Growth-stage consumer app with 12 PMs across 4 squads
A consumer fintech app with 12 PMs, three PM managers, and a Director of Product needs to standardize expectations across squads because each manager has developed different informal standards. Promotion decisions have caused friction when PMs compare their progression to peers on other squads.
The Director runs a two-session workshop with all three PM managers. In session one, they align on 16 competencies and a 5-level scale (Foundational through Expert). In session two, they split the competencies among the three managers, with each manager writing behavioral anchors for 5-6 competencies. They reconvene to review, challenge, and revise each other's anchors.
The critical insight emerges during calibration: one manager had been setting the 'data analysis' bar much lower for mid-level PMs than the other two, explaining why that squad's PMs had been promoted faster. They standardize the anchor at Proficient for mid-level PMs: 'Independently defines and tracks product metrics. Builds dashboards to monitor feature performance. ' They then validate by rating 6 PMs (two per squad) and find strong alignment, with disagreements concentrated in the 'organizational influence' competency, which prompts a rewrite of those anchors.
The final matrix becomes the shared standard across squads, and the Director schedules quarterly cross-manager calibration sessions.
Example: Enterprise B2B company defining senior product manager expectations for a new level
A 200-person enterprise B2B company is introducing a 'Senior PM' level between their existing PM and Principal PM roles. They need to define what distinguishes senior product manager expectations from both adjacent levels. They have 18 competencies and 30 PMs across 8 teams.
The Head of Product assembles a working group of four experienced PM managers. They start by reviewing the existing PM-level and Principal PM-level expectations, which are documented but vaguely worded. The working group rewrites all behavioral anchors using the observable-behavior standard before adding the new senior product manager level. They focus the senior PM expectations on the quadrant-shift principle: a senior product manager should demonstrate Advanced proficiency in at least one strategic quadrant (either strategic-external like product vision and market positioning, or strategic-internal like organizational influence and cross-functional leadership) while maintaining Proficient in all tactical competencies.
They identify 4 promotion-gap competencies for the PM-to-senior transition: product strategy, cross-functional leadership, stakeholder management, and market analysis. The working group validates against 8 PMs who are candidates for the new level, finding that 3 clearly meet the new bar, 2 are close with specific gaps, and 3 need significant development. This validates that the bar is set correctly. They document the results and use them to have transparent conversations with each PM about their readiness and development priorities.
Example: Fully remote startup building a competency matrix from scratch
A 15-person fully remote startup with 2 PMs (both mid-level) is about to hire their first senior product manager and their first associate PM. The CEO and current PMs need to define what they expect at each level to write job descriptions and set up onboarding.
With only 2 PMs and no PM manager, they take a lighter approach. They select 12 core competencies from the Product Team Competencies Framework and use a 4-level scale. Instead of a full workshop, they work asynchronously in a shared document over one week: each PM drafts behavioral anchors for 6 competencies, then they review each other's work via comments. They focus their senior product manager expectations on the strategic competencies that the startup most needs: product vision, go-to-market strategy, and cross-functional leadership.
For the associate PM role, they set Foundational expectations for strategic competencies and Developing for tactical ones, with the explicit note that the associate will be mentored by the incoming senior PM. ' Both PMs rate themselves, finding they are at Proficient in tactical areas and Developing in most strategic competencies, which confirms that the senior hire needs to bring Advanced strategic proficiency. The matrix directly feeds into the job descriptions for both open roles.
Best Practices
Write behavioral anchors as a small group (2-4 PM managers), not solo. Individual managers anchor to their own team's behaviors and miss patterns from other teams. A group surfaces disagreements about what 'Proficient' means for a given competency, and resolving those disagreements produces sharper anchors. If you write alone, you will discover the ambiguity only when someone else interprets your anchors differently during an evaluation.
Keep behavioral anchors to 2-3 sentences per cell. Longer descriptions get skimmed during evaluations, which defeats the purpose of precise calibration. If you need more than 3 sentences, you are probably combining two distinct behaviors. Split them into separate competencies or choose the single most diagnostic behavior for that level.
Differentiate scope and autonomy at each level, not just quality. The difference between Developing and Proficient should not be 'does it better.' It should be 'does it independently across a broader scope.' This principle prevents the common failure mode where every level sounds like the previous one with more adjectives. Scope is the variable that changes most visibly as PMs grow toward senior product manager roles.
Review and update the matrix annually. Role expectations shift as your product matures, your team grows, and your market changes. A competency matrix written for a 5-person PM team at a startup will not fit a 30-person PM organization at a growth-stage company. Schedule an annual review with the PM leadership team to adjust behavioral anchors, add or retire competencies, and recalibrate expected proficiency targets.
Separate the matrix from the performance review process initially. Introduce the matrix as a development and career conversation tool before using it for formal evaluations. If PMs first encounter the matrix during a performance review, they will associate it with judgment rather than growth, and you will get pushback on the anchors. Let teams use it informally for 1-2 cycles before incorporating it into any formal review process.
Set different proficiency ceilings for different competencies by seniority. A senior product manager does not need Expert-level proficiency in every tactical competency. Some competencies plateau because the senior PM delegates that work. Failing to set ceilings creates the impression that senior PMs must be world-class at everything, which is unrealistic and discouraging.
Use the matrix to calibrate across managers, not just within teams. Schedule a quarterly calibration session where PM managers compare how they are applying the behavioral anchors. Two managers rating the same behavior at different proficiency levels indicates an anchor clarity problem that needs fixing. Without cross-manager calibration, the matrix provides false precision.
Common Mistakes
Using vague trait descriptors instead of observable behaviors
Correction
This is the most common failure mode. It looks like writing 'strong strategic thinker' or 'excellent communicator' as a proficiency anchor. It happens because writing observable behaviors is harder and slower than writing adjectives. You can catch it by applying the photograph test: could a neutral observer watching the PM for a week determine whether this anchor is met?
If the answer is no, rewrite the anchor to describe a specific action at a specific scope.
Making every competency increase linearly from associate to senior product manager
Correction
This looks like a matrix where every single competency is set to a higher level at each career stage. It happens because the matrix builder assumes seniority means universal improvement. The signal is that your senior PM expectations look superhuman, requiring Expert-level proficiency in 15+ competencies simultaneously. Fix it by identifying which tactical competencies plateau at Proficient for senior roles.
A senior product manager should be delegating detailed user story writing and bug triage, not becoming the best on the team at those tasks. Reserve Advanced and Expert expectations for the strategic competencies that define the senior role.
Building the matrix in isolation without validating against real PMs
Correction
This manifests as a matrix that looks logical on paper but produces absurd results when applied to actual people. A common symptom is that your best-performing mid-level PM scores as Advanced across the board (anchors too easy) or your proven senior product manager scores as Developing in strategic areas (anchors too hard). It happens because the builder theorizes about what each level should look like without testing. Fix it by running the validation step (Step 5) with at least 3-5 real PMs before finalizing.
Expect 2-3 revision cycles before the matrix produces calibrated results.
Creating a single proficiency scale without quadrant-specific expectations
Correction
, 'all associate PMs should be at Developing for everything'). The result is that the matrix fails to capture the quadrant-shift pattern that actually distinguishes career levels. Associate PMs should have higher expectations in tactical competencies than strategic ones. A senior product manager should have the opposite pattern.
If your matrix shows uniform expectations across quadrants for any career level, revisit the mapping step and encode the quadrant-shift principle explicitly.
Treating the matrix as a checklist for promotion rather than a development guide
Correction
This happens when managers tell PMs 'you need to hit Advanced in all five promotion-gap competencies to get promoted,' turning the matrix into a gate rather than a compass. The symptom is PMs gaming specific behaviors to check boxes rather than genuinely growing. The matrix should inform promotion decisions, but the conversation should be about patterns of demonstrated growth over time, not about checking every box in a single review cycle. Frame the promotion-gap competencies as 'areas where we need to see consistent evidence of growth,' not 'a scorecard you must max out.'
Conflating competency expectations with job description requirements
Correction
This looks like copying behavioral anchors directly into job postings, producing job descriptions that read like evaluation rubrics. Job descriptions need to attract candidates and describe the role's scope. Competency expectations need to evaluate and develop people already in the role. They serve different audiences and different purposes.
Use the matrix to inform your job descriptions (see writing competency-based PM job descriptions), but translate the behavioral anchors into role descriptions and responsibility statements rather than pasting them verbatim.
Other Skills in This Method
Showcasing PM Competencies in Portfolios and Resumes
How to use the competency framework to structure a product manager resume or portfolio that clearly demonstrates breadth and depth across strategic, tactical, internal, and external skills.
Assessing Product Team Strengths and Identifying Skill Gaps
How to use the competency framework to evaluate individual and team-level proficiency, surface blind spots, and prioritize areas for development.
Building Personalized PM Career Development Plans Using Competency Data
How to translate competency assessment results into actionable growth plans that guide product managers on how to advance their careers.
Differentiating PM Role Types Using the Competency Framework
How to use the quadrant model to distinguish technical product managers, growth PMs, and platform PMs from generalist roles based on their competency emphasis.
Mapping PM Competencies Across Strategic vs. Tactical and Internal vs. External Axes
How to plot core product management skills onto the 2D competency grid to visualize where each capability falls along the strategic-tactical and internal-external dimensions.
Writing Competency-Based Product Manager Job Descriptions
How to translate framework quadrants into clear, measurable job descriptions and hiring criteria that attract the right candidates for specific PM roles.
Designing PM Interview Rubrics Aligned to Competency Quadrants
How to structure product manager interview questions and scoring rubrics that evaluate candidates across all four quadrants of the competency framework.
Frequently Asked Questions
How many proficiency levels should I use in the competency matrix?
Use 4 or 5 levels. Fewer than 4 does not provide enough granularity to distinguish adjacent career levels. More than 5 creates false precision that makes rating harder without improving calibration. A 4-level scale (Foundational, Developing, Proficient, Advanced) works well for organizations with 3 career levels. A 5-level scale adds Expert for organizations that include a Principal or Staff PM tier.
How long should it take to build the full competency matrix?
Plan for 3-5 hours of focused work for the initial draft if you already have your competencies mapped. Writing behavioral anchors is the bottleneck. Add another 2-3 hours for validation against real PMs and revision. Total calendar time is typically 2-3 weeks when done in sessions rather than a single marathon. Smaller teams (under 5 PMs) can move faster because there are fewer perspectives to reconcile.
Should I define competency expectations before or after assessing my current team's strengths?
Define expectations first, then assess. If you assess first, your expectations will unconsciously anchor to your current team's strengths and weaknesses rather than reflecting what the roles genuinely require. The matrix should represent what the organization needs from each role, independent of who currently fills those roles. After defining expectations, use the [team assessment skill](/skills/assessing-pm-team-strengths-and-gaps) to identify gaps.
How do I handle competencies where the senior product manager level does not need to be higher than mid-level?
Set the same proficiency target for both levels and document why. Some tactical competencies (e.g., detailed user story writing, QA coordination) legitimately plateau at Proficient because senior PMs delegate that work. Explicitly noting the plateau prevents the impression that the matrix is incomplete and signals to PMs that not every competency needs to grow for promotion.
What if my PM managers disagree on what 'Advanced' looks like for a specific competency?
This is a feature, not a bug. Disagreement surfaces calibration gaps that would otherwise show up as inconsistent promotion decisions. Resolve it by having each manager write their version of the anchor independently, then comparing them side by side. Usually the disagreement is about scope (how broad a context counts as Advanced) rather than quality. Pick the version that is most observable and testable, and document the reasoning.
Can I use the same competency matrix for both individual contributor and people manager PM tracks?
Use the same competencies and proficiency scale, but create a separate set of proficiency targets for the management track. A PM manager at the senior level needs Advanced proficiency in 'people development' and 'team leadership' competencies that an IC senior product manager might only need at Developing. The underlying competency list stays the same. The expected proficiency targets diverge where the roles diverge.
Why does my competency matrix result keep drifting over time?
Drift happens for two reasons: the organization's expectations genuinely change (your product matured, your team grew, your market shifted), or managers gradually reinterpret behavioral anchors without realizing it. The first kind of drift is healthy and should be captured in annual matrix reviews. The second kind is calibration decay, and the fix is quarterly cross-manager calibration sessions where managers rate the same PM and compare results. If ratings diverge by more than one level on any competency, the anchor needs rewriting.