Know
Can you explain how it changes a product decision?
Knowing the vocabulary matters, but recognition is not yet applied capability. RICE, SQL, Jira, Figma, interview frameworks, or AI tools are not substitutes for product judgment.
Capability diagnostic + routing system
Product Manager Skills
Strong PM skills are visible in decisions, not framework vocabulary. Use this map to understand each capability, practice it on realistic product problems, and identify the evidence you can actually show.
No readiness score. No seniority prediction. No account required.
What a PM skill actually is
Know the skill → practice the decision → show evidence
Practice
Can you apply it when evidence conflicts or constraints bite?
Use a realistic exercise, live product problem, or honest side project. Make the choice yourself before reading a worked answer, then compare your assumptions and trade-offs.
Evidence
Can another person inspect what you actually did?
Credible proof can be a decision, artifact, outcome, learning, or conflict story. It does not need to be a polished deck, and it should never claim metrics or ownership you did not have.
Beginner mode
Do not treat the skill map as an application prerequisite checklist
Foundational now
Build basic competence across discovery, framing, prioritization, product sense, metrics, strategy, execution, and influence. You do not need senior-level evidence in all eight before applying.
Deepen on the job
The same capabilities become harder with larger scope, conflicting stakeholders, weaker evidence, multiple teams, longer horizons, and more consequential trade-offs.
Context-specific depth
Deep SQL, APIs, infrastructure, ML/AI, pricing, growth experimentation, compliance context, or domain expertise can matter enormously in specific roles without becoming universal PM requirements.
PM capability check
Separate what you know, what you can do, and what you can prove
Assess the three states independently. Someone can understand a concept without applying it, practice it without strong career evidence, or have a real example that is still hard to explain. This is a development guide, not a validated psychometric assessment or hiring-readiness test.
0 of 8 skills fully assessed
Saved locally in this browser. No account and no PM score.
Optional. Choosing a focus changes recommendation priority only; it does not predict role fit or seniority.
How priority works
Without a focus skill, start with an earlier development gap before a later one: understanding → applied practice → clear evidence. This does not rank one PM capability as universally more important than another.
Customer / Product Discovery
Reduce uncertainty about users, problems, and product bets before the team commits more time or scope.
Decision: What uncertainty should we reduce before committing more product capacity?
Problem Framing
Turn messy signals into a decision-ready problem without smuggling a preferred feature into the definition.
Decision: What problem are we actually deciding to solve, and what is outside this decision?
Prioritization
Choose among competing opportunities under capacity, strategic, confidence, and risk constraints.
Decision: What gets capacity now, what waits, and what evidence could reverse the choice?
Product Sense
Choose a meaningful user and problem, generate credible options, evaluate trade-offs, and connect the solution direction to an outcome.
Decision: Which user/problem and product direction should we choose under incomplete evidence?
Metrics & Analytics
Choose meaningful outcome signals, diagnose movement, segment intelligently, and connect data to the next product decision.
Decision: What does success mean, what changed, and what product decision should follow?
Product Strategy
Choose a target, product advantage or strategic logic, meaningful bets, sequencing, and explicit non-goals.
Decision: Where should we place the product bet, and what will we deliberately not pursue?
Execution & Trade-offs
Move a product decision through delivery and launch while adapting scope, dependencies, risk, and sequencing as reality changes.
Decision: What scope, sequence, rollout, or risk decision best protects the intended outcome?
Communication & Influence
Make decisions legible, expose trade-offs, handle disagreement, and move people toward a choice without relying on formal authority.
Decision: How do we make a contested product decision clear enough for people to act on it?
Assess one capability completely to get a useful next action. You do not need to complete all eight.
PM capability example
Capture the decision, not just the artifact
Use this for one capability example. Capture what you decided, what evidence you used, which alternative lost, what you actually contributed, and what happened or what you learned. A large metric is not required; attributable reasoning is more important than borrowed scale.
Evidence honesty: a CraftUp exercise proves practice and learning, not professional experience. A side project can show judgment and initiative, but it should not be presented as employer work. Professional evidence should reflect your attributable contribution rather than a team result you cannot defend.
Your diagnostic and capability example are stored only in this browser until you clear them.
Capability → decision → evidence
What good looks like across eight PM capabilities
Each capability exists because it improves a distinct class of product decisions. Frameworks and tools can support the work, but the important part is the judgment: how the PM frames evidence, chooses among alternatives, handles uncertainty, and changes direction when facts change.
Customer / Product Discovery
Reduce uncertainty about users, problems, and product bets before the team commits more time or scope.
Decision enabled: What uncertainty should we reduce before committing more product capacity?
Customer / Product Discovery
Reduce uncertainty about users, problems, and product bets before the team commits more time or scope.
Decision enabled: What uncertainty should we reduce before committing more product capacity?
Know
Can you explain the decision logic?
Can you explain how discovery should change a product decision rather than merely produce interview notes?
Practice
Can you make the decision?
Can you separate requests from root problems, distinguish evidence from interpretation, and choose the next uncertainty to reduce?
Evidence
Can another person see how you made the call?
Can you show a real example where research or behavioral evidence changed the problem framing, priority, or product direction?
What strong behavior looks like
- Distinguishes a requested feature from the underlying user problem.
- Separates direct evidence, inference, assumptions, and unknowns.
- Recognizes repeated signals without treating one vivid anecdote as universal.
- Chooses research because it can change a decision, not to hit an interview quota.
Weak pattern
You can describe interviews you ran, but not what decision changed because of what you learned.
Credible proof can look like
- • Research synthesis that invalidated or narrowed an assumption.
- • Discovery memo showing evidence, uncertainty, and the resulting product decision.
- • A problem reframing supported by multiple evidence sources.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Discovery course →Build a repeatable discovery system from research question to product bet.ExerciseThree feature requests, one underlying problem →Practice turning conflicting requests into an evidence plan before seeing guidance.CaseFeature requests disagree. The workflow problem does not. →Inspect a worked discovery decision with knowns, assumptions, unknowns, and reversal evidence.ToolProblem Statement Generator →Turn evidence into a bounded problem statement after the problem is understood.InterviewDiscovery / Product Sense interview questions →See how discovery judgment appears inside Product Sense and case prompts.
Problem Framing
Turn messy signals into a decision-ready problem without smuggling a preferred feature into the definition.
Decision enabled: What problem are we actually deciding to solve, and what is outside this decision?
Problem Framing
Turn messy signals into a decision-ready problem without smuggling a preferred feature into the definition.
Decision enabled: What problem are we actually deciding to solve, and what is outside this decision?
Know
Can you explain the decision logic?
Can you explain the difference between a user problem, symptom, solution request, assumption, constraint, and success condition?
Practice
Can you make the decision?
Can you define user + context + problem + impact + evidence + decision boundary when the initial request is ambiguous?
Evidence
Can another person see how you made the call?
Can you show a real brief or decision where clearer framing prevented the team from building the wrong scope?
What strong behavior looks like
- Names the affected user or segment and the context where the problem appears.
- Separates problem from solution and makes the evidence explicit.
- Exposes important assumptions and unknowns instead of hiding them in requirements.
- Defines what is in and out of the current decision.
Weak pattern
Your problem statement is a feature request rewritten as a sentence, such as ‘users need a dashboard so they can…’.
Credible proof can look like
- • Problem statement that led to a smaller or different solution than originally requested.
- • Decision brief with evidence, assumptions, boundaries, and explicit non-goals.
- • Requirements artifact that traces scope back to a validated problem rather than a feature name.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Discovery course →Use discovery evidence to move from signal to opportunity and problem framing.ExerciseTurn ‘saved searches’ into a decision-ready requirement →Practice separating repeated user behavior from a preselected feature scope.CaseWorked discovery / root-problem case →Inspect how problem framing changes before solution selection.ToolProblem Statement Generator →Create a reusable problem artifact once the evidence and boundary are clear.
Prioritization
Choose among competing opportunities under capacity, strategic, confidence, and risk constraints.
Decision enabled: What gets capacity now, what waits, and what evidence could reverse the choice?
Prioritization
Choose among competing opportunities under capacity, strategic, confidence, and risk constraints.
Decision enabled: What gets capacity now, what waits, and what evidence could reverse the choice?
Know
Can you explain the decision logic?
Can you explain why prioritization is a decision under constraints rather than the output of RICE, MoSCoW, or another scoring formula?
Practice
Can you make the decision?
Can you compare credible alternatives, choose criteria that fit the decision, make opportunity cost explicit, and state what could reverse the choice?
Evidence
Can another person see how you made the call?
Can you show a real moment where you chose one opportunity over another and explain the evidence, trade-off, and work deliberately deferred?
What strong behavior looks like
- Chooses criteria before choosing the preferred option.
- Makes constraints, uncertainty, strategic fit, and opportunity cost visible.
- Uses frameworks as decision inputs rather than automatic answers.
- Can explain why the second-best option lost and what evidence would change the ranking.
Weak pattern
You feed weak guesses into a score, accept the highest number as the answer, and cannot defend the ranking when one input changes.
Credible proof can look like
- • Prioritization memo with alternatives, decision criteria, assumptions, and rejected work.
- • Roadmap change where new evidence caused an explicit re-ranking.
- • Decision record showing why a high-demand request was deferred.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Management Foundations →Strengthen the core product judgment behind prioritization and roadmap decisions.ExerciseChoose one onboarding bet with incomplete evidence →Make the decision yourself without turning uncertainty into fake precision.CaseOne onboarding bet, three plausible winners →Inspect criteria selection, opportunity cost, and reversal conditions in a worked example.ToolPrioritization tools →Use structured comparisons after defining the decision and evidence quality.InterviewPrioritization interview questions →Stress-test trade-off reasoning under interview constraints.
Product Sense
Choose a meaningful user and problem, generate credible options, evaluate trade-offs, and connect the solution direction to an outcome.
Decision enabled: Which user/problem and product direction should we choose under incomplete evidence?
Product Sense
Choose a meaningful user and problem, generate credible options, evaluate trade-offs, and connect the solution direction to an outcome.
Decision enabled: Which user/problem and product direction should we choose under incomplete evidence?
Know
Can you explain the decision logic?
Can you explain Product Sense as product judgment across user, problem, options, trade-offs, and outcomes rather than as an interview framework?
Practice
Can you make the decision?
Can you narrow an ambiguous product problem, generate more than one plausible direction, choose, and explain what you would learn next?
Evidence
Can another person see how you made the call?
Can you show a real product decision where your understanding of the user and problem shaped the solution direction and what was not built?
What strong behavior looks like
- Selects a user/problem before brainstorming features.
- Generates alternatives rather than defending the first idea.
- Balances usefulness, risk, constraints, and expected outcome.
- Keeps solution detail proportional to what is actually known.
Weak pattern
You jump from an ambiguous prompt to a feature brainstorm and call the longest feature list ‘customer centric’.
Credible proof can look like
- • Product brief showing the user/problem choice, alternatives, and product direction.
- • Prototype or concept decision with explicit trade-offs and success criteria.
- • A product decision where evidence caused you to reject an attractive idea.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Sense guide →Learn the reasoning pattern without treating it as a script.ExerciseImprove approvals for field supervisors →Choose the user, problem, direction, metric, and central trade-off yourself.CaseSearch conversion is fine. Discovery is still weak. →Inspect how a PM separates search performance from the broader discovery job.InterviewProduct Sense interview simulator →Use interview practice only after you can make the underlying product decision without a memorized script.
Metrics & Analytics
Choose meaningful outcome signals, diagnose movement, segment intelligently, and connect data to the next product decision.
Decision enabled: What does success mean, what changed, and what product decision should follow?
Metrics & Analytics
Choose meaningful outcome signals, diagnose movement, segment intelligently, and connect data to the next product decision.
Decision enabled: What does success mean, what changed, and what product decision should follow?
Know
Can you explain the decision logic?
Can you explain the difference between an outcome metric, leading or diagnostic signals, and guardrails, and why correlation alone does not prove a product mechanism?
Practice
Can you make the decision?
Can you diagnose a metric movement by cohort/segment, generate competing explanations, and choose what analysis or experiment changes the decision?
Evidence
Can another person see how you made the call?
Can you show a real metric tree, funnel/cohort analysis, or experiment readout that ended in a product decision rather than a dashboard update?
What strong behavior looks like
- Connects metrics to a plausible user/product mechanism.
- Uses cohorts and segments when aggregate movement can mislead.
- Distinguishes correlation, causal evidence, and unresolved uncertainty.
- Defines primary outcomes, diagnostics, and guardrails before interpreting results.
Weak pattern
You report top-line movement or know SQL, but cannot explain the mechanism, uncertainty, or decision that should follow.
Credible proof can look like
- • Metric tree tied to a product decision.
- • Funnel or retention diagnosis that changed priority or scope.
- • Experiment plan/readout with hypothesis, decision criterion, guardrails, interpretation, and stop/continue choice.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Metrics & Experiments →Go deeper on metric design, diagnosis, experimentation, and evidence quality.ExerciseFeature usage rose while retention fell →Separate adoption, retained value, cohort mix, and causal uncertainty.CaseFeature usage rose while retention fell →Inspect a worked measurement decision with conflicting signals and segmentation risk.ToolKPI Tree Builder →Turn an outcome into drivers and diagnostics before building a dashboard.InterviewMetrics interview simulator →Practice choosing and interpreting metrics under pressure.
Product Strategy
Choose a target, product advantage or strategic logic, meaningful bets, sequencing, and explicit non-goals.
Decision enabled: Where should we place the product bet, and what will we deliberately not pursue?
Product Strategy
Choose a target, product advantage or strategic logic, meaningful bets, sequencing, and explicit non-goals.
Decision enabled: Where should we place the product bet, and what will we deliberately not pursue?
Know
Can you explain the decision logic?
Can you explain why strategy requires choices, trade-offs, and non-goals rather than a vision statement or roadmap list?
Practice
Can you make the decision?
Can you choose among credible growth directions, state the objective, define what will not be pursued, and name assumptions that could change the strategy?
Evidence
Can another person see how you made the call?
Can you show a real strategic choice where your judgment changed focus, sequencing, target segment, or resource allocation?
What strong behavior looks like
- Names the target user/market and product objective before choosing initiatives.
- Connects product choices to user and business outcomes.
- Defines non-goals that make the strategy meaningfully selective.
- States assumptions, sequencing logic, and revision triggers.
Weak pattern
Your ‘strategy’ is a list such as improve onboarding, add AI, expand enterprise, and grow internationally, all at once.
Credible proof can look like
- • One-page strategy with target, rationale, bets, non-goals, assumptions, and revision triggers.
- • Portfolio-level trade-off showing why one direction was funded and another deferred.
- • A strategy update prompted by evidence about market, user, product, or company capability.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Strategy hub →Deepen strategic choices, bets, positioning, and the connection to product execution.ExerciseChoose one growth direction for a B2B product →Make a real strategic choice instead of funding three directions at once.CaseThree growth directions, one strategy →Inspect target selection, non-goals, sequencing, and reversal evidence.ToolProduct Strategy One-Pager →Capture a strategy after the choices are explicit.InterviewStrategy interview simulator →Practice strategic choices under ambiguous interview prompts.
Execution & Trade-offs
Move a product decision through delivery and launch while adapting scope, dependencies, risk, and sequencing as reality changes.
Decision enabled: What scope, sequence, rollout, or risk decision best protects the intended outcome?
Execution & Trade-offs
Move a product decision through delivery and launch while adapting scope, dependencies, risk, and sequencing as reality changes.
Decision enabled: What scope, sequence, rollout, or risk decision best protects the intended outcome?
Know
Can you explain the decision logic?
Can you explain why PM execution is protecting the intended outcome under changing constraints, not simply tracking tickets or shipping the original scope on time?
Practice
Can you make the decision?
Can you narrow scope, isolate launch-critical work, expose dependency risk, and decide when to roll back, stage, delay, or continue?
Evidence
Can another person see how you made the call?
Can you show a real scope, dependency, rollout, or launch decision where you accepted a trade-off to protect user value or learning?
What strong behavior looks like
- Separates launch-critical from optional scope.
- Surfaces dependencies and uncertainty before they become hidden commitments.
- Uses reversibility and downside asymmetry when making delivery decisions.
- Treats launch as a measurement and learning point, not the end of the job.
Weak pattern
You equate execution with keeping Jira current and preserving every committed requirement even after assumptions, cost, or risk change.
Credible proof can look like
- • Scope decision showing what was cut, why, and which outcome was protected.
- • Launch plan or incident decision with rollout/rollback criteria and guardrails.
- • Dependency re-sequencing that preserved learning or value despite a blocked path.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Management Foundations →Build the fundamental decision chain from problem through delivery, outcome, and learning.ExerciseCheckout completion drops after a release →Make a fast containment decision with measurement uncertainty and reversible risk.CaseLaunch now, delay, or reduce scope? →Inspect staged rollout, scope isolation, and explicit pause criteria.ToolProduct Launch Plan Template →Turn the selected rollout and risk decisions into a launch artifact.InterviewExecution interview simulator →Practice execution judgment rather than project-status narration.
Communication & Influence
Make decisions legible, expose trade-offs, handle disagreement, and move people toward a choice without relying on formal authority.
Decision enabled: How do we make a contested product decision clear enough for people to act on it?
Communication & Influence
Make decisions legible, expose trade-offs, handle disagreement, and move people toward a choice without relying on formal authority.
Decision enabled: How do we make a contested product decision clear enough for people to act on it?
Know
Can you explain the decision logic?
Can you explain why PM communication is decision clarity and influence, not presentation polish, meeting volume, or generic stakeholder friendliness?
Practice
Can you make the decision?
Can you frame one contested decision for different stakeholders, preserve the facts, surface dissent, and make ownership plus revisit triggers clear?
Evidence
Can another person see how you made the call?
Can you show a real disagreement or ambiguous decision where your framing, evidence, or facilitation changed what the group did next?
What strong behavior looks like
- Frames the decision, evidence, alternatives, trade-off, owner, and next step clearly.
- Adapts depth and language to the audience without changing the underlying rationale.
- Makes disagreement inspectable instead of forcing superficial consensus.
- Influences through product judgment and clarity rather than title or meeting volume.
Weak pattern
You describe stakeholder management as running more meetings, keeping everyone happy, or sending status updates with no clear decision.
Credible proof can look like
- • Decision memo that aligned functions around a difficult trade-off.
- • Conflict story where evidence changed the recommendation or escalation path.
- • Executive/team communication showing the same decision at different levels of detail.
The artifact supports the example. The capability is the judgment, contribution, outcome, and learning that another person can follow.
What to do next
LearnProduct Manager responsibilities →See where influence, decision ownership, and cross-functional accountability appear in real PM work.ExerciseSales, Engineering, and Growth all want the next six weeks →Practice a contested cross-functional decision with one capacity window and competing objectives.ToolStakeholder Map Builder →Map influence and decision context without reducing stakeholder work to a contact list.InterviewBehavioral interview questions →Translate influence evidence into concrete stories without generic leadership claims.
Local data controls
The diagnostic and capability example use browser local storage so you can return to them. No answer is sent to a CraftUp assessment service by this component.
Skills by career stage
Seniority changes scope and ambiguity, not the names of the skills
These are generalized patterns, not a universal leveling rubric. Company titles and decision rights vary significantly.
Entry / APM
Capability focus: Build basic competence in bounded product decisions: understand a problem, compare options, reason with simple metrics, communicate the choice, and follow work through delivery and learning.
Credible evidence: One or two honestly scoped decisions are more useful than claiming mastery across every skill. A project, internship, adjacent-role example, or exercise can demonstrate the reasoning if its limits are explicit.
See the APM path →Product Manager
Capability focus: Apply the same skills independently across a product/problem area: choose priorities, connect discovery to outcomes, manage execution trade-offs, and adapt when evidence changes.
Credible evidence: Show an end-to-end product bet with context, evidence, alternatives, decision, trade-off, outcome or learning, and your actual contribution.
Review the PM role →Senior PM
Capability focus: The techniques do not become different; the ambiguity and scope do. Strong Senior PM evidence shows harder prioritization, broader strategy, cross-team dependencies, and influence across more consequential decisions.
Credible evidence: Show where your judgment changed direction, reduced product or organizational risk, or improved decision quality beyond one feature.
See Senior PM scope →Advanced IC / Principal
Capability focus: Increase leverage across teams, product systems, and strategic choices without inventing a separate skill taxonomy. Advanced capability means wider scope, harder ambiguity, and better decisions around you.
Credible evidence: Show cross-team leverage: portfolio trade-offs, reusable decision systems, strategic influence, or technical/product-system judgment that improved more than one team’s work.
Explore Principal / advanced IC →Career switcher mode
Transfer evidence; do not transfer job-title assumptions
Adjacent backgrounds can create real PM evidence. The patterns below are hypotheses to audit against the work you actually did, not stereotypes about every engineer, designer, Project Manager, or Product Owner.
Engineer → PM
Possible transfer: Technical trade-offs, systems thinking, delivery constraints, reliability and execution context often transfer well.
Audit carefully: Do not assume technical feasibility equals product priority. Discovery, user/market judgment, prioritization, and product strategy may need more deliberate practice depending on your prior role.
Open the transition guide →Designer → PM
Possible transfer: Research, problem framing, user understanding, interaction trade-offs, and qualitative synthesis may transfer strongly.
Audit carefully: Build evidence around opportunity cost, business/metric ownership, broader prioritization, and decisions beyond the experience layer where those were not previously yours.
Open the transition guide →Project Manager → PM
Possible transfer: Coordination, risk, sequencing, dependency management, and cross-functional delivery can be valuable foundations.
Audit carefully: Product work adds problem selection, user/value judgment, outcome ownership, and deciding what should not be built, not simply owning a different project plan.
Open the transition guide →Product Owner → PM
Possible transfer: Backlog decisions, delivery context, acceptance judgment, and close engineering collaboration can transfer, depending on how the PO role is defined.
Audit carefully: Audit whether you have broader discovery, market/business context, strategy, outcome ownership, and longer-horizon prioritization evidence rather than assuming the titles are interchangeable.
Open the transition guide →Capability → proof → hiring communication
Use a different surface once the problem is packaging or interview performance
Portfolio
Package enough evidence for another person to inspect
A skill is capability. Evidence is proof you used it. A portfolio packages selected evidence into a decision story. Never present a CraftUp exercise or case study as personal work.
Build PM portfolio evidence →Resume
Compress evidence without inventing ownership or metrics
When you have evidence but struggle to communicate it concisely, use the Resume Evidence Lab to surface context, judgment, trade-offs, contribution, outcome, and learning from facts you actually supplied.
Open the Resume Evidence Lab →Interview
Practice combinations of skills under hiring constraints
Product Sense combines discovery, product judgment and prioritization. Metrics combines analytics and causal reasoning. Behavioral questions often expose influence, ownership, conflict, and learning.
Browse PM interview questions →Want live interview-style reps rather than question discovery? Use the Product Manager Interview Simulator. Case Studies remain for inspecting worked reasoning; PM Exercises remain for making the decision yourself first.
Technical and AI depth
There is no universal coding or ML bar for Product Managers
Technical PM contexts
Most PMs benefit from understanding technical constraints well enough to reason with engineering. Platform, API, infrastructure, data, and developer products can require much deeper system fluency. That does not mean every PM must code.
Technical Product Manager guide →AI: using tools vs managing AI products
Using AI to speed up PM work is different from managing an AI-enabled product, where evaluation, failure handling, data, cost/latency, human review, and model capability boundaries can become product decisions.
Choose one next step
Do not collect eight learning plans at once
Use the diagnostic to find the capability state that actually blocks your current work or target role. Learn the minimum useful model, practice on a decision, keep the evidence, then move to the next gap.
Practice
PM Exercises
Make realistic product decisions before revealing the reasoning guide.
Inspect
PM Case Studies
Inspect evidence, alternatives, trade-offs, metrics, uncertainty, and reversal conditions.
Sequence
PM Learning Path
Choose the order in which to learn and practice capabilities instead of browsing randomly.