在任何產品組織裡，作為產品主管（Head of Product, HoP），你和你的 PM 都必須持續平衡探索（product discovery, 決定要做什麼）與交付（product delivery, 把它做出來）。前者過多：永遠出不了貨；後者過多：把錯的產品做得很漂亮。

確保你在做對的事，比單純做事重要得多。

章首那句據稱出自 Einstein 的話很適合定錨：

If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.

即使最資深的 PM 也必須不斷對抗三股「邪惡勢力」：

• 功能蔓延（feature creep）：對那些不影響目標/KPI、不明顯改善使用者生活的事情，要敢說 No
• 沒有深度思考的時間：一天塞 15 個會，就別談 discovery 了
• 餵食野獸（feeding the beast）：backlog 空了就隨便丟任務給工程師做，只為了不讓他們閒著

作者建議一個很有效的 check-in 方式：請 PM 反思自己如何在「日、週、月、季」這四個時間尺度上平衡 discovery 與 delivery。再搭配任務板（task board）作為視覺工具。本章沿用第 4 章 PMwheel 的八個分類（Figure 17-1）來討論 PM 的不同活動。

把一天過對（Get your day right）#

這是最簡單的一層。請 PM 問自己：是否有大塊不被打斷的時間去做深度思考、學習、使用者訪談、資料研究、假設發想、團隊腦力激盪？這些對應 PMwheel 的 bucket 1、2、3、5。

一天的理想比例大約是 50% discovery / 50% delivery（Figure 17-2）。重點不是每天做了什麼，而是有沒有預留 maker time 給 discovery。

把一週過對（Get your week right）#

請 PM 打開過去六週的行事曆，逐條檢視：

• 每週都有接觸使用者嗎？ 作者堅持每週至少一個使用者接觸點——哪怕只是讀 app-store 評論、打給兩三位忠實客戶聊聊最新版本
• 每週都有看使用者資料來校準或產生新假設嗎？
• 每週都有檢視成功指標與目標進度嗎？ 產品表現如何？使用者用的方式是預期的嗎？營收面健康嗎？
• 每週花多少時間和團隊待在一起？ 坐在團隊空間讓工程師、設計師隨時能問問題，偶爾也一起吃飯、打球
• 每週都在檢視短期與中期規劃嗎？ 這個 sprint 會如期出嗎？接下來最重要的實驗是什麼？時間夠嗎？需要調整 roadmap 或對 stakeholder 重新溝通嗎？

這些要一人腦內 juggle 很難，所以才需要任務板來提醒。

把一個月過對（Get your month right）#

作者每月會和 PM 一起問的問題：

• 開發 backlog 上有「有意義」的工作嗎？（對使用者、公司、團隊三方都有意義）
• 這個月使用者的生活有被改善嗎？若沒有，為什麼？
• 這個月 PM 想學到什麼現在還不知道的事（關於使用者或團隊）？
• discovery 流程有可以改進之處嗎？學得更快？進入開發的點子品質比上個月更高？
• 這個月有多少 idea 可以丟進 ideas trash can？
• 有為了趕進度而累積技術債嗎？如果有，怎麼讓它回到健康水位？

把一季過對（Get your quarter right）#

作者推薦三個練習：

Draw the quarter（畫出你的一季）#

請 PM 反思：想花多少時間在「理解問題」vs.「和團隊把事情做完」vs. 其他 PMwheel bucket？把它畫出來，檢查是否平衡（Figure 17-3）。

一個實用的節奏：季末多留一些「理解問題」與「做規劃」的時間，為下一季做準備。

Plan the quarter（規劃這一季）#

每季都有一批會重複的活動，幫 PM 提早開工、預留夠多時間：

