規劃與優先順序大到足以各寫一本書。作者在本章聚焦於 如何 coach PM 做好這兩件事，而不是把所有技法塞進一章。
為什麼會變成 coaching 議題#
通常由三個狀況之一觸發：
- PM 主動求助——她覺得自己在規劃／排序上不夠好，來找你
- 你不同意 PM 的做法——身為 HoP，你判斷他需要被引導
- 最常見：stakeholders 在抱怨——dev team、marketing、sales、顧客對 PM 的排序選擇不滿，要你介入
如果是第三種狀況，先讓抱怨者直接跟 PM 溝通（見 Ch. 28「處理衝突」）；沒改善才由你出手 coach。
確認要 coach 之後，先診斷底層問題：
- 解釋能力問題：PM 其實排序能力夠，只是沒把流程與標準說清楚
- 技能問題：PM 根本缺這項能力——重大警訊，值得你投入大量時間補救
- 組織問題：整間公司還卡在 top-down/waterfall 思維——PM 無力修復，得由你處理
規劃 vs. 優先順序#
這兩件事相關但根本不同：
- Planning（規劃）：依時間順序列出為達目標所需的未來行動清單
- Prioritization（優先順序）：一種有意識的選擇——把各種替代方案，依刻意選定的標準排序
標準是什麼很重要：用的是商業價值、團隊依賴，還是直覺？HoP 的工作是幫 PM 釐清自身脈絡下哪些標準真的有意義。
目標是讓優先順序成為主戲，規劃變得容易。優先順序做對了，規劃幾乎自動成形。
關於 deadline 的立場#
- 有時必要（例如兩個月後的展會，行銷要能開賣）
- 但能避免就避免——人們總會把 deadline 視為承諾
- 時程圖偶爾有用（例如：誰何時休假、12 週怎麼排），但只給 dev team 內部用
- 若要給組織看，務必讓大家理解「這不是承諾交付日」——預測未來沒人擅長
Agile 規劃基本盤（Figure 21-1）#
讓 PM 理解經典的四角關係：
Time
|
Scope-+-Quality
|
Investment (Staffing)- 四者相互牽動：硬性 deadline + 固定 scope + 固定團隊 → 很可能做不完，或品質妥協
- 若 quality 與 scope 可浮動，給定團隊仍能為展會交付有價值的東西
Figure 21-1: Revisiting Agile planning basics
同時做仔細的團隊 availability 計算：6 人 × 每季 4 天休假 = 每季 24 人日要扣掉。沒算進去的規劃永遠會偏。
Coaching 優先順序：四個提醒#
coach PM 時，請他們循以下大方向：
- Set your priorities——什麼現在做、什麼能等？反思自己用的排序標準，把它變成刻意選擇。讓 PM 理解：不可能有兩個 #1。可以有 Discovery Now/Next/Later 和 Delivery Now/Next/Later 兩套 backlog，但每套都要是排序過且最新的
- Explain and (sometimes) defend——不要只丟清單不解釋。挑戰是好事——更多聰明人介入，結果會更好
- Stick to your priorities——別被 Christina Wodtke 在 Radical Focus 提到的 “golden apples” 分心。快速評估，值得才換
- Adjust as necessary——世界會變，要定期重檢。但挑好時機：sprint 末尾大家心情好、動 backlog 沒事；sprint 中途動，超煩
優先順序的幾個真相#
- Truth：永遠會有做不完的工作。團隊再大也不夠——這正是排序存在的理由
- Truth：任何時刻只能有一個 #1。可以有 discovery #1 和 delivery #1，但若兩者搶同一批人，PM 必須選一個
- Truth：沒有 vision 與 strategy，排序無從談起——它們是過濾器。idea 不符合就砍掉
- Truth：要早早砍掉不是贏家的 idea。贏家是歷經實驗驗證後變成 opportunity 的——才值得進 delivery backlog。對齊 discovery 與 delivery 的垃圾桶，能幫你說 no
- Truth：適合你的方法就是最好的方法。作者目前最愛 Gabrielle Bufrem 的框架
- Truth：永遠有突發狀況（bugs、support、ad hoc、tech stack、ops）和持續運營要處理
一套可教的流程（Figure 21-2）#
Figure 21-2: An approach to planning and prioritization
作者分享自己與 coachee 都覺得好用的流程：
Step 1：Analyze your throughput#
回看過去兩季實際交付了什麼。套用 rock, pebbles, sand 模型，算出你能處理的大／中／小事項數量——這就是下一季扎實的規劃基準。
Step 2：Collect all the items#
把所有人想放進產品裡的東西全堆出來：
- 和使用者／顧客／stakeholders（含 dev team）談
- 檢查 discovery/delivery backlog 的遺留項
- 寫下你基於目標與希望達成的 outcome 的直覺清單
- 交叉檢查：新機會、創新、深化現有機會、組織改善（例如讓客服團隊更輕鬆）、tech debt 與 org debt——都想過了嗎？
Step 3：Filter#
檢查每項是否符合願景、策略、本季／下季目標——這會產出第一輪 no。
Opportunity Assessment——值不值得給 discovery 時間的一組問題：
- 這 idea 背後的假設是什麼？我們理解底層的顧客問題嗎？
- 目前是驗證這些假設的好時機嗎？大概要投入多少？（大型實驗？還是桌面研究？）
- 這些假設多危險？（如果押錯，災難有多大？）
- 有商業潛力嗎？多大？（沒有就現在砍掉）
- 我們想得出可能的解法與實作嗎？effort-to-impact 比值看起來有吸引力嗎？
- 什麼都不做的機會成本？
- 能漸進式產生價值嗎？
- 能透過合作降低成本或放大效果嗎？
答案都漂亮就叫 opportunity，樂意進 discovery backlog；答不出來就代表現在還不到排序這件事的時候。
Step 4：Cluster and assess#
通過 Step 3 的項目，用你的排序標準（customer impact、business impact、cost of doing nothing、跨團隊依賴……）逐項評估，同時用 rock/pebbles/sand 分群，甚至直接砍掉一些——第二輪 no。
Step 5：Reality check#
假設你每季能做 2 rocks + 5 pebbles，那花力氣深挖 10 個 rocks 毫無意義。檢查可用 slot、故事一致性、使用者價值、團隊可用性——第三輪 no。
Step 6：Select#
做最終選擇。
Step 7：排成一列#
只留一份清單——確保全隊對「#1 是什麼」有共同認知。
要讓所有人清楚：「no」有時是「later / next」，有時是「never」。對每個 idea/feature，透明化你給的是哪一種 no。
PM 的最終目標#
coaching 結束時，你的 PM 應該能做到：
- 能解釋每個層級的當前優先順序（discovery、delivery、validation）
- 有到達那裡的戰術——知道排什麼、用什麼標準、做了 reality check
- 能解釋自己是怎麼得出這些排序的（decision log）
- 能解釋優先順序的含義（now / next / later）
- 能解釋為什麼某件事不是優先——不符策略、無助目前目標，或驗證後發現沒那麼有前景（使用者價值不足、實作太貴）
排序不是「拿單子做事」的活，而是持續的選擇。PM 的工作不是接訂單，而是挑對的事情做——並能向任何人說清楚為什麼。