Product Team Competencies Framework for Every Product Manager
The Product Team Competencies Framework, created by Neal Cabage, organizes core product manager skills along two axes: strategic versus tactical and internal versus external. By plotting competencies on this 2D grid, teams can objectively assess individual strengths, identify collective gaps, calibrate role expectations from associate to senior PM, and build targeted development plans that connect daily work to career growth.
Overview
Most organizations know they need strong product managers but struggle to define what "strong" actually means. Job descriptions recycle the same vague bullets. Performance reviews devolve into gut feel. Promotion criteria differ between managers on the same team. The Product Team Competencies Framework, introduced by Neal Cabage, attacks this ambiguity head-on by giving teams a shared, structured vocabulary for what product management skill looks like at every level.
The framework plots competencies on two intersecting axes. The vertical axis runs from strategic (vision, market positioning, business modeling) to tactical (execution, delivery, process optimization). The horizontal axis runs from external (customer research, competitive analysis, go-to-market) to internal (cross-functional collaboration, stakeholder management, team development). These two axes create four quadrants, and every meaningful PM skill lands somewhere on the resulting grid. A PM who excels at competitive intelligence but struggles with sprint-level execution lives in the strategic-external quadrant. One who is brilliant at unblocking engineers but rarely talks to customers clusters in the tactical-internal zone. Neither profile is wrong, but both are incomplete, and the framework makes that incompleteness visible without making it personal.
Cabage developed the model while observing a persistent pattern across product organizations: teams hired for one archetype of PM (often the "mini-CEO" generalist) and then wondered why gaps kept appearing. The root cause was not bad hiring. It was the absence of a map. Without a map, you cannot tell whether you are missing a competency because nobody on the team has it, or because the team has it but it lives in the wrong role. The framework provides that map. It does not prescribe a single ideal profile. Instead, it argues that a healthy product team covers the full grid collectively, even if no individual PM does.
What distinguishes this model from generic skills matrices or leveling rubrics is its two-dimensional structure. Many competency lists treat skills as a flat checklist: "strategy, communication, analytics, execution." That format obscures the tension between skills. Strategy and execution are not independent line items. They trade off against each other in any given sprint. By placing them on opposing ends of an axis, Cabage's framework forces teams to confront the tradeoff honestly. A PM who spends 80% of their time in the strategic-external quadrant is not failing at tactical-internal work by accident. They are making an implicit allocation choice, and the framework makes it explicit.
The model also maps cleanly onto career progression. Associate PMs typically concentrate in the tactical half of the grid, building craft in execution, data analysis, and cross-functional coordination. As PMs grow into senior and leadership roles, their center of gravity shifts toward the strategic half, with increasing emphasis on external competencies like market strategy, ecosystem positioning, and customer segment design. This progression is not a rigid ladder. Some organizations need deeply tactical senior PMs (think platform infrastructure teams), and the framework accommodates that by treating the axes as descriptive, not prescriptive. The point is not to push everyone toward the top-right quadrant. It is to make the team's current shape visible so leaders can make deliberate choices about where to invest.
Compared to alternatives like Ravi Mehta's Product Competency Toolkit or Reforge's PM archetypes, Cabage's framework is lighter-weight and more spatial. Mehta's toolkit offers deeper scoring rubrics, while Reforge's archetypes emphasize personality and working style. The Product Team Competencies Framework sits in between. It is structured enough to drive hiring and development conversations, but simple enough that a team can whiteboard it in fifteen minutes. That accessibility is its greatest strength and, for organizations wanting granular scoring, its primary limitation.
Teams using Hamster can operationalize this framework with AI agents that help map competencies, surface gaps, and generate development plans, turning a whiteboard model into a living system that evolves alongside the team.
How It Works
Step 1: Define the competency inventory for your context
Start by listing the specific competencies that matter for product management at your organization. Cabage's original framework provides a default set, but yours should reflect your product's domain, your company's stage, and your team's actual work. ' Aim for 12 to 20 competencies. Fewer than 12 lacks resolution. More than 20 becomes unwieldy and encourages checkbox thinking. You know you have done this step well when each competency on the list is distinct (no overlaps), observable (you can point to evidence of it), and recognized by PMs on your team as real work they actually do. A common mistake is importing a generic competency list from the internet without pruning it to your context, which produces a map that looks thorough but does not resonate with the people it is supposed to describe.
Step 2: Place each competency on the two-axis grid
For each competency, determine where it falls on the strategic-to-tactical axis and the external-to-internal axis. 'Competitive analysis' is strategic and external. 'Backlog grooming' is tactical and internal. 'Customer discovery' is strategic and external. 'Engineering estimation support' is tactical and internal. Some competencies will cluster near the center of an axis, meaning they involve both ends. That is fine. Place them where their center of gravity sits. Do not force everything to the extremes. You know you have done this well when the resulting grid shows a roughly balanced distribution, not all competencies piled in one quadrant. If your grid is heavily lopsided, reconsider whether your competency list is truly comprehensive or whether it reflects your team's existing bias. Watch out for the tendency to categorize 'important' skills as strategic and 'mundane' skills as tactical. Execution is not inherently less important than strategy.
Step 3: Assess each PM's current competency profile
Have each PM self-assess their proficiency in each competency, and supplement with manager assessment or peer feedback for calibration. Use a simple scale: developing, proficient, or strong. Avoid numeric scores at this stage because false precision undermines the exercise. The goal is a heat map showing where each PM concentrates, not a leaderboard. You know this step is working when PMs are surprised by at least one gap they had not consciously noticed, and when managers see patterns they had sensed but could not articulate. A common pitfall is letting this devolve into a performance review conversation. Frame it explicitly as a development exercise, not an evaluation. If PMs feel they are being graded, they will inflate their self-assessments and the entire map loses its diagnostic value.
Step 4: Overlay individual profiles into a team map
Combine all individual assessments into a single team view. ' Color-code or annotate the map to show which quadrants have deep coverage (multiple PMs rated proficient or strong) and which have thin or no coverage. You have done this well when you can point to specific business risks created by the gaps. For example, if no PM on the team has strong external-strategic skills, your competitive intelligence and market positioning are likely suffering, even if nobody has complained yet. The mistake to avoid is treating coverage as purely additive. Having five PMs who are all proficient at stakeholder management does not make stakeholder management a team strength that you can stop worrying about. It means you have redundancy in one area and likely starvation in another.
Step 5: Define target profiles for each role and level
Based on the team map and your organizational needs, define what the expected competency profile looks like for each PM role (growth PM, platform PM, core product PM) and each seniority level (associate, mid, senior, principal). These are not job descriptions. ' You know you have done this well when the target profiles feel honest, meaning they acknowledge that no role requires strength in all quadrants and they differentiate between roles in non-obvious ways. A frequent error is creating target profiles that describe a superhuman generalist. If every role requires 'strong' in every competency, you have not made any real choices and the profiles will not help anyone.
Step 6: Build individual development plans from the delta
Compare each PM's current profile to their target profile. The gaps become the development plan. For each gap, identify one or two concrete actions: a project assignment that exercises the skill, a mentorship pairing with someone who is strong in that quadrant, a course or reading list, or a stretch responsibility. Limit each PM to two or three development focus areas per quarter. More than that dilutes attention and produces no meaningful progress on any front. You know this step is working when PMs can articulate not just what they need to improve, but why that specific improvement matters for the team and for their own career trajectory. The trap to avoid is making the development plan a list of courses to take. Skill development in product management happens primarily through practice, not instruction. Pair every learning input with a doing output.
Step 7: Reassess quarterly and adjust the map
Competency maps decay. People grow, leave, change roles, or shift their focus. The team's product context evolves. Run a lightweight reassessment every quarter: update individual profiles, refresh the team map, and check whether target profiles still match organizational needs. This should take 30 to 60 minutes per PM, not a multi-day exercise. You know you are doing this well when the conversation in quarter three feels noticeably different from quarter one, because the team is using the framework's language naturally and the map reflects real changes. The risk is that reassessment becomes a bureaucratic ritual that nobody takes seriously. If people are just copying last quarter's assessments with minor tweaks, the cadence is too frequent or the process is too burdensome. Scale it back to semi-annual if needed.
When to Use
- When your product team has grown from three to ten or more PMs and you realize there is no shared language for what a 'strong PM' means at your company, leading to inconsistent hiring rubrics, subjective performance reviews, and promotion decisions that feel political rather than principled.
- When you are designing a new PM job description and want to be precise about which competency quadrant the role should emphasize, rather than copying a generic 'PM job description' template that lists every possible skill with no prioritization.
- When a PM comes to you asking how to grow into a senior product manager and you want to show them a concrete map of where they are strong, where they have gaps, and what the expected competency profile looks like at the next level, instead of offering vague advice like 'think more strategically.'
- When you are restructuring a product organization after a reorg, acquisition, or significant team turnover, and you need to quickly assess what competencies the remaining team covers, where the dangerous gaps are, and what kind of hires should be prioritized to restore coverage.
- When two PMs on the same team keep clashing about priorities or approach, and you suspect the conflict is actually a quadrant mismatch: one lives in strategic-external thinking while the other operates in tactical-internal execution, and neither understands why the other's concerns feel irrelevant.
- When building an interview rubric for PM candidates and you want each interviewer to assess a specific quadrant rather than everyone asking generic 'tell me about a time you shipped something' questions that produce redundant signal.
When Not to Use
- When your product team consists of one or two PMs who wear every hat by necessity. The framework's value comes from comparing profiles across a team and identifying collective gaps. With only one PM, there is no team shape to optimize. The framework will just confirm what that PM already knows: they are stretched thin across every quadrant. A simple personal development plan is more useful at this scale.
- When you need to evaluate a PM's performance on a specific recent project or deliverable. The framework maps standing competencies, not situational performance. Using it to judge whether someone handled a particular launch well conflates capability with execution context. Use a retrospective or outcome-based review instead.
- When the organization's real problem is unclear role boundaries between product management, project management, and engineering management. The framework assumes you already know what falls under the PM role at your company. If that boundary is contested, applying the framework will just surface the wrong debate: people will argue about whether 'sprint facilitation' is a PM competency rather than examining why role boundaries are blurry in the first place.
- When you need deep, granular scoring for compensation calibration or formal leveling tied to pay bands. The framework provides a spatial map, not a numeric rubric. Translating quadrant positions into compensation scores requires additional tooling like a structured leveling matrix. Trying to force the framework into a scoring function it was not designed for produces imprecise numbers that feel authoritative but are not.
- When the team's core challenge is not competency gaps but organizational dysfunction: no clear product strategy, leadership that overrides PM decisions, or engineering teams that do not respect the PM role. The framework cannot fix structural or cultural problems. Mapping competencies in a broken org just produces a beautiful chart that gathers dust because nobody has the authority to act on it.
Examples
Example: Series B SaaS company discovers a strategic-external blind spot after a failed product launch
A 45-person B2B SaaS company with six product managers launched a new analytics module that generated strong internal excitement but landed to silence in the market. Win rates dropped from 35% to 22% in the quarter after launch. The VP of Product used the framework to map the team and discovered that five of six PMs clustered in the tactical-internal and tactical-external quadrants. The team was exceptional at execution and customer support workflows but had almost no coverage in strategic-external: nobody was doing competitive analysis, market sizing, or buyer persona research with any depth. The analytics module had been built based on existing customer requests rather than market opportunity analysis. The VP hired a senior PM with deep strategic-external skills and shifted one existing mid-level PM's focus toward competitive intelligence. Within two quarters, the next feature launch was informed by a proper market analysis and achieved a 38% win rate. Looking back, the VP noted that the mistake was not the PMs' fault. The team simply did not have the competency coverage that the product's maturity demanded.
Example: Growth-stage fintech startup uses the framework to differentiate PM role types
A fintech startup with 12 PMs was struggling with role clarity. All PMs had the same title, same job description, and same performance rubric, but their actual work varied enormously. The platform PM spent 80% of her time with engineers on API design (tactical-internal). The growth PM spent 80% of his time on acquisition funnel experiments (tactical-external with some strategic-external). Both received the same review template asking them to rate themselves on 'strategic thinking,' which felt absurd to both for different reasons. The Head of Product mapped all 12 PMs on the framework and used the resulting profiles to define three distinct PM role types: Platform PM (weighted toward tactical-internal), Growth PM (weighted toward tactical-external and strategic-external), and Core Product PM (balanced across all quadrants). Each role type got its own target profile, career ladder, and interview rubric. Hiring quality improved immediately because recruiters could finally articulate what made a Growth PM hire different from a Platform PM hire. The team also stopped having unproductive debates about whether 'strategy' or 'execution' mattered more, because the framework made explicit that different roles weighted those axes differently.
Example: Enterprise product org uses the framework to plan a reorg after an acquisition
After acquiring a smaller competitor, a 200-person enterprise software company found itself with 22 PMs across two formerly separate product lines. The CPO needed to restructure quickly but had no objective view of what the combined team could and could not do. She ran a rapid competency assessment using the framework. The results revealed a surprising asymmetry: the acquiring company's PMs were heavily strategic-external (market-oriented, vision-driven) while the acquired company's PMs were heavily tactical-internal (process-oriented, deeply technical). Rather than treating one profile as superior, the CPO used the complementarity to her advantage. She paired PMs from each side on integrated product squads, ensuring each squad had coverage across the full grid. She also identified three PMs who were strong in areas nobody else covered (one in regulatory compliance, an unusual tactical-external competency, and two in developer ecosystem strategy, a strategic-external niche) and gave them cross-cutting responsibilities rather than assigning them to a single squad. The reorg completed in six weeks instead of the projected twelve because the framework gave the CPO a shared language for making team composition decisions that both legacy organizations could understand and accept.
Example: Solo PM uses the framework to build a case for her first PM hire
A seed-stage B2C startup had one product manager who had been doing everything: customer research, backlog management, sprint planning, competitive analysis, pricing strategy, and stakeholder updates. ' She mapped her own competency profile on the framework and realized she was proficient-to-strong across the tactical half of both axes but only developing in the strategic half. She was executing well on known priorities but had no bandwidth for market analysis, pricing experimentation, or long-term product vision work. She presented the framework to the founder and made the case: hire a senior PM with strategic-external strength to own market positioning and competitive strategy while she continued to anchor execution. The founder, who had been leaning toward hiring a junior PM to 'take things off her plate,' was persuaded by the visual evidence that the gap was not about bandwidth but about capability coverage. The senior hire started six weeks later and within a quarter had repositioned the product's pricing, which increased average revenue per user by 28%. The solo PM reflected that without the framework, she would have hired a junior version of herself and continued running blind on strategy.
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.
Defining Competency Expectations from Associate PM to Senior PM
How to calibrate expected proficiency levels across each quadrant of the framework for associate, mid-level, and senior product manager roles.
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.