• 檢查產品策略是否還站得住？策略是否真的能幫 PM 決定取捨？若否，先把策略翻修
• 收集並檢視 open ideas，規劃比較大的機會評估（opportunity assessment）
• 設定目標。若用 OKR，檢視並訂出 objectives，對齊 key results 與指標
• 小心 sand（下一章會介紹 rock/pebbles/sand 時間管理框架）：為小事保留時間但不要預先排滿，你終究會用來做其他小事
• 請 PM 問團隊：**技術棧（tech stack）**是不是該升級了？

Do a reality check（做現實檢驗）#

計畫出來後，立刻做對帳：

• 人力盤點：用 person-day 計算，扣掉假日、研討會、all-hands、其他把人抽離團隊的活動。這一步通常會讓所有人嚇一跳。然後請 PM 再檢查一次——discovery 的時間真的還夠嗎？
• 產出量假設（throughput）：團隊一季能交付幾個 large / medium / small 任務？
• 不要讓 PM 每季末都在爆炸：計畫要有挑戰性，但不能過於野心勃勃。長期達不到目標，不會讓人感覺良好。

產品管理任務板（Task boards）#

任務板是用卡片代表工作項目、欄位代表流程階段的視覺化工具，卡片由左向右移動表示進度（Figure 17-4）。搭配每週 standup，能讓 PM 與團隊自然而然被提醒「還有什麼事該做」。

作者建議依組織規模，使用四種不同粒度的任務板，互相串接。

Idea Board（點子板）#

把點子或假設從被提出、變成合格機會、到被指派給 PM 或團隊這條流程視覺化（Figure 17-5）。核心問題：這個點子潛力夠不夠？

Product Overview Board（產品總覽板）#

給 HoP 用的高層級視圖（Figure 17-6）。卡片從「合格機會」開始，經過：

discovery → implementation（delivery）→ validation 與漸進優化 → sunsetting

Validation 階段最常被遺忘：released 不等於就此不碰。一個 feature 上線後還有非常多的迭代價值。

而 sunsetting（日落）同樣重要：舊功能先隱藏 → 再封存 → 最後工程師刪掉程式碼。

discovery 活不下來的點子，直接進 trash can。

Product Discovery Board（探索板）#

由 PM 主責，用來視覺化打造「有價值、可用、可行、商業可持續」產品的所有活動（Figure 17-7）。對應的 standup 通常包含：

• PM
• 設計師
• 至少一位工程師

這三人被稱為 holy trio 或 product trio。也可納入資料分析師或只想保持訊息同步的 stakeholder。

Product Delivery Board（交付板）#

開發團隊擁有的任務板（Figure 17-8）。作者的建議：

堅持在流程最後加一個 validation 欄位。提醒所有人：done and released 不代表結束，真實使用者帶來的學習還會驅動下一輪迭代。

trash can 是必要的——該砍的 feature 要敢砍。但如果 trash can 經常在裝東西，代表你的 discovery 流程該被改善了。

寫了程式碼卻最終沒人用，是公司能犯下最昂貴的錯誤。

Figure 17-9 是四塊板的整體鳥瞰。

任務板如何幫你保持平衡#

要平衡，先得知道你在平衡什麼——而這需要把活動寫下來、讓它可見。任務板就是做這件事。

兩個具體幫助：

• 流程提醒：如果某個 PM 一直做 solution hypothesis，卻忘了先驗證底層問題，板子上的欄位就會把這件事喊回來。板子是團隊自己同意的理想工作流的「外化提醒」
• 節奏揭露瓶頸：卡片卡在某一欄太久？為什麼？板子開始變空？該找新機會、新實驗、新 backlog 了

一個聚焦於平衡各股力量的工作流 + 一塊會自己暴露瓶頸的板子 = 一個讓 PM 與團隊不必每分鐘都在想平衡、卻自動維持平衡的 liberating structure。

延伸閱讀#

• Jeff Patton — Balancing Continuous Discovery and Delivery
• Teresa Torres — How Much Time Should You Spend in Product Discovery?
• Teresa Torres — Fix Delivery to Make Time for Discovery
• Lucio Santana — Product Discovery in the Multitrack of Madness