# 產品 OKR 的訂立與 Roadmap 展開 - 曾友志

{%hackmd o8oUosN0QnqMSkF1_6kH7g %}

#### 📚 議程介紹

{%preview https://webconf.tw/agenda/6 %}

###### ▼▼▼ 開始筆記 ▼▼▼

> 講師的部落格：https://mrpm.cc/
> 投影片：[here](https://onedrive.live.com/view.aspx?resid=5574E2EE3F192A60!sda06abf8f2ea421886452545d7106276&migratedtospo=true&redeem=aHR0cHM6Ly8xZHJ2Lm1zL3AvYy81NTc0ZTJlZTNmMTkyYTYwL0lRVDRxd2JhNnZJWVFvWkZKVVhYRUdKMkFlbTBwREZfaFg5Zlc1X3NkMm40akRr&wdSlideId=269&wdModeSwitchTime=1765512527502)
=> 不能下載 (過去之後可以看&用下載pdf ) https://mrpm.cc/1809/#more-1809

### OKR 策略與目標是什麼
- 策略 告訴我們怎麼贏
- 目標管理 確保沒有走偏
- 基於策略，OKR 才會有意義
- 策略改變，OKR 就應該改變

1. OKR 的本質與顧問的角色
顧問的任務： 幫助團隊與組織「做對的決定」。團隊需要方向一致，組織需要決策效率。

OKR 的重新定義： 很多人認為 OKR 只是 Objective（目標）和 Key Results（關鍵結果），但講者認為完整的 OKR 包含三個層次：

策略 (Strategy)：怎麼贏？（這是最基礎的，沒有策略就不要寫 OKR）

目標管理 (Objectives)：我們要去哪裡？

Roadmap 迭代：如何到達？

常見誤區： 只有目標沒有策略。如果策略改變，OKR 就必須改，不要死守舊的 OKR。

### 產品團隊的 OKR
- 困難
- 迭代的失敗率高
- 迭代不如預期是常態，成效非線性
- 瑣事多
- 老闆無感
- 利害關係人多
- 問題一

- 定出 outcome 型KR

- OKR 的核心：不是高機率能做到的成果，而是能帶來最大突破的成果
- OKR 是期望值的概念 = 達成機率 x 成果
- 保守的心態沒辦法帶來突破

2. 產品團隊 OKR 的特殊性
非線性成果： 產品開發不像業務（打越多電話業績越高），產品團隊可能嘗試 10 個點子只有 1 個成功。這就是「產品迭代」的常態。

面臨挑戰： 產品團隊除了做新功能，還有修 Bug、還技術債、應付利害關係人（行銷、業務）的需求，資源容易被瓜分。

3. 設定 Key Results (KR) 的實戰原則
講者透過兩個案例（搜尋優化、推薦引擎）探討如何設定 KR：

原則：盡量衡量 Outcome (成效) 而非 Output (產出)

Output 型 KR（較差）： 「完成搜尋功能上線」、「完成 20 場訪談」。這只是做了事情，不代表有價值。
Outcome 型 KR（較好）： 「搜尋後加入購物車比例提升至 12%」。這代表了用戶行為的改變與商業價值。

例外情況： 如果 Outcome 的數據回饋太慢（例如要三個月後才知道營收），為了保持迭代速度，可以暫時用「領先指標」或假設性的數據當作 KR，但必須快速驗證。

4. OKR 執行的三大挑戰與解法
挑戰一：大家習慣定「保守目標」 (Sandbagging)
現象： 員工喜歡定 100% 能達到的目標，因為怕績效考核不好看。

問題： 100% 能做到的事通常只是優化 (Optimization)，無法帶來突破。

解法：
* OKR 與績效脫鉤： 講者引用 Christina Wodtke 的概念，OKR 是追求「期望值最大化」（達成機率 x 成果）。
* 鼓勵冒險：如果目標是「登陸月球」，就算只做到 70% 到了大氣層，也比「走到巷口」完成 100% 有價值。

挑戰二：目標太高導致倦怠 (Burnout)
現象： 老闆定了一個超高目標，但沒有給資源，員工覺得這是不可能的任務。

解法：區分 OKR 類型
* 優化型 OKR (Optimization)： 團隊自己決定，追求穩定提升（如：轉化率 30% -> 45%）。
* 探索型 OKR (Exploration)： 老闆直接給定方向（如：驗證 AI 助理價值），沒人知道做不做得到。這類目標必須「由老闆給予足夠資源」且「允許放棄」，失敗必須是選項之一。

挑戰三：策略與執行的斷裂
好策略的定義： 策略的好壞很難用結果論（成王敗寇），因為你永遠不知道沒選的那條路會不會更好。
好策略 = 好過程： 花足夠時間深思熟辯、投入足夠資源、解決關鍵問題。

Roadmap 展開： 不要只是列功能清單 (Feature list)。要以「做一次就會成」的角度去發想，但在執行上要假設「做一次不會成」來進行高頻率的驗證與修正。

總結建議
1. 先有策略再寫 OKR： 不要讓 OKR 變成單純的填空題。
2. 減少等待： KR 要定得讓團隊每週都能看到進度，如果指標跑太慢，就換一個能快速反應的指標。
3. 擁抱不確定性： 產品開發是賭注，OKR 是為了管理這個賭注的期望值，而不是為了寫報告給老闆看。