題幹與適用場景
你負責一款 B2B 協作 SaaS，下一個迭代只有 6 個工程週，卻收到三項無法同時完成的請求：
- 業務提出 SSO，初步估算 5 個工程週；1 個現有客戶表示上線後會擴充，業務另列出 12 個同類潛在客戶。
- 客服提出「批次復原誤封存專案」，初步估算 3 個工程週；相關問題占近 4 週工單的 18%，涉及約 8% 的每月活躍管理員。
- 平台團隊提出儲存遷移，初步估算 6 個工程週；目前版本將在 9 個月後停止支援，遷移、觀察和回復至少需要 5 個月。
以上數字都是面試案例假設，不代表產業基準。你需要說明會核驗什麼、怎樣比較不同類型的工作、選擇哪一項，並向沒有被選中的團隊交代後續安排。面試官可能進一步改變條件，例如把儲存停止支援提前，或發現 SSO 只服務一個客戶，觀察你是否會機械地堅持第一次結論。
這是一道產品判斷題，適合產品經理、產品負責人和需要參與路線圖決策的技術負責人。2026 年公開面試材料仍直接把「在三個衝突功能請求中排序」列為產品題；DoorDash 的公開產品經理面試指南也把 Product Prioritization 設為獨立環節，關注資料、取捨、艱難決策和一開始建立目標。
面試官考察點
第一項是能否先確定決策目標。沒有目標時，收入、工單、平台風險和工程成本無法放進同一個結論。候選人需要問清楚目前週期究竟優先企業擴張、留存、支援效率，還是必須消除營運風險，並指出哪些護欄不能被目標覆蓋。
第二項是能否識別硬性限制。安全、法遵、合約承諾、供應商停止支援和不可逆相依關係可能構成准入閘門。一項工作若已到最晚安全啟動時間，就應先保障它，不應與一般機會一起算平均分。相反地，「9 個月後停止支援」也不能自動等於「本週立刻做」；還要扣除遷移、觀察、回復和緩衝時間，算出最晚安全啟動日。
第三項是證據品質。業務給出的客戶名單、客服工單比例和平台風險並非天然可比。好的回答會核驗客戶承諾是否有合約條件、12 個潛在客戶是否真的進入相同階段、18% 工單是否由同一根因造成、8% 使用者是否處於核心流程，以及工程估算是否包含安全審查、上線和維護成本。
第四項是作出選擇。只說「用 RICE、MoSCoW 或價值—成本矩陣」仍未完成題目。目前的產品實務材料也強調，單一框架無法涵蓋性質不同的工作；RICE 的原始說明同樣允許相依項目或市場准入項目改變分數順序。框架負責減少盲點，候選人仍要給出結論、機會成本和改判條件。
最後看溝通是否可執行。路線圖決策需要留下證據、假設、負責人、時間點和複查觸發器。給所有請求都承諾「儘快」只會製造三個隱性承諾，也無法檢驗候選人是否真的會管理預期。
回答前需要澄清的問題
- 本週期的唯一首要結果是什麼？ 本題假設公司本季優先提升企業客戶擴張，同時不得錯過儲存遷移的最晚安全啟動時間。
- 6 個工程週怎樣計算？ 是一名工程師 6 週，還是多人平行工作的合計投入？是否已經扣除審查、測試、發布和事故值班？本題按可替代的總工程投入計算。
- 儲存遷移最晚何時啟動？ 9 個月是確定期限還是預警？遷移、雙寫、驗證、回復和緩衝分別多久？本題假設平台負責人驗證後，最晚可在 4 個月後啟動，但必須在下一個規劃週期鎖定產能。
- SSO 的商業證據有多強？ 擴充是否寫入合約條件，12 個潛在客戶是否都被同一個缺口阻塞，預期價值和成交機率如何？本題假設現有客戶條件已確認，12 個潛在客戶中有 4 個完成技術核驗。
- 客服問題是否值得做產品修復？ 18% 工單是否去重，8% 管理員的任務是否關鍵，是否存在培訓、權限或流程根因？本題假設批次復原能解決主要根因，但沒有造成資料遺失。
- 三項估算的口徑是否一致？ SSO 是否包含安全審查和企業設定，客服功能是否包含稽核紀錄，遷移是否包含雙寫和回復演練？缺少這些內容時不能直接比較數字。
- 能否拆出低成本的風險驗證？ 小型技術探索可以降低不確定性，但不能把三項工作都切成無法產生結果的碎片。本題允許先用 3 個工作日驗證 SSO 的安全範圍，且這部分包含在 6 個工程週內。
- 誰擁有最終決定權？ 產品經理應提出有證據的建議；涉及已簽合約、監管或不可接受的技術風險時，要明確相應決策人與升級路徑。
30 秒回答框架
「我先確認本週期目標與硬性限制，尤其是遷移最晚啟動日；再統一比較結果、證據、投入、延遲成本、相依關係和可逆性，只為同類機會評分。題設下遷移可等一個週期，企業擴張優先，因此用 3 個工作日驗證 SSO；總投入不超過 6 個工程週就做，否則轉向批次復原。遷移鎖定下一個週期產能，客服獲得暫時方案和複查日，全部假設與改判條件寫入決策紀錄。」
分步驟深入解答
先把需求改寫成結果，避免比較三個功能名稱：SSO 希望解除企業擴張阻塞；批次復原希望減少管理員返工和支援成本；儲存遷移希望在供應商期限前消除連續性風險。然後寫出本週期目標與護欄。本題假設目標是企業擴張，護欄包括資料安全、合約履行和不得錯過遷移最晚啟動時間。
第二步建立硬性限制閘門。對每項請求回答四個問題：不做會不會違反法律、合約或安全底線；是否存在外部硬期限；現在是否已經達到最晚安全啟動日；延遲後能否恢復。只要答案表明本週期必須開始，該項就先進入產能計畫，剩餘機會再排序。這裡平台團隊已經證明遷移最晚可在 4 個月後啟動，因此本週期尚未觸發閘門；這項結論必須有負責人和日期，不能停留在「以後再說」。
第三步統一證據口徑。可以使用下面的決策表，但表中的數字只是目前案例快照：
| 維度 | SSO | 批次復原 | 儲存遷移 | |---|---|---|---| | 目標結果 | 企業擴張 | 減少返工與工單 | 降低連續性風險 | | 涵蓋證據 | 1 個已確認擴充條件；4 個完成核驗的潛在客戶 | 18% 工單；8% 每月活躍管理員 | 9 個月後停止支援 | | 證據強度 | 中 | 高 | 高 | | 總投入 | 5 個工程週，另有 3 個工作日範圍驗證，合計不超過 6 個工程週 | 3 個工程週 | 6 個工程週 | | 延遲成本 | 可能推遲本季擴張 | 工單與返工繼續累積 | 目前可等待一個週期，之後快速上升 | | 可逆性與相依關係 | 安全範圍不明時可停止 | 上線可灰度、較易回復 | 相依關係多、回復成本高 |
「涵蓋證據」不能只複製請求人的數字。業務名單要按機會階段、合約條件和共同需求去重；客服資料要按根因、使用者群和嚴重性拆分；平台期限要從最後日期倒推實際工作和緩衝。資訊缺口本身也要影響排序。沒有證據支撐的高影響估計應降低信心，精確小數無法掩蓋未知。
第四步選擇合適的比較方式。若候選項都是同一目標下的功能機會，可以用 RICE 比較涵蓋範圍、影響、信心和投入；若關注時間損失，可以加入延遲成本；若是範圍收斂，可以用 MoSCoW。混合了商業機會、體驗修復和基礎風險時，先分類與過閘門，再用較小的評分表比較剩餘選項。分數是討論輸入，任何「必須做」的例外都應寫明原因。
第五步必須作出單一決定。按本題假設，儲存遷移尚未到最晚安全啟動點，SSO 與目前企業擴張目標最一致，且存在一項已確認擴充條件和 4 個完成核驗的同類機會。因此先進行 3 個工作日的安全與範圍驗證；驗證確認總投入不超過 6 個工程週，就把本週期產能給 SSO。
這個決定附帶兩個明確的切換條件：若 SSO 完整範圍超過 6 個工程週，或擴充條件與共同需求無法被證實，就停止投入並切換到 3 個工程週的批次復原；剩餘產能用於驗證儲存遷移，不臨時塞入第三個半成品。切換條件使探索有上限，也防止團隊因為已經投入幾天而陷入沉沒成本。
第六步處理沒有入選的工作。平台遷移需要在路線圖上鎖定下一個週期的 6 個工程週、負責人、啟動日和風險複查；若供應商期限提前、驗證發現遷移實際需要更久，或安全餘量低於約定值，就立即重開優先級。客服團隊獲得批次操作的受控人工流程、工單標記和下一次審查日期，同時繼續收集嚴重性與耗時，不能用暫時方案無限延期。
最後定義結果與複盤。SSO 上線後觀察被該能力阻塞的客戶是否完成設定、擴充條件是否兌現、銷售週期是否推進，並監控驗證失敗和支援負擔。達到預先約定的證據窗口後，核對最初假設；若價值沒有出現，記錄誤判來自涵蓋範圍、影響、信心還是投入估算。優先級能力包含修正決策，不能只包裝第一次選擇。
高品質示範回答
以下結論基於題目給出的虛構案例資料。
「我會先把三個請求翻譯成結果：SSO 解除企業擴張阻塞，批次復原減少管理員返工，儲存遷移控制連續性風險。然後確認本季的首要目標是企業擴張，同時安全、合約和遷移最晚啟動日屬於護欄。
我不會直接把 1 個客戶、18% 工單和 9 個月期限拿來算總分。平台團隊需要從期限倒推遷移、觀察、回復與緩衝；題設確認最晚可在 4 個月後啟動，所以本週期還沒觸發硬性閘門，但我會立即鎖定下一個週期的 6 個工程週和負責人。業務需要證明擴充條件，並核驗 12 個潛在客戶裡有多少真的被同一種 SSO 能力阻塞；目前有 1 項已確認條件和 4 個完成技術核驗的潛在客戶。客服則要證明 18% 工單來自缺少批次復原，並單獨排除培訓或權限問題。
在這些假設下，我建議本週期選擇 SSO。它最符合企業擴張目標，5 個工程週也在產能內。我會先做一個最多 3 個工作日的安全和範圍驗證，這段投入包含在 6 個工程週中。若驗證後總範圍仍不超過 6 個工程週，就繼續交付；若超限，或者客戶擴充條件和共同需求沒有被證實，就停止並切換到 3 個工程週的批次復原。
沒有入選的請求也要得到可執行答案。遷移會寫入路線圖，明確下一個週期啟動、負責人和提前重排的風險觸發器；客服會先使用受控人工流程，並在下一次規劃前更新問題嚴重性與處理耗時。我會把目標、證據、假設、決定和切換條件寫進一頁決策紀錄，讓業務、客服、工程和管理者看到同一套依據。
上線後，我會核對 SSO 設定完成、擴充條件兌現、銷售機會推進以及驗證失敗和新增工單。到約定窗口後複盤估算誤差。如果目標或硬期限變化，我會重新排序；初次決定不應成為永久承諾。」
常見錯誤
- 一開始就套 RICE → 不同性質的工作被強行量化，硬期限可能被平均分掩蓋 → 先分類並檢查法律、安全、合約、相依關係和最晚啟動日，再比較機會。
- 誰聲音最大就先做誰的需求 → 組織權力取代了使用者與業務證據 → 統一證據口徑，記錄請求背後的結果、涵蓋範圍和信心。
- 把「9 個月後停止支援」直接排第一 → 沒有倒推遷移與緩衝，無法判斷真實急迫性 → 計算最晚安全啟動日，並給出負責人和複查觸發器。
- 把 12 個潛在客戶都當成確定收入 → 機會階段、成交機率和需求共性沒有核驗 → 檢查合約條件、銷售階段和可重複價值，並降低不確定估計的信心。
- 只統計工單數量 → 重複工單、低嚴重性問題和少數高頻使用者會扭曲判斷 → 按根因、受影響使用者、任務嚴重性和處理時間拆分。
- 把團隊拆成三份同時開始 → 每項都缺少完成產能，產生三個半成品和更多切換成本 → 選擇一個結果，只拆出有明確時間盒與退出條件的驗證工作。
- 所有請求都答應「下一個版本」 → 隱性承諾互相衝突，下一輪仍無法取捨 → 為未入選項目給出明確狀態、日期、負責人和重開條件。
- 給出分數卻不做決定 → 面試官看不到候選人是否願意承擔機會成本 → 說出選擇、放棄什麼、為什麼，以及什麼證據會讓你改判。
- 上線就宣布優先級正確 → 交付完成不等於預期價值出現 → 按最初假設觀察結果，並複盤涵蓋範圍、影響、信心和投入估算。
追問及應對
追問一：CEO 明確要求先做某一項，還需要排序嗎？
先確認這是資訊輸入、決策建議還是最終指令，並補齊 CEO 掌握而團隊未知的目標或限制。若決定權確實屬於 CEO，就記錄決定與風險，團隊負責執行；產品經理仍應提供機會成本、受影響承諾和驗證方案。用一張評分表對抗明確的決策權沒有價值，隱瞞風險同樣失職。
追問二：三項資料都不完整，怎樣避免一直研究？
找最可能改變排序的未知項，設定時間盒。這個案例中，SSO 安全範圍和客戶條件會直接決定它能否入選；儲存最晚啟動日決定是否觸發硬性閘門。先用 3 個工作日驗證這些變數，其餘使用範圍估計，並提前寫好「結果 A 選什麼、結果 B 選什麼」。研究要買到決策資訊，不能追求全面資料。
追問三：一個大客戶需求和很多小使用者問題怎樣比較？
把「大」和「多」拆成共同結果：可歸因價值、涵蓋範圍、嚴重性、策略匹配、信心、投入與長期維護。檢查大客戶需求是否代表可重複使用的市場准入能力，也檢查小使用者問題是否阻塞核心任務。客戶數量本身不負責結論；一項低頻但阻斷關鍵工作的問題，可能高於一項高頻輕微不便。
追問四：技術債總是在評分中落後，怎麼辦？
技術債需要翻譯成故障機率、交付延遲、法遵風險、人力成本或被阻塞的後續工作，並標出風險隨時間如何變化。達到不可接受閾值或最晚啟動點後，它進入硬性限制產能；尚未達到時，可以安排有限的風險驗證和明確的保留產能。長期基礎工作若只用短期收入評分，模型本身就不適用。
追問五：開發中途出現緊急需求，是否立即改優先級？
先用同一個閘門判斷它是否涉及安全、法遵、重大客戶損失或不可逆期限。未觸發硬性限制時，比較完成目前工作的剩餘價值、切換成本和新需求的延遲成本。若改排，明確停止點、已投入如何處理以及哪些承諾被移動；若不改，也寫出下一次複查時間。頻繁插隊需要單獨統計，因為它可能說明目標不穩定或入口治理失效。
追問六：選中的 SSO 上線後沒有帶來擴充，怎樣複盤？
按決策紀錄逐層核對：業務條件是否真實、潛在客戶是否共享同一需求、客戶是否完成設定、實作是否滿足企業安全要求、觀察窗口是否足夠。然後區分判斷錯誤與執行錯誤。若涵蓋範圍或影響被高估，更新今後的證據標準；若交付品質阻斷採用，先修復體驗再評價機會。複盤結果要改變下一輪估算，不能只寫「市場不如預期」。