优先级的艺术
掌握十种框架以及挑选合适框架的判断力 —— 配合五个实操模拟器进行练习。
Explainer
优先级排序不是产出一个客观正确的清单。它是关于价值、信心、时机与约束的一场结构化对话。框架是一种「迫使诚实」的功能 —— 让隐含假设显露出来,把分歧摊到明面上。错误的问题是「哪个框架最好」。正确的问题是「哪个框架能逼我们这支具体的团队去面对我们一向回避的东西」。
为什么会有优先级框架
每个优先级框架都是在四件事之间权衡的启发式:价值、信心、努力、时间。不同框架把不同的取舍摆到台前。RICE 突出信心;Kano 突出情绪回报;WSJF 突出时间;Value/Effort 突出杠杆比。适合你团队的框架,是那个迫使你们就你们一直回避的话题展开争论的框架。
- 框架揭露分歧,不解决分歧。
- 大家都不假思索就同意的分数是可疑的 —— 通常没有人在信心上诚实。
- 对同一个 backlog 用多个框架,关注那些得分明显不一致的条目 —— 那些最有意思。
RICE:Reach × Impact × Confidence ÷ Effort
Intercom 的 RICE 是现代 PM 中最常见的打分框架。Reach 是单位时间内受影响的用户数或事件数。Impact 是粗粒度乘子(Massive=3,High=2,Medium=1,Low=0.5,Minimal=0.25)。Confidence 是百分比,用来给推测性分数打折扣。Effort 是人月。这个分数在同一个 backlog 中跨倡议可比,即使它们在产品的差异很大的区域。
- Reach 必须是带时间段的真实数 —— 「每季度 5,000 用户」,而不是「很多」。
- Impact 故意粗粒度 —— 精度是假的;离散桶迫使对话。
- Confidence 必须反映证据,而不是热情 —— 50% 是无支撑想法的诚实默认值。
- Effort 包含设计、工程、QA、沟通和下线支持 —— 不仅是写代码。
ICE:Impact × Confidence × Ease
Sean Ellis 的 ICE 是 RICE 的快速表亲。每个输入是 1-10 的分数;乘积就是排序。在高吞吐的实验 backlog(增长实验、转化测试)上用 ICE,因为对每条用 RICE 打分会烧掉一周。代价是:没有 Reach 分量,所以 ICE 偏向「容易赢」,而对覆盖广但建造较难的系统性改进不利。
- ICE 更适合实验 backlog,而非功能 backlog。
- Ease 是 effort 的反面 —— Ease 越高,越快上线。
- 凭直觉打分,然后用真实结果校准;每月重新校准。
- 搭配一个独立的「主题」标签,以免不小心把战略主题优化掉。
价值 vs 努力(2×2 矩阵)
最简单的可视化优先级工具。把每条放在「价值(对目标的影响)对努力」的 2×2 上。象限:quick wins(高价值低努力)、big bets(高价值高努力)、fill-ins(低价值低努力)、thankless(低价值高努力,丢弃)。最适合 30 分钟的对齐研讨会 —— 对话本身才是交付物,矩阵不是。
- 强迫团队为每条放置位置;打平意味着定义模糊。
- 用便签或虚拟看板;公开辩论位置。
- Quick wins 先发;big bets 排队;fill-ins 填补产能;thankless 死。
- 别过度工程化 —— 这是为了清晰,不是为了追踪。
Kano 模型:必备、性能、惊喜
Noriaki Kano 的模型按「功能存在与用户满意度的关系」对功能分类。必备(must-have)在的时候看不见、不在的时候是灾难(登录可用、数据持久化)。性能(performance)是线性关系 —— 更多就更好(加载更快、容量更大)。惊喜(delighter)是不在不痛、在了就生爱的意外正面;反向(reverse)是出现就让人讨厌。
- 用「功能型/反功能型」一对问题对每个功能分类。
- 必备就是氧气 —— 必要,但不构成差异化。
- 性能是路线图主体;选择满意度曲线最陡峭的那些。
- 惊喜会褪色;今天的惊喜是明天的必备(参考 Uber 的「司机正在过来」地图)。
MoSCoW:Must / Should / Could / Won't
MoSCoW 更像是一种发布范围工具,而不是路线图工具。Must-have 对该次发布不可让步。Should-have 重要但非关键。Could-have 锦上添花。Won't-have 显式地不在范围内 —— 命名是为了防止 scope creep。在固定截止时间(合规、上线)的语境里很有用,问题是「这次发布里有什么」,而不是「下一步该做什么」。
- 多数团队 Must 太多 —— 用「我们会为发这个推迟一周上线吗?」来校准。
- Won't-have 是最被忽视的类别;明列排除项可减少 scope creep。
- 每次发布重新分类,不要让它变成静态文档。
- 搭配一个日期;没有日期的 MoSCoW 只是改了名字的 wishlist。
WSJF:Weighted Shortest Job First
WSJF(来自 SAFe / 精益)按 Cost of Delay 除以 Job Size 排序。Cost of Delay = User-Business Value + Time Criticality + Risk Reduction / Opportunity Enablement。在「时机」很重要的时候出彩 —— 监管截止日期、市场窗口、阻塞他人的依赖。把它用在「何时」与「做什么」同样重要的 backlog 上。
WSJF = (User-Business Value + Time Criticality + Risk Reduction & Opportunity Enablement) / Job Size
- 对每个分量使用 1/2/3/5/8/13 的类斐波那契尺度。
- Time criticality 捕捉衰减:等得越久价值掉得越多。
- Risk reduction / opportunity enablement 捕捉解锁其他工作的二阶价值。
- WSJF 高的先做。出乎意料地常见:小工作配上高 time criticality 会战胜大赌注。
Cost of Delay
Cost of Delay(Don Reinertsen)是因为没上线而每单位时间损失的经济价值。它是 WSJF 的推广,是财务在场时最严谨的视角。CoD/周 × 延误周数 = 失去的价值。当你需要用美元(而不是感觉)来论证招聘、并行或砍范围时,极有用。
- 用区间估,不要用点 —— 「每周 $50-150k」是诚实的;「$73,520」是表演。
- 考虑非线性衰减:发布窗口、监管截止日、爆款时刻。
- 搭配团队产能,看看并行是否真减少总 CoD,还是只是把每个项目拉长。
- Reinertsen:「如果你只能量化一件事,就量化 Cost of Delay。」
Stack ranking
最简单的框架:把整个 backlog 摊开,强制从 1 到 N 排序。不允许并列。纪律就在分歧里:如果两项「并列第三」,团队在回避取舍。Stack ranking 强迫做出取舍。适合作为 RICE/ICE/Kano 之后的最终一关 —— 人来核对分数所暗示的排序与直觉,把打错分的暴露出来。
- 把 backlog 打印出来,用墙物理排序 —— 空间布局会暴露薄弱的理由。
- 卡在并列上时问:「如果我下季度只能上其中一个,选哪个?」
- 用作最终一关,不要当作唯一的一关。
Buy a Feature
Luke Hohmann 的协作游戏:给每位干系人一笔固定的虚拟货币,展示一份按 effort 定价的功能菜单,让他们「买」最有价值的那些 —— 包括拼钱买贵的。它揭示真实偏好、暴露联盟、把稀缺感变得具体。
- 最适合面向客户的优先级会议(顾问委员会、design partner 计划)。
- 凑钱行为是最有趣的信号 —— 干系人之间的联盟揭示对齐情况。
- 别把结果当字面路线图;当作对需求强度的发现。
- 变体:「Pay for a Feature」用打折套餐测试 packaging 假设。
Opportunity Scoring(ODI)
Tony Ulwick 的结果驱动打分法:对每个期望结果(而非功能),让用户对重要性与当前满意度各打 1-10 分。Opportunity = Importance + max(0, Importance − Satisfaction)。机会高的结果(≥12)是「未被满足」;机会低的结果(<10)是过度满足或饱和。让投资走向用户在意而市场未满足的结果。
Opportunity = Importance + max(0, Importance − Satisfaction)
- 结果必须是与方案无关的陈述(「最小化识别重复项的时间」)。
- 在目标 segment 中调研 n≥100 个用户以得到稳定分数。
- 避免对不实际做该 job 的用户调研 —— 不相关数据稀释信号。
- 每年重新调研;饱和度会随市场演化而漂移。
Theme scoring
当 backlog 有 200 条时,挨个打分是浪费精力。Theme scoring 把项目卷入 5-10 个战略主题(如「缩短首次价值时间」「向中型市场扩张」「平台稳定性」),给主题打分,按主题分配产能。主题内,团队做战术取舍。最适合有战略主题、且小赌注很多的产品组织。
- 按战略对齐 + 可度量的结果价值给主题打分,而非按功能层级打分。
- 按主题分配产能(如 50% 稳定性、30% 增长、20% 实验)。
- 在主题内,用 RICE 或 ICE 做战术排序。
- 每季度与领导层重平衡主题;战术选择留给团队。
把信心当作一等公民的分数
PM 优先级排序中最被低估的维度,就是诚实的信心。证据弱的「巨型想法」不应默认压过证据明确、需求清晰的小想法。信心防止推测性的 reach 与 impact 主导路线图。让它显式、贴上证据标签、定期重访。
- 用证据锚定信心层级:100%(数据已验证)、80%(定性 + 领先指标)、50%(访谈支持但无数据)、30%(知情假设)。
- 为每一个信心分数附上证据标签。
- 在每次路线图复盘时重访并调整信心。
- 信心下降时,条目可以下移 —— 这本身就是目的。
选对框架
把框架与决策匹配。新产品 backlog,赌注大小不一?RICE。增长实验 backlog?ICE。快速对齐研讨?Value/Effort。干系人需求会议?Buy a Feature。带截止日期的发布范围?MoSCoW。带依赖的时间敏感 backlog?WSJF。庞大成熟的 backlog?Theme scoring。你最先想到的那个框架,泄露了你面对的决策类型 —— 以及你练过的纪律。
Framework atlas
Reference cards for each method in this mission
Expand a card for when to deploy it, misuse patterns, sequencing guidance, and (where relevant) shorthand formulas.
Quantitative scoring · Sean McBride at Intercom (2017)RICE(RICE)
Reach × Impact × Confidence / Effort. The most common cross-functional scoring framework.
RICE = (Reach × Impact × Confidence%) / Effort
When to use
- Roadmap candidate backlog with mixed bet sizes.
- Cross-team prioritization where transparency matters.
- When confidence varies wildly across items.
When not to
- Pure experiment backlogs (use ICE, faster cycle).
- When all items are within the same theme (RICE noise > signal).
How to apply
- Estimate Reach as a number per period (users, events, or sessions).
- Pick Impact from a coarse scale: Massive=3, High=2, Medium=1, Low=0.5, Minimal=0.25.
- Set Confidence honestly with an evidence tag (100/80/50/30%).
- Estimate Effort in person-months across all functions.
- Compute the score; rank descending; argue about top vs bottom of ties.
- Reach written as 'all users' — meaningless without a time period.
- Confidence inflated to win the comparison.
- Effort that excludes design, ops, comms, and ramp-down.
Quantitative scoring · Sean Ellis (popularized through GrowthHackers)ICE(ICE)
Impact × Confidence × Ease, each on a 1-10 scale. Lightweight scoring for high-volume experiment backlogs.
ICE = Impact × Confidence × Ease
When to use
- Growth experiment backlogs.
- When you need a score in <2 minutes per item.
- Backlogs where Reach is roughly equal across items.
When not to
- Roadmap-level prioritization with mixed bet sizes.
- Cross-team trade-offs (RICE's transparency helps more here).
How to apply
- Score Impact (1-10): expected lift on the target metric.
- Score Confidence (1-10): evidence quality.
- Score Ease (1-10): inverse effort.
- Rank by product; calibrate weekly against actual experiment outcomes.
- Same person scoring all three components — biased.
- Never recalibrating against actual outcomes.
Visual prioritization · Lean / agile workshopsValue vs Effort 2×2
Simple 2×2 matrix plotting items by value and effort to surface quick wins, big bets, fill-ins, and items to drop.
When to use
- Quick alignment in a 30-minute workshop.
- Sanity-checking a RICE-ordered list visually.
When not to
- When you need numerical comparability across many items.
How to apply
- Define the value dimension explicitly (revenue impact? activation lift? NSM movement?).
- Plot every item with the team co-present.
- Cluster into quick wins (DO), big bets (PLAN), fill-ins (FILL), thankless (DROP).
- Sequence quick wins immediately; scope big bets formally.
- Letting 'value' stay vague — produces a useless map.
- Skipping the DROP quadrant — it's the most valuable category.
Customer satisfaction · Noriaki Kano (1984)Kano Model
Classifies features by the relationship between presence and satisfaction: Must-Have, Performance, Delighter, Indifferent, Reverse.
When to use
- Designing a tier or plan structure.
- Detecting under-investment in basics or over-investment in delighters.
When not to
- Highly novel categories where users can't classify yet.
How to apply
- List candidate features.
- For each, ask users a functional and dysfunctional question pair (how would you feel if this feature existed / didn't exist?).
- Classify each feature by the response pattern.
- Re-score annually as delighters age into must-haves.
- Treating Kano as a static taxonomy instead of a moving target.
- Surveying customers who don't yet know the feature category.
Release scoping · Dai Clegg / DSDM (1990s)MoSCoW(MoSCoW)
Must-have, Should-have, Could-have, Won't-have-this-time. Release-scoping tool for fixed-deadline contexts.
When to use
- Fixed-date launches (regulatory, partner integrations, conferences).
- Releases with strict scope boundaries.
When not to
- Continuous-delivery products without releases as a unit.
How to apply
- List every candidate item for the release.
- Categorize as Must / Should / Could / Won't.
- Validate: would you delay the release a week to land each Must? If not, demote.
- Publish the Won't list to set expectations explicitly.
- Over-Must-ing under stakeholder pressure.
- Treating Won't as a deferral list instead of an exclusion list.
Time-sensitive scoring · SAFe / Don ReinertsenWSJF(WSJF)
Weighted Shortest Job First: Cost of Delay divided by Job Size. Prioritizes high-CoD short jobs first.
WSJF = (User-Business Value + Time Criticality + Risk Reduction & Opportunity Enablement) / Job Size
When to use
- Backlogs where time-to-value or sequencing matters.
- Dependency-heavy programs where unblocking work has compounding value.
When not to
- Pure feature backlogs without time pressure.
How to apply
- Score each component on a Fibonacci-like scale: 1, 2, 3, 5, 8, 13.
- Sum the value components; divide by job size.
- Sequence highest WSJF first.
- Confusing Job Size with story points — Job Size includes dependency unblocking.
- Ignoring time criticality decay.
Economic prioritization · Don ReinertsenCost of Delay
The economic value lost per unit time by not shipping. Quantifies the urgency case in dollars.
When to use
- Cross-team capacity allocation arguments.
- Hiring decisions ('how much will the second engineer save us per month?').
- When finance partners want a dollar-denominated case.
When not to
- Early-stage products without revenue mechanics.
How to apply
- Identify the value the project will create (annual revenue, retention dollars, support hours saved).
- Estimate value-per-week if shipped today vs in 13 weeks.
- Account for non-linear decay (launch windows, deadlines).
- Express as a range; communicate to stakeholders weekly.
Forced-choice ordering · Industry-wide practiceStack Ranking
Force-rank the entire backlog 1..N with no ties allowed. Surfaces hidden disagreements that scored frameworks miss.
When to use
- Final pass after RICE/ICE has produced a candidate order.
- Small backlogs (<30 items).
When not to
- Backlogs of 100+ items — use theme scoring first.
How to apply
- List all items.
- Force-rank with no ties.
- When stuck, ask 'if we could ship only one, which?'
- Reconcile against framework scores; investigate any large divergences.
Collaborative · Luke HohmannBuy a Feature
Stakeholders allocate fake currency to features priced by effort. Pooling and trading reveal demand intensity and coalitions.
When to use
- Customer advisory boards.
- Internal alignment workshops with multiple competing priorities.
When not to
- Solo PM scoring — Buy a Feature requires multiple participants.
How to apply
- Price each feature at 1-3 times its effort proportional cost.
- Give each participant a budget that can buy ~1/3 of the menu.
- Run a 30-45 minute session; allow pooling.
- Debrief on why pooling happened; that's the strategic signal.
Outcome-based scoring · Tony Ulwick / StrategynOpportunity Scoring (ODI)
Score outcomes by importance and current satisfaction; opportunity = importance + max(0, importance − satisfaction).
Opportunity = Importance + max(0, Importance − Satisfaction)
When to use
- Mature markets with well-understood jobs.
- Roadmap arbitration in a saturated category.
When not to
- Brand-new categories where users can't articulate the job yet.
How to apply
- Decompose the job into outcome statements.
- Survey users (n≥100) on importance and satisfaction.
- Compute opportunity score per outcome.
- Prioritize outcomes with score ≥ 12 as under-served.
Personal triage · Dwight D. EisenhowerEisenhower Matrix
Urgent vs Important 2×2 for personal task triage. Useful for managing the PM's own workload, not for product prioritization at scale.
When to use
- Personal weekly triage of inbound asks.
- Distinguishing reactive support from strategic work.
When not to
- Roadmap prioritization — 'important' is too vague at scale.
How to apply
- List all open asks/tasks.
- Tag each: urgent or not; important or not.
- Triage: do, schedule, delegate, drop.
Product Psychology
Cognitive biases that distort product decisions
Confidence Inflation
Scorers inflate confidence to ensure their preferred items rank highly.
Product Risk
Speculative bets dominate the roadmap because nobody will admit a 30% confidence score.
Research Countermove
Tag every confidence score with the specific evidence behind it. Audit retroactively: did 80%-confidence items actually hit?
Effort Sandbagging
Engineers overestimate effort on items they don't want to do; underestimate on items they want to ship.
Product Risk
Roadmaps reflect engineering preferences disguised as effort scores.
Research Countermove
Track estimated vs actual effort over time per scorer; calibrate against history; consider a second estimator.
Reach Hallucination
Optimistic Reach estimates because nobody fact-checks the user counts.
Product Risk
Big-feeling features dominate over targeted features that are genuinely more impactful.
Research Countermove
Pull reach from analytics, not hopes. If the segment can't be quantified, set Reach = 0 and force the team to instrument first.
HiPPO Effect
Highest Paid Person's Opinion overrides scoring frameworks.
Product Risk
Frameworks become rationalization for predetermined exec preferences.
Research Countermove
Score blind first; reveal to leadership only after the team has converged. Disagreements with leadership become explicit conversations, not silent overrides.
Organizational anti-patterns
When ceremonies look like rigor but aren't
Score Then Ignore
Team produces a beautifully scored RICE sheet, then ships in the order leadership prefers anyway.
The framework is performative; real authority is elsewhere.
Either commit to the score or admit the framework is advisory. Performative scoring corrodes trust faster than honest political prioritization.
All Confidence at 80%
Every item has confidence 70-90%; the lever is never used.
Confidence below 50% feels like an admission of failure; nobody wants to write it down.
Define explicit confidence anchors (with examples). Reward calibration over confidence.
Effort Without Capacity Check
Top-ranked RICE items add up to 18 person-months in a 3-month quarter; team commits anyway.
Prioritization and capacity planning live in different docs.
After ranking, draw the line at actual capacity. Items below the line are explicit not-doing; their existence is information for next quarter.
One Framework Forever
Team uses RICE for everything regardless of decision type.
Cargo-culting; nobody on the team has tried the alternatives.
Use at least three frameworks across the year. Notice which one each kind of decision gravitates toward.
Resurrection Backlog
Items that lost prioritization three quarters ago keep returning, slightly rebranded, against the same evidence.
Stakeholders feel unheard; the team has no public record of why items were declined.
Maintain a public 'declined items log' with the reason and the evidence threshold for revisiting. Items can return only when the threshold is met.
Worked examples
Walkthroughs translated from real trade-off rooms
Walking through a real RICE comparison
A B2B SaaS team is comparing two roadmap candidates: 'Onboarding checklist' and 'Bulk admin invite flow'.
- Onboarding checklist: Reach 800/quarter (new accounts), Impact 2 (High — activation step), Confidence 85% (validated in 8 user interviews), Effort 3 PM. Score = (800 × 2 × 0.85) / 3 = 453.
- Bulk admin invite: Reach 260/quarter (mid-market signups only), Impact 3 (Massive — unlocks team activation), Confidence 60% (qualitative only, no behavioral data), Effort 5 PM. Score = (260 × 3 × 0.6) / 5 = 94.
- First instinct says bulk-invite is bigger ('massive impact!'), but the smaller-reach + lower-confidence + bigger-effort combination drops it 5x below the checklist.
- Action: ship checklist now; instrument the bulk-invite hypothesis to raise its confidence; revisit next quarter.
TakeawayWithout RICE, gut feel might have prioritized the bulk invite. With RICE, the lower-confidence bigger bet correctly defers to the higher-confidence smaller bet.
Picking ICE over RICE for a growth experiment backlog
A growth team has 28 conversion experiments queued. RICE-scoring all of them would take a full week.
- Reach is roughly constant (all hit the same signup funnel) — so RICE's Reach lever is dead weight.
- Switch to ICE; score each from gut in a 90-minute session.
- Top-scoring experiment: 'Add social proof on signup'. ICE = 7×6×9 = 378.
- Bottom-scoring: 'Animated hero on landing page'. ICE = 4×3×5 = 60.
- Run the top 3; recalibrate scores against actual lift; adjust scoring style.
TakeawayICE was the right tool for high-volume same-Reach experiments. RICE's transparency overhead would have starved velocity.
Using WSJF when the deadline is real
Three roadmap items are competing: 'GDPR DPA renewal automation', 'New-user activation experiment', 'Premium plan tier launch'.
- GDPR DPA: Job 5, User-Business Value 5, Time Criticality 13 (regulatory deadline 4 months out), Risk Reduction 8. WSJF = (5+13+8)/5 = 5.2.
- Activation experiment: Job 2, V 5, TC 3, RR 2. WSJF = (5+3+2)/2 = 5.0.
- Premium tier: Job 8, V 13, TC 5, RR 5. WSJF = (13+5+5)/8 = 2.875.
- Rank: GDPR > Activation experiment > Premium tier. Despite Premium having the highest dollar value, its size and lower time criticality push it to third.
TakeawayWSJF correctly highlighted that the regulatory deadline created ambient cost-of-delay invisible to RICE. The big premium bet still gets done, just sequenced after the urgent shorter jobs.
Catching a Kano misclassification
Team wants to invest heavily in custom dashboard builders, treating them as a Delighter that will differentiate.
- Run Kano survey on 50 enterprise users: results show 71% classify dashboard builders as Must-Have or Performance, only 12% as Delighter.
- Reframe: dashboard builders are table-stakes, not delight. Delight will need to come from somewhere else.
- Re-prioritize: ship the dashboard builder MVP fast as a competitive must-have; redirect 'delight' investment to the AI-summarization feature that scored as a true Delighter (78% Delighter response).
TakeawayKano correctly redirected investment from a feature that would only meet expectations to a feature that would actually generate satisfaction lift.
Interactive lab
These instruments implement the textbook formulas loosely—use them to stress‑test judgments, compare frameworks on the same backlog, then document evidence and decisions.
← swipe to see all frameworks →
RICE
Reach × Impact × Confidence ÷ Effort (Intercom scale)
Reach × Impact × Confidence% ÷ Effort— Reach = users/events in one consistent period; Effort in person-months
score = (reach × impact × confidence/100) ÷ effort| # | Initiative | Reach | Impact | Confidence | Effort | RICE Score | |
|---|---|---|---|---|---|---|---|
| 1 | 85% | 453.33 800×2×0.85÷3 | |||||
| 2 | 60% | 93.60 260×3×0.60÷5 |
Resources / Case Studies
Curated reading for this mission
Sean McBride / Intercom
The original Intercom blog post introducing the RICE framework with worked examples.
Source-of-truth article for RICE; the simulator in this curriculum implements the same math.
Don Reinertsen
The seminal text on Cost of Delay, queuing theory, and product development economics.
The most rigorous treatment of why time-based prioritization matters; foundational for WSJF.
Sean Ellis / GrowthHackers
Sean Ellis's lightweight scoring method for high-velocity experiment backlogs.
Establishes when ICE is the right tool over heavier frameworks like RICE.
Mind the Product
Practical guide with templates for running a Kano survey, classifying responses, and avoiding common pitfalls.
Most accessible operational guide for actually running Kano analysis.
Luke Hohmann
Hohmann's collaborative game for surfacing demand intensity from stakeholders.
Strong tool for advisory boards and internal alignment workshops.
Joshua J. Arnold (Black Swan Farming)
Plain-language explanation of CoD with case studies showing the dollar impact of late shipments.
Best free introduction to CoD for PMs new to the concept.
Tony Ulwick
Outcome-Driven Innovation's quantitative scoring method for under-served outcomes.
The clearest reference for combining JTBD discovery with quantitative roadmap prioritization.
Janna Bastow / ProdPad
The case for Now / Next / Later format and why date-based roadmaps damage trust.
Foundational reading for moving teams off Gantt-roadmap pathology.
Itamar Gilad
Gilad's Confidence Meter — a structured way to attach evidence to confidence scores in any prioritization framework.
Operationalizes confidence in a way every framework benefits from.
Lenny Rachitsky
Recurring case studies from PMs at large tech companies on how they actually prioritize.
Reality-check against the canonical frameworks; current practitioners share what works and what doesn't.
John Cutler / Amplitude
Weekly notes from a product strategy lens on prioritization, theme allocation, and team operating models.
Sharpens systems-level thinking about prioritization beyond per-item scoring.
Ryan Singer / Basecamp
Basecamp's alternative to backlog-driven development: shaped bets, fixed appetite, no estimation theater.
Provocative counter-view to scoring-based prioritization; worth reading even if you don't adopt it.