How to Write a Competency-Based Product Manager Job Description
This skill teaches you how to translate the four competency quadrants into structured, measurable product manager job descriptions that attract candidates whose strengths match your team's actual needs.
Start by identifying which competency quadrants the role emphasizes, then translate each required competency into observable responsibilities and measurable outcomes. Structure the job description around 4-6 core competencies with specific proficiency levels, concrete deliverables, and evaluation criteria so candidates can self-select and hiring panels can score consistently.
Outcome: You produce a job description where every listed responsibility traces to a named competency at a defined proficiency level, giving candidates a clear signal of fit and giving interviewers a scoring rubric they can use before the first phone screen.
Prerequisites
- Familiarity with the Product Team Competencies Framework and its four quadrants (strategic-external, strategic-internal, tactical-external, tactical-internal)
- A clear understanding of the specific PM role you are hiring for and where it sits on the seniority ladder
- Access to your team's current competency gap analysis or at least an informal sense of which competencies you need most
Overview
Most product manager job descriptions read like a wish list assembled by committee. They blend vague aspirations ('strategic thinker,' 'data-driven') with laundry lists of tools and technologies, leaving candidates guessing at the actual shape of the role. The result is a flood of mismatched applicants, inconsistent interview scoring, and new hires who discover on day 30 that the role bears little resemblance to the posting. Writing a product manager job description grounded in the Product Team Competencies Framework solves this problem by anchoring every responsibility, requirement, and success metric to a specific competency at a specific proficiency level.
The technique works by first deciding which of the four framework quadrants the role emphasizes. A Growth PM will lean heavily into the strategic-external quadrant (market sensing, user research, positioning) and the tactical-external quadrant (experimentation, analytics, conversion optimization). A Platform PM will skew toward strategic-internal (technical vision, architecture influence) and tactical-internal (sprint execution, cross-team coordination). Once you know the quadrant mix, you select 4-6 competencies, define the proficiency level required for each, and write responsibilities as observable behaviors at that level. Instead of 'strong analytical skills,' you write 'Design and run A/B tests that inform quarterly roadmap decisions, presenting results with statistical context to senior leadership.' The specificity lets candidates self-select and gives your hiring panel a shared vocabulary.
The artifact you produce is a single document containing four sections: a role summary tied to team strategy, a competency-mapped responsibilities list, a requirements section expressed as demonstrated behaviors rather than credential proxies, and a set of evaluation criteria your interviewers can use in scorecards. This document feeds directly into the interview rubric design skill and connects back to your team gap analysis so you can verify the role you are posting is the role your team actually needs.
How It Works
The mental model behind competency-based job descriptions is that a role is not a bag of tasks but a profile of applied skills at specific levels. The Product Team Competencies Framework organizes PM skills along two axes: strategic versus tactical (how far ahead the work looks) and external versus internal (whether the work faces users and markets or faces teams and systems). Every PM role has a characteristic shape on this grid. A junior Associate PM might need Level 1 proficiency across all four quadrants, while a Senior Growth PM might need Level 4 in strategic-external and tactical-external but only Level 2 in the internal quadrants.
When you write a job description using this model, you are making the role's shape explicit. Each responsibility becomes a sentence describing what a person at that proficiency level actually does, not a trait they possess. 'Customer empathy' turns into 'Conduct 8-10 customer interviews per quarter, synthesize findings into opportunity briefs, and present prioritized insights to the product leadership team.' This transformation matters because traits are unfalsifiable in a resume, while behaviors are demonstrable in a portfolio, a case study, or a structured interview.
The approach also solves the problem of inflated requirements. Traditional job descriptions drift upward over time as each stakeholder adds their ideal trait. Competency-based descriptions resist this inflation because each addition must be justified against the framework. If you add 'deep technical architecture knowledge' (a strategic-internal competency) to a Growth PM role (which skews external), the mismatch is visible. You can still include it, but you must consciously lower the proficiency level or acknowledge you are hiring a hybrid role. This constraint keeps descriptions honest and focused.
Finally, competency-mapped descriptions create a feedback loop. When you later assess the hired PM using the same framework, you can compare their actual performance profile against the role profile you published. Gaps between the two reveal whether you wrote the description accurately or whether the role shifted after posting. Over multiple hiring cycles, this loop tightens your descriptions, improves candidate fit, and reduces early attrition.
Step-by-Step
Step 1: Confirm the Role's Quadrant Emphasis
Before you write a single word, pull up the Product Team Competencies Framework grid and mark which quadrants this role primarily operates in. Talk to the hiring manager and one or two people who will work closely with the new hire. ' Document the primary quadrant (the one where the role spends most of its energy), the secondary quadrant, and any tertiary involvement. If stakeholders disagree on emphasis, that disagreement is a signal the role is not yet well defined.
Resolve it before moving on. The output of this step is a simple quadrant priority ranking, such as: primary = strategic-external, secondary = tactical-external, tertiary = tactical-internal.
Tip: If every stakeholder picks a different quadrant, you may be trying to hire two roles in one. Split the role or explicitly decide which quadrant to deprioritize. A role that demands Level 4 across all four quadrants does not exist below the VP level.
Step 2: Select 4-6 Core Competencies
Within each prioritized quadrant, choose the specific competencies that define the role. A typical PM role needs 4-6 core competencies. Pull from your team's existing competency map or from the framework's standard competency list. For each competency, write one sentence explaining why it matters for this role specifically, not for PM roles in general.
For example, for a Growth PM you might select 'User Research' (strategic-external), 'Experimentation Design' (tactical-external), 'Data Analysis' (tactical-external), 'Positioning and Messaging' (strategic-external), and 'Cross-functional Communication' (tactical-internal). Limit yourself to six maximum. Every competency you add dilutes the signal to candidates.
Tip: Cross-reference your selections with the output from your team's gap analysis. If the team already has deep strength in data analysis, you may want to weight user research more heavily, even if both feel important.
Step 3: Set Proficiency Levels for Each Competency
Using the framework's proficiency scale (typically Level 1 through Level 4, corresponding roughly to Associate PM through Senior PM), assign a target level to each competency. A mid-level PM role might require Level 3 in the primary quadrant competencies and Level 2 in the secondary. Write the level number and then one sentence describing what performance at that level looks like for this competency. For instance, 'User Research, Level 3: Independently designs and runs multi-method research programs, synthesizes findings into strategic recommendations, and mentors junior PMs on interview technique.' This level-setting step is where you prevent requirements inflation, because every competency has a ceiling as well as a floor.
Tip: Refer to the sibling skill on defining competency levels from Associate PM to Senior PM for calibrated level descriptions. Borrowing from that calibration ensures your Level 3 means the same thing across every job description your team publishes.
Step 4: Write Responsibilities as Observable Behaviors
Transform each competency-level pair into 2-3 responsibility statements. Each statement should describe an action the person will take, the context they will take it in, and the outcome that will be visible. ' Group responsibilities under headings that match the quadrant names or use plain-language equivalents like 'Market and Customer Focus' for strategic-external. The total number of responsibilities should land between 8 and 15.
Fewer than 8 feels too vague; more than 15 suggests scope creep.
Tip: Read each responsibility aloud and ask: 'Could a candidate show me evidence of doing this in a portfolio review or a case study?' If the answer is no, the statement is still too abstract.
Step 5: Rewrite Requirements as Demonstrated Behaviors, Not Credentials
Traditional requirements sections list years of experience, degree types, and tool proficiencies. Replace these with behavioral requirements that map to your chosen competencies. Instead of '5+ years of product management experience,' write 'Demonstrated history of leading product discovery from problem identification through solution validation, with at least two shipped products where you owned the roadmap end to end.' Instead of 'MBA preferred,' write 'Ability to build and defend business cases with financial projections, demonstrated through past work.' You can still include a years-of-experience range as a rough signal, but frame it as 'typically' rather than 'required.' Keep hard requirements (like security clearance or language fluency) clearly labeled as required. Mark everything else as preferred or typical.
Tip: Run a quick check: would a self-taught PM with strong demonstrated competencies pass your requirements? If not, you have credential proxies masquerading as competency requirements.
Step 6: Add Evaluation Criteria for the Hiring Panel
At the bottom of the job description (or in an internal-only companion document), add a scoring rubric that maps each competency to interview signals. For each competency, list 2-3 questions or exercises the panel should use and describe what a strong, acceptable, and weak answer looks like. This section turns the job description into a living hiring tool rather than a one-time marketing document. Share this rubric with every interviewer before the first screen so they know which competencies they are responsible for evaluating.
This prevents the common failure mode where five interviewers all probe for 'strategic thinking' and nobody assesses execution skill.
Tip: Assign each interviewer a primary competency to own. Overlap is fine on one or two competencies for calibration, but every competency must have at least one designated evaluator.
Step 7: Write the Role Summary Last
With responsibilities, requirements, and evaluation criteria drafted, write the 3-4 sentence role summary that sits at the top of the job description. This summary should name the team, state the role's primary quadrant focus in plain language, and describe the business impact the role is expected to drive. Avoid generic phrasing like 'fast-paced environment' or 'wear many hats.' Instead, be specific: 'You will own the growth funnel for our self-serve product, running experiments that directly impact our $12M ARR target.' Writing the summary last ensures it reflects what you actually need rather than an aspirational version of the role.
Tip: The summary is the section most candidates read to decide whether to keep reading. Test it by showing it to someone unfamiliar with the role. If they cannot explain what the person will do day-to-day after reading those four sentences, revise.
Step 8: Review Against the Framework for Consistency
Read the completed job description end to end and check three things. First, does every responsibility trace back to one of your 4-6 named competencies? If a responsibility is orphaned, either cut it or add the competency it implies. Second, do the proficiency levels match the seniority title?
A role titled 'Senior PM' with all Level 2 competency expectations will confuse candidates and underpay for what you actually need. Third, does the quadrant emphasis you defined in Step 1 match the distribution of responsibilities? If you said the role is primarily strategic-external but 10 of 12 responsibilities are tactical-internal, the description has drifted. Fix the description or reconsider the quadrant emphasis.
Share the final version with the hiring manager and ask them to rank-order the competencies. If their ranking contradicts the description's emphasis, iterate.
Tip: Keep a one-page 'role profile card' alongside the description that lists the competency names, levels, and quadrant in a simple table. This card is the source of truth. If the prose ever contradicts the card, the prose needs editing.
Examples
Example: Growth PM at a B2C SaaS Startup (Series A, 30 employees)
A consumer SaaS startup needs its first dedicated Growth PM. The team has strong engineering and design but lacks someone to own the acquisition funnel and run experiments. The PM team is small (one Senior PM focused on core product), so this hire needs to operate independently. The competency gap analysis shows the team is weakest in strategic-external (market sensing) and tactical-external (experimentation).
The hiring manager and the existing Senior PM align on two primary quadrants: strategic-external and tactical-external. They select four competencies: User Research (Level 2), Experimentation Design (Level 3), Data Analysis (Level 3), and Positioning (Level 2). They add one secondary competency from tactical-internal: Cross-functional Communication (Level 2), because the Growth PM will coordinate with engineering and marketing. ' The evaluation criteria assign Experimentation Design to the technical interview, User Research to the hiring manager screen, and Data Analysis to a take-home exercise.
25% equity.
Example: Platform PM at a B2B Enterprise Company (500+ employees)
A large B2B company is hiring a Platform PM to own internal developer tools and API infrastructure. The role serves internal engineering teams rather than external customers. The team has three PMs already, all skewed toward external-facing product work, and the competency gap analysis reveals a critical weakness in strategic-internal (technical vision) and tactical-internal (delivery management).
The hiring committee identifies strategic-internal and tactical-internal as primary quadrants. They select five competencies: Technical Architecture Influence (Level 3), Roadmap Planning (Level 3), Stakeholder Management (Level 3), Sprint Execution (Level 2), and Developer Experience Research (Level 2). Responsibilities are framed for an internal audience: 'Partner with the platform engineering lead to define the 12-month API platform roadmap, balancing internal developer requests with long-term architectural goals' and 'Run biweekly developer experience surveys and quarterly interviews with internal consumers of your platform to identify friction points.' Requirements emphasize demonstrated behaviors: 'History of shipping developer-facing tools or APIs, with evidence of managing competing internal stakeholder priorities' replaces '7+ years in platform product management.' The evaluation criteria map Technical Architecture Influence to a system design discussion with the engineering director, Stakeholder Management to a role-play exercise with two internal stakeholders played by interviewers, and Roadmap Planning to a case study. The salary range is $165K-$195K, the description is 700 words, and it explicitly notes this is not a customer-facing role to prevent mismatched applications.
Example: Associate PM at a Mid-Stage B2B SaaS Company (Series B, 100 employees)
The PM team (four people) wants to hire an Associate PM to support the lead PM on the core product. They need someone who can execute tactically while developing strategic skills. The team wants to set honest expectations about the entry-level nature of the role without scaring away ambitious candidates.
The hiring manager sets all four quadrants to Level 1, reflecting an entry-level role where the associate will contribute across areas under supervision. They select four competencies: User Research (Level 1), Data Analysis (Level 1), Sprint Execution (Level 1), and Cross-functional Communication (Level 1). Responsibilities are scoped to assisted work: 'Conduct 4-6 customer interviews per month using discussion guides designed with the lead PM, and summarize findings in a structured template' and 'Own the weekly sprint review presentation for your pod, reporting progress and blockers to the broader product team.' Requirements avoid years-of-experience thresholds entirely and instead ask for 'demonstrated curiosity about product management, evidenced through personal projects, coursework, or contributions to product communities.' The description explicitly names what the associate will learn: 'In your first year, you will develop Level 2 proficiency in user research and data analysis, with mentorship from a Senior PM.' The salary range is $85K-$105K, the description is 550 words, and the evaluation criteria assign all four competencies to a single structured case interview plus a behavioral screen. By naming the growth path and leveling honestly, the description attracted 40% fewer but significantly more qualified applicants compared to the team's previous generic posting.
Example: Senior PM Leading a New Product Line (B2B2C, 200 employees)
A company expanding into a new market segment needs a Senior PM to lead a zero-to-one product initiative. The role requires both strategic vision and hands-on execution because the team is small (2 engineers, 1 designer) and the product does not exist yet. The competency framework shows the company needs someone strong in strategic-external (market entry) with solid tactical-external (rapid prototyping and validation).
The VP of Product and the CEO align on strategic-external as the dominant quadrant with tactical-external as the strong secondary. They select six competencies: Market Analysis (Level 4), User Research (Level 3), Business Case Development (Level 4), Experimentation Design (Level 3), Roadmap Planning (Level 3), and Cross-functional Leadership (Level 3). The Level 4 ratings on Market Analysis and Business Case Development reflect the zero-to-one nature: the PM must independently assess market entry feasibility and build financial models without an existing playbook. ' The evaluation criteria include a 60-minute strategy presentation where the candidate analyzes a hypothetical market entry, a portfolio review of past zero-to-one launches, and a behavioral interview on stakeholder leadership.
The salary range is $175K-$210K with significant equity, and the description is 750 words.
Best Practices
Limit core competencies to 4-6 per role. Every additional competency dilutes the signal candidates receive about what matters most, and it makes interview scoring harder because evaluators spread their attention across too many dimensions. If your list exceeds six, force-rank and cut.
Use the same competency vocabulary across all PM job descriptions in your organization. When one posting says 'customer empathy' and another says 'user research' for the same skill, candidates cannot compare roles and internal mobility becomes confusing. Standardize on the framework's terminology and define it in a shared glossary.
Include proficiency levels explicitly in the posting, not just internally. Candidates who see 'Level 3 in Experimentation Design: independently designs multi-variant tests and interprets results with statistical rigor' can self-assess far more accurately than candidates who see 'strong experimentation skills.' This specificity reduces unqualified applications by 20-40% based on practitioner reports.
Write separate 'required' and 'preferred' sections and keep the required list brutally short. Every requirement you add reduces the applicant pool, disproportionately discouraging underrepresented candidates. If a competency is nice-to-have, say so explicitly.
Test the job description with a current PM at the target level before publishing. Ask them: 'Does this sound like a role you would apply to? Does anything feel misleading?' Their feedback catches inflated expectations and jargon that reads differently outside your organization.
Update the job description after every hire using the evaluation data from the interview process. If interviewers consistently found that one competency was irrelevant during screening, remove or deprioritize it. If a competency you omitted turned out to be the deciding factor, add it. Treat the description as a living document, not a one-time artifact.
Include compensation range and team context. Competency-based descriptions already signal transparency, and withholding salary undermines that signal. State the range, the team size, and who the role reports to. Candidates who understand the org structure self-select more accurately.
Common Mistakes
Listing every competency from the framework at a high proficiency level
Correction
This happens when multiple stakeholders each add their ideal competency without coordinating. The result is a job description that describes a unicorn rather than a real person. Catch it by counting: if you have more than six core competencies or more than two at the highest proficiency level, you have likely over-specified. Force the hiring manager to rank-order and cut.
If the role genuinely needs breadth, lower the proficiency levels to acknowledge that breadth comes at the cost of depth.
Translating competencies into trait adjectives instead of observable behaviors
Correction
Writing 'strong strategic thinker' feels like you have used the framework, but you have not. The competency framework describes what people do, not what they are. The tell is that your responsibility statements contain adjectives rather than verbs. Go back through every line and convert traits into actions: 'Develops and presents quarterly roadmap proposals to the executive team, incorporating market analysis and competitive positioning' replaces 'strategic and visionary leader.'
Setting proficiency levels without referencing calibrated definitions
Correction
Without a shared understanding of what Level 2 versus Level 3 looks like, different writers assign different levels for identical expectations. This creates inconsistency across job postings and confuses internal mobility. Always pull the proficiency definitions from your framework's level descriptions (see the sibling skill on defining competency levels). If your organization has not yet calibrated levels, do that work first before writing descriptions.
Writing the role summary first and then backfilling responsibilities to match
Correction
When you start with the summary, you anchor on an aspirational narrative and then stretch responsibilities to justify it. The responsibilities end up vague because they are reverse-engineered from prose rather than built from competency analysis. Write the summary last, after the competencies, levels, and responsibilities are locked. The summary should describe what you built, not prescribe what you wished for.
Omitting the evaluation criteria section because it feels like an internal document
Correction
The evaluation criteria are the bridge between the job description and the interview process. Without them, interviewers default to their own priorities and the carefully mapped competencies never reach the scoring rubric. Even if you do not publish the rubric externally, attach it to the job description as an internal companion. Share it with every interviewer before their first conversation with a candidate.
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.
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.
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 do I write a product manager job description when my organization has not adopted the competency framework yet?
You can still use competency-based thinking without a formal framework rollout. Start by listing the 4-6 skills you care about most for this role, categorize them roughly into the strategic/tactical and internal/external quadrants, and assign simple proficiency expectations (basic, intermediate, advanced). This gives you 80% of the benefit. As you hire and evaluate candidates against these criteria, you build the case for formalizing the framework organization-wide.
How long should a product manager job description be?
Target 550-750 words for the external posting. Research consistently shows that postings under 500 words feel too vague for candidates to self-assess, while postings over 800 words see significant drop-off in completion rates. The internal companion document with evaluation criteria can be as long as it needs to be, but the candidate-facing version should be scannable in 3-4 minutes.
Should I include the proficiency levels in the public job posting or keep them internal?
Include them. Proficiency levels with one-sentence behavioral descriptions are the single most effective way to help candidates self-select. Candidates who see 'Level 3: independently designs multi-variant experiments' can immediately judge whether that matches their experience. Hiding this information forces candidates to guess and increases the volume of mismatched applications. The slight risk of candidates gaming the language is far outweighed by the filtering benefit.
How do I handle competencies that span multiple quadrants?
Some competencies, like 'stakeholder management,' touch both internal and external work. Assign the competency to whichever quadrant reflects how this specific role will use it. A PM who manages external partner relationships places stakeholder management in strategic-external. A PM who manages internal engineering dependencies places it in tactical-internal. If the role genuinely needs both, list it once and note the dual context in the responsibility description.
Should I write a different job description for each PM role type or use a standard template?
Use a standard structural template (role summary, competency-mapped responsibilities, behavioral requirements, evaluation criteria) but customize the content completely for each role. The template ensures consistency across postings and makes it easy for candidates to compare roles. The content ensures each posting reflects the actual quadrant emphasis and proficiency profile. The sibling skill on differentiating PM role types gives you the distinct profiles to build from.
How do I prevent the job description from drifting as stakeholders add requirements?
Create a one-page role profile card before writing the description. The card lists the 4-6 competencies, their proficiency levels, and the quadrant emphasis. Any proposed addition to the description must map to a competency on the card. If it does not map, the stakeholder must either replace an existing competency or accept the addition as a 'nice to have.' This constraint forces prioritization and prevents the description from becoming a wish list.
Why does my product manager job description keep attracting the wrong candidates?
The most common cause is trait-based language that every PM identifies with. Words like 'strategic,' 'data-driven,' and 'customer-obsessed' feel universally flattering and provide no filtering signal. Replace every trait with a specific behavior at a specific level. The second common cause is missing or hidden salary ranges, which forces candidates to apply speculatively. Adding a range and behavioral specificity together typically reduces application volume by 30-40% while increasing the percentage of qualified applicants.