How to use this encyclopedia
This is a reference page, not a teaching page. Each framework gets a concise card: what it is, when to use it, when it fails, and how to apply it. For deep coverage of specific frameworks, see the topic pages that use them (linked in each card). This page exists so you can quickly look up a framework, compare alternatives, and choose the right tool for your situation.
A framework is a thinking tool, not a decision machine. No framework replaces judgment. The best PMs use frameworks to structure their thinking, then apply judgment to interpret the results. The worst PMs hide behind frameworks to avoid making decisions: "RICE says we should build Feature X" is not a decision — it's a delegation of decision-making to a formula. Use frameworks as inputs, not as oracles.
Prioritization frameworks
RICE Scoring Framework
Use when: you need a structured, quantitative prioritization for a large backlog.
Reach × Impact × Confidence ÷ Effort = RICE score. Reach: how many users will this affect in a given time period? Impact: how much will it affect each user? (0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive.) Confidence: how sure are you about these estimates? (100% = high, 80% = medium, 50% = low.) Effort: person-months of work.
When it fails: When Reach or Impact estimates are guesses rather than data. When strategic importance doesn't correlate with Reach (a feature for 10 enterprise customers can be higher priority than one for 10,000 free users). When the team games the numbers to justify a preferred option.
ICE Scoring Framework
Use when: you need a quick, lightweight prioritization — faster than RICE.
Impact (1-10) × Confidence (1-10) × Ease (1-10). Simpler than RICE: no need to estimate Reach separately (it's folded into Impact). Good for growth experiments where you're comparing many small ideas quickly. Less rigorous than RICE — the 1-10 scales are subjective and harder to calibrate across raters.
MoSCoW Framework
Use when: categorizing features for a release rather than ranking them numerically.
Must have (the release is useless without these), Should have (important but not critical for this release), Could have (nice-to-have if time allows), Won't have (explicitly out of scope). Works well for fixed-scope releases where you need to communicate what's in and what's out. Fails when everything gets labeled "Must have" — which happens if the PM doesn't enforce discipline.
Kano Model Framework
Use when: understanding which features delight vs. which are expected.
Features fall into categories: Must-be (expected, causes dissatisfaction if missing but doesn't delight if present — e.g., a login page). Performance (more is better linearly — e.g., loading speed). Attractive (unexpected delighters — causes satisfaction if present, no dissatisfaction if absent). Indifferent (users don't care either way). Reverse (presence causes dissatisfaction). The Kano model helps you balance: fulfill Must-be features first, then invest in a few Attractive features that differentiate. Don't over-invest in Performance features past the "good enough" threshold.
Opportunity Scoring (Ulwick) Framework
Use when: identifying underserved needs using JTBD-style research.
Ask customers: "How important is [outcome]?" and "How satisfied are you with current solutions?" Plot importance vs. satisfaction. High importance + low satisfaction = underserved opportunities (your sweet spot). High importance + high satisfaction = table stakes (must match, hard to differentiate). Low importance = ignore regardless of satisfaction. The framework is powerful because it uses customer-defined importance rather than PM assumptions.
Cost of Delay Framework
Use when: deciding which project to start first when resources are limited.
For each project, estimate: what's the cost per week of NOT doing this? Revenue lost? Customers churned? Competitive ground conceded? Then: WSJF (Weighted Shortest Job First) = Cost of Delay ÷ Job Duration. Prioritize the project with the highest WSJF — it has the highest value-per-unit-time. This framework naturally prioritizes urgent, high-value, quick projects over large, slow, lower-value ones.
Metrics frameworks
AARRR (Pirate Metrics) Framework
Use when: mapping the full user lifecycle for a growth-focused product.
Acquisition (how users find you) → Activation (first "aha" moment) → Retention (users come back) → Revenue (users pay) → Referral (users bring others). Each stage has metrics. Find the weakest stage and fix it — that's your growth bottleneck. Don't optimize referral if activation is broken.
HEART Framework Framework
Use when: measuring user experience quality, not just business outcomes.
Happiness (satisfaction, NPS), Engagement (frequency, depth of use), Adoption (new users, feature uptake), Retention (churn, return rate), Task Success (completion rate, time-on-task, error rate). For each dimension, define: Goals (what you want to achieve), Signals (user behaviors that indicate progress), Metrics (measurable numbers you track). HEART is particularly useful for products where business metrics (revenue) are a lagging indicator of UX quality.
North Star Metric Framework
Use when: aligning the entire company around one metric that captures value delivered.
The North Star Metric is the single metric that best represents the value your product delivers to customers. Spotify: time spent listening. Airbnb: nights booked. Slack: daily active teams. The NSM should: reflect customer value (not just revenue), be a leading indicator of long-term success, and be influenceable by the product team. Support it with 3-5 input metrics that the team directly controls. The NSM is the "what"; input metrics are the "how."
Strategy and discovery frameworks
Jobs-to-be-Done (JTBD) Framework
Use when: understanding why customers hire your product — the underlying motivation beyond the feature request.
Customers don't buy products — they "hire" them to get a job done. The "job" is the progress a customer wants to make in a particular circumstance. Format: "When [situation], I want to [motivation], so I can [expected outcome]." Example: "When I'm commuting to work, I want something to pass the time, so I can arrive feeling entertained rather than bored." This reveals that the competitor to a podcast app isn't just other podcast apps — it's music, audiobooks, social media, and staring out the window.
Value Proposition Canvas Framework
Use when: mapping how your product's features address customer needs.
Two sides: Customer Profile (jobs, pains, gains) and Value Map (products/services, pain relievers, gain creators). The canvas works when the Value Map addresses the Customer Profile: your pain relievers match their pains, your gain creators match their desired gains. Gaps reveal product opportunities. Mismatches reveal positioning problems (you're solving pains the customer doesn't have).
Lean Canvas Framework
Use when: quickly mapping a business model for a new product or startup.
One-page business model: Problem, Solution, Key Metrics, Unique Value Proposition, Unfair Advantage, Channels, Customer Segments, Cost Structure, Revenue Streams. Fill it out in 20 minutes, not 20 days. The value is in what you can't fill out — those are your biggest unknowns. Use it as a conversation tool with co-founders and early team members, not as a planning document.
When to use which framework
RICE → Opportunity Scoring → Cost of Delay
ICE → MoSCoW → Impact/Effort 2x2
JTBD → Kano Model → Value Proposition Canvas
North Star + Input Metrics → HEART → AARRR
Lean Canvas → JTBD → Opportunity Scoring
AARRR → ICE (for experiment prioritization) → North Star
Common mistake
Using a framework because you've heard of it, not because it fits the problem. RICE is overkill for a 3-item backlog. JTBD is unnecessary when you already understand customer needs. The best framework is the simplest one that structures the decision. If a 2x2 matrix on a whiteboard gives you the answer, you don't need a spreadsheet with weighted scores.