從洞察到行動：分岔路口#
我們已經聚焦於少數關鍵問題、辨識了驅動策略的洞察——現在要把洞察變成行動。
但這裡有個分岔：這正是判斷「公司是否認真實踐賦能型團隊」的時刻。
老實說，即使公司決定保留路線圖與功能團隊，只要有強的產品策略，就比多數沒有策略的功能團隊組織好得多。
兩條路：給「功能」 vs. 給「問題」#
差別歸結到：你給產品團隊的是「要打造的功能」，還是「要解決的問題」？
多數時候很明顯：
| 「打造功能」 | 「解決問題」 |
|---|---|
| 把影片加進線上說明 | 改善新使用者引導的成功率 |
| 我們需要一個 app | 我們的使用者需要能在任何地方存取我們的服務 |
例子 1：把影片加進說明，只是「改善引導」上百種方法之一。
例子 2：app 很可能是「在任何地方使用」的主要方式，差異微妙——但仍有多種達成方式，我們希望給團隊盡量多的自由度去找出最佳解法。
兩種模式對應的領導行為#
| 領導者相信什麼 | 行為 |
|---|---|
| 我們已經知道實現策略所需的功能與專案 | 把功能放上路線圖，分配給相關團隊 |
| 我們希望團隊擁有問題，並對「探索並交付能帶來必要結果的解法」負責 | 給團隊盡量多的自由度去想出有效的解法 |
賦能團隊不等於給團隊一張空白支票——永遠有限制與脈絡（合約、合規等）。
第一種做法 = 傭兵團隊 第二種做法 = 傳教士團隊
作者全力支持賦能型模式：它持續產出更好的結果，特別在創新與交付必要結果上。
賦能模式中：把「問題」交給團隊#
在賦能模式中，我們的目的是：為每個團隊提供一組他們需要解決的具體問題，並給他們空間決定如何解。
最流行的工具是 OKR（Objectives and Key Results）：
- Objectives：要解決的顧客或業務問題
- Key Results：用來衡量進展的指標
我們已經談過「公司目標」是策略脈絡的一部分。要啟動行動，需要為每個產品團隊提供它的團隊目標（team objectives）。Part VII 將深入 OKR 在賦能模式中的運用。
但其實 OKR 不是必要的#
在 OKR 之前，先說一件重要的事：你其實不需要 OKR 或任何技術。
真正需要的只是：有見識的領導者坐下來、與相關產品團隊解釋策略脈絡（含產品策略），告訴每個團隊要處理什麼問題、要量測什麼業務結果。
若團隊有對的知識與技能，他們就會開始工作。
OKR 是把這些對話形式化的技術——但只有在你已經配置好賦能型團隊、領導者已經做出有效產品策略，且願意託付團隊去解問題的前提下，OKR 才是有用的技術。
給予自由 ≠ 放任不管#
賦能不代表「把團隊放著不管，靜觀其變」——產品策略仍需大量主動管理。
下一章談的就是這個：如何管理而不微觀管理。