How to Differentiate Technical Product Manager and Other PM Role Types Using the Competency Framework
This skill teaches you to use the two-axis competency quadrant model to create distinct, defensible profiles for technical product manager roles, growth PMs, platform PMs, and generalist PMs based on where their required competencies cluster.
Map each PM role's required competencies onto the strategic-tactical and internal-external quadrant model. A technical product manager clusters heavily in the internal-tactical quadrant (architecture decisions, API design, system constraints), while growth PMs skew external-tactical (experimentation, funnel optimization) and generalists spread evenly across all four quadrants. The resulting competency profile becomes the objective basis for role definition, hiring criteria, and career pathing.
Outcome: You produce a set of competency profile cards, one per PM role type, that show exactly which quadrant each role emphasizes, which competencies are primary vs. secondary, and where role boundaries sit. These profiles become the single source of truth for writing job descriptions, designing interviews, setting career ladders, and resolving org design confusion about what distinguishes one PM role from another.
Prerequisites
- Familiarity with the Product Team Competencies Framework's two-axis model (strategic vs. tactical, internal vs. external)
- A working list of 12-20 product management competencies already mapped onto the quadrant axes
- Understanding of the PM roles currently in use or planned at your organization
- Basic knowledge of what technical product managers, growth PMs, and platform PMs actually do day-to-day
Overview
Most product organizations struggle with a deceptively simple question: what exactly makes a technical product manager different from a growth PM or a generalist PM? Job titles vary wildly across companies, and the same title can mean completely different things depending on the team. The result is fuzzy role boundaries, misaligned hiring, and frustrated PMs who are evaluated against the wrong competency expectations. This skill gives you a systematic way to cut through that ambiguity by mapping each role type onto the Product Team Competencies Framework quadrant model.
The core move is straightforward: take a defined set of PM competencies (things like user research, system design, data analysis, stakeholder management, roadmap planning, experimentation), and plot where each role type's emphasis falls across the strategic-tactical and internal-external axes. A technical product manager, for instance, needs deep competency in areas like system architecture understanding, API design collaboration, and technical trade-off analysis, all of which cluster in the internal-tactical quadrant. A growth PM, by contrast, concentrates in the external-tactical space with competencies like funnel optimization, A/B testing rigor, and acquisition channel analysis. The quadrant model makes these differences visual and concrete rather than hand-wavy.
The artifact you produce is a set of competency profile cards. Each card names a role type, identifies its primary quadrant emphasis (where 50% or more of the role's critical competencies sit), its secondary quadrant (where another 25-30% cluster), and the remaining competencies that round out the role. These profile cards feed directly into sibling skills like writing competency-based job descriptions and designing interview rubrics. They also surface organizational gaps: if your team has three generalist PMs but your product's biggest constraint is technical platform decisions, the competency profiles will show that the internal-tactical quadrant is dangerously understaffed.
Success looks like this: any hiring manager, PM leader, or individual contributor at your company can pick up a competency profile card and immediately understand what makes a technical product manager role distinct from a growth PM role, not through vague narrative descriptions, but through a concrete list of weighted competencies mapped to specific quadrant positions.
How It Works
The technique works because the two-axis quadrant model forces you to make tradeoffs that narrative job descriptions never do. When you write a traditional job description, you can list 15 competencies and imply they are all equally important. That feels comprehensive, but it is actually meaningless, because no one is equally strong across 15 competencies, and no role actually requires equal depth in all of them. The quadrant model demands that you assign each competency to a position on two axes and then weight the overall role toward specific quadrants. That weighting is what differentiates role types.
The strategic-tactical axis captures the time horizon and altitude of decisions. Strategic competencies involve market positioning, product vision, multi-quarter roadmap planning, and business model reasoning. Tactical competencies involve sprint-level execution, backlog grooming, bug triage, specification writing, and short-cycle experimentation. The internal-external axis captures the direction of attention. External competencies face customers, partners, markets, and competitors. Internal competencies face engineering, infrastructure, architecture, DevOps, and organizational processes.
When you combine these two axes, you get four quadrants. Each PM role type has a characteristic shape, a pattern of where its critical competencies cluster. The technical product manager clusters in internal-tactical and internal-strategic: they spend most of their time translating between product goals and engineering constraints, making build-vs-buy decisions, defining API contracts, and managing platform dependencies. Growth PMs cluster in external-tactical and sometimes external-strategic: they run experiments, optimize funnels, analyze acquisition channels, and iterate on conversion flows. Platform PMs sit heavily in internal-strategic: they think about architectural evolution, developer experience, and multi-team infrastructure decisions. Generalist PMs, by definition, spread more evenly across all four quadrants, which is why their role is hardest to hire for and easiest to mislabel.
The key insight from the Product Team Competencies Framework is that roles are not defined by what competencies they include, because most PM roles include many of the same competencies. Roles are defined by the relative weight and depth required in each competency. A technical product manager still does user research, but they do it at a different depth and frequency than a consumer-facing generalist PM. The quadrant model captures this nuance through primary and secondary quadrant designations. The primary quadrant is where the role spends 50% or more of its competency depth. The secondary quadrant gets 25-30%. The remaining quadrants still exist but are expected at baseline, not expert, levels.
This model breaks down in exactly one scenario: when an organization genuinely needs a PM who is deep in all four quadrants simultaneously. That is almost never a single role. It is either a very senior PM lead who delegates execution, or it is a sign that the organization is conflating two roles into one headcount. Recognizing that distinction is part of the skill.
Step-by-Step
Step 1: Assemble your master competency list from the quadrant model
Start with the competency inventory you have already mapped onto the strategic-tactical and internal-external axes. If you have not done this mapping yet, complete the mapping competencies across axes skill first. You need a list of 12-20 competencies, each assigned to one of the four quadrants. Typical competencies include user research, data analysis, roadmap planning, stakeholder management, technical architecture understanding, experimentation design, go-to-market planning, backlog management, API and integration design, funnel optimization, platform strategy, and developer experience management.
Write each competency on a card or in a spreadsheet row with its quadrant assignment clearly marked. Do not proceed until every competency is assigned to exactly one quadrant. You should have at least 3 competencies per quadrant to make the differentiation exercise meaningful.
Tip: If you are stuck deciding which quadrant a competency belongs to, ask yourself: does this competency primarily serve people outside the product team (external) or inside it (internal)? And does it primarily involve decisions with a time horizon of weeks (tactical) or quarters (strategic)? Those two questions usually resolve ambiguity.
Step 2: List the PM role types you need to differentiate
Write down every PM role type that exists in your organization or that you are considering creating. Common types include generalist product manager, technical product manager, growth PM, platform PM, data PM, design-oriented PM, and enterprise PM. Limit yourself to 3-5 role types for the initial exercise. More than five becomes unwieldy and usually reveals that you are over-segmenting.
If your organization only has one PM role type today but suspects it needs specialization, list the generalist role plus 2-3 candidate specialized roles. For each role type, write one sentence describing what you think makes it distinctive. This sentence is your hypothesis, and the exercise will either confirm it or reveal that the distinction is not as clear as you assumed.
Tip: If two role types are hard to distinguish in a single sentence, they may actually be the same role at different seniority levels rather than genuinely different role types. Check whether the [competency levels skill](/skills/defining-competency-levels-from-associate-to-senior-pm) better captures the difference.
Step 3: Assign competency weights for each role type
For each role type, go through your master competency list and rate how critical each competency is to that specific role. Use a three-level scale: primary (this competency is essential and must be at expert depth), secondary (this competency is important but does not need expert depth), and baseline (this competency is useful but not a differentiator for this role). Work through one role type at a time, completing all competencies before moving to the next role. For a technical product manager, you might mark 'technical architecture understanding' as primary, 'API and integration design' as primary, 'backlog management' as primary, 'user research' as secondary, and 'go-to-market planning' as baseline.
Record these ratings in a matrix: roles as columns, competencies as rows, with P/S/B in each cell.
Tip: Force yourself to mark no more than 5 competencies as primary for any single role. If everything is primary, nothing is, and you have failed to differentiate the role. The constraint is what makes the exercise valuable.
Step 4: Calculate quadrant emphasis for each role type
Now aggregate the competency weights by quadrant. Count the number of primary competencies in each quadrant for each role. Then count secondary competencies. The quadrant with the most primary competencies is the role's primary quadrant.
The quadrant with the second-most primary or the most secondary competencies is the role's secondary quadrant. ' If a role's primary competencies are spread evenly across three or four quadrants, that is a generalist profile, not a specialized one. Record this on each role's profile card.
Tip: If two specialized roles end up with the same primary and secondary quadrant, look more closely at which specific competencies differ. The quadrant is the same, but the competencies within it may be distinct enough to justify separate roles. For example, a data PM and a technical product manager might both cluster in internal-tactical, but the data PM's primary competencies are around data pipeline design and analytics infrastructure while the technical PM's are about API contracts and system reliability.
Step 5: Create visual competency profile cards
For each role type, create a one-page profile card with four sections. First, the role name and a one-sentence definition derived from your quadrant analysis, not your original hypothesis. Second, a visual representation of the quadrant model with the primary quadrant shaded darkly, the secondary quadrant shaded lightly, and the remaining quadrants left unshaded. Third, a list of primary competencies (3-5 items) with a brief note on the expected depth.
Fourth, a list of secondary competencies (2-4 items) with notes on baseline expectations. These cards are your core artifact. They should be easy to compare side by side. If you are working digitally, a simple 2x2 grid diagram with color coding works.
If you are working on paper or a whiteboard, use sticky notes with different colors for primary, secondary, and baseline.
Tip: Add a 'Not this role' section at the bottom of each card listing 1-2 common misconceptions. For the technical product manager card, you might write: 'Not an engineering manager. The technical PM does not manage engineers or own the technical architecture itself. They translate between product goals and technical constraints.' This disambiguation prevents the profile from being misread.
Step 6: Validate profiles against real work samples
Take the last 2-3 months of actual work done by PMs in your organization (or, if hiring for a new role, by PMs at peer companies whose work you can examine through case studies or interviews). Map the work artifacts, such as PRDs, experiment plans, architecture decision records, go-to-market briefs, and sprint plans, to your competency list. Count which competencies appear most frequently in each PM's output. Compare this empirical distribution to the profile card you created for that role type.
If a person with the title 'technical product manager' is actually spending 60% of their time on external-strategic work like market positioning, either the role is mislabeled or the profile needs updating. Adjust profiles based on what the work data reveals, not what the title implies.
Tip: This validation step is where most organizations discover their biggest insight. The stated role and the actual work often diverge significantly. Do not skip this step or treat it as optional. The mismatch itself is valuable data for organizational design conversations.
Step 7: Define boundary rules between adjacent roles
For every pair of role types that share a primary or secondary quadrant, write explicit boundary rules. A boundary rule states what falls on each side of the line. For example: 'Technical PM vs. Platform PM: The technical PM owns feature-level technical decisions (API design for a specific integration, database schema for a specific feature).
The platform PM owns cross-cutting infrastructure decisions (shared authentication service, event bus architecture, developer tooling). ' Write 2-3 boundary rules per adjacent pair. These rules prevent turf wars and clarify escalation paths.
Tip: Boundary rules should reference real decisions your organization has made or will make. Abstract boundaries like 'the technical PM handles technical things' are useless. Name specific types of decisions, documents, or meetings where the boundary applies.
Step 8: Socialize profiles and iterate based on feedback
). Collect feedback in structured form: ask each reviewer to mark where they agree, where they disagree, and where they are confused. Common feedback includes profiles that feel too narrow (usually a sign the reviewer is conflating seniority with specialization) and boundary rules that do not match current practice (usually a sign that current practice needs to change, not the boundary). Incorporate feedback that sharpens the profiles.
Resist feedback that makes every role look the same.
Tip: Run the feedback session with PMs and their cross-functional partners separately, then compare. If engineering leads think the technical product manager should go deeper on internal-tactical competencies than the PMs themselves believe, you have found a real expectation gap that the profile card should surface explicitly.
Examples
Example: B2B SaaS startup splitting generalist PM into technical and growth roles
A 40-person B2B SaaS startup has 3 generalist PMs and is about to hire a 4th. The product has a complex API integration layer that partners use, and a self-serve onboarding funnel that drives 70% of new revenue. The VP of Product suspects they need a technical product manager for the API side and a growth PM for the funnel, but is not sure if the volume of work justifies specialization or if two more generalists would be more flexible.
The VP starts with a 16-competency list already mapped to quadrants. For the proposed technical PM role, they mark 'API and integration design,' 'system architecture understanding,' 'technical trade-off analysis,' and 'developer experience' as primary. All four land in the internal-tactical and internal-strategic quadrants. For the growth PM role, they mark 'funnel optimization,' 'experimentation design,' 'acquisition channel analysis,' and 'conversion copywriting' as primary, all clustering in external-tactical.
They compare these profiles to the existing generalist profile, where primary competencies are spread across all four quadrants: 'user research' (external-strategic), 'roadmap planning' (internal-strategic), 'backlog management' (internal-tactical), and 'customer interviews' (external-tactical). The comparison makes the decision visible. The API work requires depth in internal-tactical competencies that the generalists are only covering at baseline level. The funnel work requires external-tactical depth that generalists also cover at baseline.
The VP validates by reviewing the last quarter's work: the PM covering the API team spent 60% of their time in internal-tactical work but rated themselves as only 'adequate' in those competencies. The funnel PM ran 12 experiments but lacked the statistical rigor competency to interpret results confidently. Both specializations are justified. The VP creates profile cards and uses them to write two distinct job descriptions, each anchored to a primary quadrant with 4 primary competencies and 3 secondary competencies.
Example: Enterprise software company differentiating platform PM from technical product manager
A 300-person enterprise software company has a 'platform team' of 15 engineers and a 'payments integration team' of 8 engineers. Both teams have PMs with the title 'technical product manager,' but they do very different work. The platform PM is making multi-quarter infrastructure decisions about shared services, while the payments PM is designing specific API endpoints for payment partners. Frequent conflicts arise about who owns shared infrastructure changes that affect payment flows.
The PM Director runs the differentiation exercise. For the platform PM, primary competencies are 'platform architecture strategy,' 'developer experience design,' 'cross-team dependency management,' and 'technical roadmap planning,' all clustering in internal-strategic. For the payments technical PM, primary competencies are 'API contract design,' 'partner technical requirements gathering,' 'integration testing strategy,' and 'technical specification writing,' clustering in internal-tactical with some external-tactical (partner-facing work). The quadrant analysis reveals the roles are clearly distinct: platform PM is internal-strategic, payments technical PM is internal-tactical.
They share the internal axis but differ on the strategic-tactical axis. The Director writes a boundary rule: 'The platform PM owns decisions about shared service architecture, SLAs, and multi-team infrastructure changes. The payments technical PM owns decisions about payment-specific API endpoints, partner integration specifications, and payment feature behavior. ' This boundary rule resolves the recurring conflicts by naming the specific decision types each role controls.
Example: Consumer app team clarifying growth PM vs. generalist PM
A consumer mobile app with 2 million monthly active users has 5 PMs. One PM focuses exclusively on activation and retention experiments and calls themselves the 'growth PM.' The other 4 PMs handle feature areas like messaging, profiles, discovery, and payments. The growth PM's work increasingly overlaps with the feature PMs, especially when experiments require feature changes. There is confusion about whether the growth PM is a separate role type or just a PM with a specific focus area.
The Head of Product runs the competency weighting exercise for both the growth PM and a representative feature PM. The growth PM's primary competencies are 'experimentation design,' 'funnel analysis,' 'behavioral data interpretation,' and 'rapid prototyping for tests,' all in external-tactical. The feature PM's primary competencies are 'user research,' 'feature roadmap planning,' 'design collaboration,' and 'stakeholder communication,' spread across external-strategic, external-tactical, and internal-strategic. The quadrant profiles are distinct: growth PM is concentrated in external-tactical, while feature PMs spread more broadly.
Validation confirms the distinction: the growth PM ran 23 experiments last quarter and wrote zero PRDs, while feature PMs ran 0-2 experiments each and wrote 4-6 PRDs. The Head of Product creates profile cards and a key boundary rule: 'The growth PM owns experiment design, statistical analysis, and growth metric targets. Feature PMs own feature specifications and roadmap decisions. ' The profiles also reveal that the growth PM lacks strategic competency depth, which becomes a development goal: the growth PM should build external-strategic competency to connect experiments to long-term product vision rather than optimizing isolated metrics.
Example: Startup founder using profiles to write their first PM hire's job description
A seed-stage startup with 8 engineers and no PM is hiring their first product manager. The founder has been doing all PM work and is unsure whether to hire a generalist, a technical product manager, or a growth PM. The product is a developer tool with a self-serve signup flow and a complex CLI that requires deep technical understanding.
The founder maps their own work over the last quarter onto the competency framework. They find that they spend roughly 40% of time on internal-tactical work (writing technical specs, reviewing architecture decisions, defining CLI behavior), 25% on external-tactical work (analyzing signup funnel, writing docs, running onboarding experiments), 20% on external-strategic work (customer interviews, market positioning), and 15% on internal-strategic work (roadmap planning, team process). The heaviest cluster is internal-tactical, which matches a technical product manager profile. However, the founder also identifies that the external-tactical work (growth and funnel optimization) is what they most want to offload because it requires specialized analytics skills they lack.
This creates a tension: the product needs a technical PM based on internal-tactical demands, but the founder's biggest pain point is external-tactical. The founder resolves this by mapping two possible hires. Hire #1: a technical product manager with internal-tactical as primary and external-tactical as secondary, who can handle the core technical PM work and do baseline growth work. Hire #2: a growth PM with external-tactical as primary, but this would require the founder to continue all internal-tactical work indefinitely.
Given that the founder is technical and handles internal-tactical work competently (just time-constrained), they choose to hire the growth PM first and continue the technical PM work themselves until headcount supports a second PM hire. The competency profile made this tradeoff explicit rather than leaving it to gut instinct.
Best Practices
Limit primary competencies to 3-5 per role type. The value of differentiation comes from constraint. If every role has 8 primary competencies, the profiles blur together and lose their diagnostic power. The discipline of choosing the top 3-5 forces honest conversations about what each role really needs to be great at versus merely adequate.
Revisit profiles every 6-12 months as your product and organization evolve. A pre-product-market-fit startup may need generalists, while a scaling company may need to split into technical and growth PM specializations. If you lock profiles and never update them, the roles ossify while the work changes underneath.
Use the same competency list across all role types. Differentiation works by weighting the same competencies differently, not by inventing new competencies for each role. If you create role-specific competencies, you lose the ability to compare profiles side by side and you make career mobility between roles artificially difficult.
Anchor role definitions in competency emphasis, not in team assignment. Saying 'the technical product manager is whoever works with the platform team' is circular. The competency profile should define what makes a PM technical regardless of which team they sit on. This makes the profiles portable across reorganizations.
Always pair a profile card with explicit boundary rules for adjacent roles. Without boundaries, profile cards create a false sense of clarity. Two PMs can read their respective cards, agree with both, and still clash on who owns a specific decision. Boundary rules prevent that by naming specific decision types.
Share profiles with candidates during the hiring process. Competency profiles are not internal HR documents. Sharing them with candidates lets the candidate self-select and gives them a concrete picture of what success looks like. This reduces mis-hires significantly, especially for specialized roles like technical product manager positions where expectations vary enormously across companies.
Do not use profiles to constrain growth. A PM whose primary quadrant is external-tactical should not be told they are not allowed to develop internal-strategic competencies. Profiles define role emphasis, not career ceilings. Connect this explicitly to the career development planning skill to show PMs how role profiles feed growth conversations.
Common Mistakes
Defining role types by technology stack instead of competency emphasis
Correction
Calling someone a 'technical product manager' because they work on a backend service or an API is confusing team assignment with role type. A PM on an API team might actually function as a generalist if their day-to-day work involves equal parts user research, roadmap planning, and stakeholder management. Define the role by looking at where competencies cluster on the quadrant model. If a PM on the API team spends most of their depth on internal-tactical competencies like system design collaboration and technical trade-off analysis, they are genuinely a technical PM.
If they just happen to sit near engineers but do generalist work, the label is misleading and will cause hiring and evaluation problems.
Creating too many specialized role types too early
Correction
Organizations with fewer than 5 PMs rarely need more than 2 role types (generalist plus one specialization). Over-segmenting creates roles that are too narrow to fill, too narrow to grow into, and too narrow to justify headcount. The signal that you need a new role type is when two PMs on the same team consistently clash over decisions because their competency profiles genuinely differ, not because you read about growth PMs in a blog post. Start with generalist profiles and only split when the work demands it.
Treating the primary quadrant as the only quadrant that matters
Correction
A technical product manager whose entire evaluation focuses on internal-tactical competencies will become an engineering proxy, not a product manager. Every PM role type still needs baseline competency across all four quadrants. The primary quadrant designation means expert depth, not exclusive focus. Watch for this in interview rubrics: if your technical PM interview only tests system design and ignores user empathy and business reasoning, you are hiring a technical lead with a PM title.
Secondary and baseline competencies matter for overall effectiveness even if they are not the differentiator.
Confusing seniority differences with role type differences
Correction
A senior generalist PM naturally shifts toward the strategic axis as they gain experience. This does not make them a different role type. It makes them a more experienced version of the same role type. If your 'strategic PM' profile looks exactly like your 'generalist PM' profile but with higher depth expectations on the strategic axis, you have described seniority, not a distinct role.
Use the competency levels skill for seniority and this skill for role type. The two dimensions are orthogonal. A junior technical product manager and a senior technical product manager are the same role type at different levels.
Skipping the empirical validation step and relying only on theory
Correction
Profile cards built in a conference room without checking them against actual work artifacts are organizational fiction. They reflect what leadership thinks roles should look like, which often diverges sharply from what PMs actually do. The validation step (Step 6) exists specifically to catch this drift. If you skip it, you will build hiring rubrics and career ladders against aspirational profiles that frustrate current PMs and confuse candidates.
Always compare the profile to real work output before finalizing it.
Making profile cards once and treating them as permanent
Correction
Product organizations evolve. A company that launches with a single product needs generalists. A company scaling to a multi-product platform needs technical PMs, platform PMs, and possibly data PMs. Profiles that made sense 18 months ago may not match the current product surface area.
Set a calendar reminder to review profiles biannually. The review does not need to be elaborate. Compare each profile card to the last quarter of actual PM work and ask whether the emphasis has shifted. If it has, update the card.
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.
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 PM role types should my organization have?
For most organizations, 2-4 distinct role types are sufficient. Teams with fewer than 5 PMs usually need only 1-2 types (generalist plus one specialization). Organizations with 10-20 PMs typically need 3-4 types. Beyond 4 types, you are usually over-segmenting, and the distinctions become so fine that they create more confusion than clarity. The competency quadrant model has four quadrants, so four role types is a natural ceiling for most companies.
Can a single PM change role types over the course of their career?
Yes, and this is expected. A PM might start as a generalist, develop deep technical competencies and shift into a technical product manager role, then later move into a platform PM role as they gain strategic depth. Competency profiles define what a role requires, not what a person is forever. When PMs want to transition, use the [career development planning skill](/skills/building-pm-career-development-plans) to identify the competency gaps between their current profile and the target role's profile, then build a development plan to close those gaps.
Should I differentiate role types before or after assessing my team's current competencies?
Differentiate role types first, then assess. The role profiles become the benchmark against which you assess individuals. Without a clear profile for what a technical product manager should look like at your company, assessing whether a PM is 'strong technically' is subjective and inconsistent. Complete this skill, then use the [team assessment skill](/skills/assessing-pm-team-strengths-and-gaps) with the profiles as your standard.
How do I handle a PM whose actual work does not match their role type profile?
First, determine whether the mismatch is a person problem or a role design problem. If the PM is doing different work than their profile specifies because the organization needs them to, your profile is wrong and should be updated. If the PM is doing different work because they prefer it despite the organization needing them to focus differently, that is a management conversation about role expectations. The competency profile makes this conversation objective: 'Your role's primary quadrant is internal-tactical, but your last quarter's work was 60% external-strategic. Let us discuss what needs to change.'
How do I differentiate a technical product manager from an engineering manager?
The technical product manager owns the 'what' and 'why' of technical product decisions, like which APIs to build, what trade-offs to accept for shipping faster, and how to prioritize technical debt against feature work. The engineering manager owns the 'how' and 'who,' making decisions about system implementation, code quality standards, and team assignments. On the competency framework, the technical PM's competencies are product competencies applied in a technical context (internal-tactical and internal-strategic quadrants), while the EM's competencies are engineering leadership competencies that sit outside the PM framework entirely. If your 'technical PM' is making implementation decisions and managing engineers, they are an EM with the wrong title.
Why does my technical product manager profile keep looking like a generalist profile?
This usually happens for one of two reasons. Either you are not constraining primary competencies strictly enough (remember: maximum 5 primaries per role, and at least 50% should cluster in one quadrant), or your organization does not actually need a specialized technical PM and is trying to force a distinction that the work does not support. Go back to Step 6 and examine actual work artifacts. If the PM who is supposed to be 'technical' is doing equal amounts of user research, go-to-market planning, and architecture review, they are genuinely a generalist on a technical team, and that is fine. Not every PM on a technical team needs to be a specialized technical PM.
How long should the full role differentiation exercise take with a leadership team?
Plan for 2-3 hours for the initial exercise covering 3-5 role types. Steps 1-4 (competency listing, role listing, weight assignment, and quadrant calculation) take about 90 minutes with a group of 3-5 PM leaders. Step 5 (profile card creation) takes 30-45 minutes. Steps 6-8 (validation, boundary rules, and socialization) happen over 1-2 weeks as you collect data and feedback. Do not try to compress the entire process into a single meeting. The validation step requires real work samples, and the socialization step requires time for people to review and respond thoughtfully.