團隊目標的本質：給空間，不是給規格#

團隊目標最重要的本質：先給產品團隊一個解決困難重要問題的空間，而不是給他們一份要實作的功能清單。

對比典型的產品路線圖：

給「問題」而不是「功能」：為什麼差別這麼大#

有些人覺得「功能 vs. 問題」差別不大：「如果你需要團隊做一個 app，那就告訴他們做 app 就好。」

但業界學到的核心教訓之一是：工作如何被指派，極為關鍵。

理由：

• 離問題最近的人 + 具備所需技能的人最適合決定解法——也就是產品團隊
• 我們希望團隊對結果負責——若是我們指定功能、結果不如預期，團隊無從問責
• 給問題與空間，團隊會更感受到擁有感
• 若第一個解法沒有產生預期結果，團隊知道自己必須持續迭代或試其他方法，直到找到能用的

團隊目標的構成#

團隊目標由兩部分組成：

這裡使用 OKR 格式呈現，但真正重要的是：

1. 聚焦於少數有意義的目標
2. 用**業務結果（business results）**衡量，而不是產出或活動

Objectives：好的範例#

具體目標當然取決於產品類型與團隊責任。但典型的好目標如：

• 降低包裹送錯地址的頻率
• 提高隔日送達的比例
• 降低被標記為不當的圖片比例
• 降低訂閱者流失率
• 在新市場展現既有產品的市場契合度
• 縮短求職者找到新工作的時間
• 降低履約的營運成本
• 降低顧客取得成本（CAC）
• 提升顧客終身價值（LTV）
• 降低需要客服協助的顧客比例
• 降低客服通話的平均處理時間
• 提高新顧客成功建立帳戶的比例
• 縮短使用者產生第一份月報的時間
• 縮短部署新／更新服務到生產環境的時間
• 改善網站可用性

不要太執著於目標的具體措辭。產品團隊在理解策略脈絡並調查目標後，常會發現換個說法、改變強調點或概化目標更合理。領導者與團隊間的這種來回是正常且健康的。

共通點：這些都是要解決的問題，而不是要打造的功能。

有些是顧客問題、有些是業務問題——但每個都有多種可能解法，產品團隊最適合決定最佳解法。

注意：這些目標都是質化的；量化在 Key Results 中處理。

Key Results：以業務結果衡量成功#

Objective 是「要解決的問題」，Key Results 定義成功的樣子。

必須以業務結果（outcome）衡量，而不是「活動」或「產出」。

第二常見的錯誤就是把活動或交付物列為 Key Result。

為什麼這是大問題？因為很容易交付一個 deliverable 卻沒解決底層問題——又回到老路線圖的麻煩。

主要 KR + 護欄 KR#

通常每個 Objective 配 2 ～ 4 個 KR：

• 第一個 KR 通常是主要量測
• 後續的 KR 是品質量測（guardrail / backstop）——確保主要 KR 不是用「傷害其他面向」的方式達成

例：「降低包裹送錯地址的頻率」

• 主要 KR：實際送錯比例
• Guardrail：確保總配送量持續成長
• Guardrail：確保配送成本不增加

KR 暗示了具體的 KPI——但期望數值與時程要由團隊提出。

若領導者把成功的具體數值與時程一併指定下去，團隊就不會對承諾有應有的擁有感。

何時 KR 還不清楚？#

有時最合適的 KPI 還不清楚——尤其是團隊從未處理過的問題。這時：

• 團隊需要時間理解動態與最合適的指標
• 領導者要確保「來回對話」一直在發生——被動的團隊是警訊

警惕「讓尾巴搖狗」（let the tail wag the dog）：團隊有時會選「容易量測」而非「最有意義量測」的東西當 KR。

分享策略脈絡#

要給團隊解決困難問題的空間，就必須提供做好決策所需的脈絡——尤其是產品願景與產品策略。

四個原因：

• 團隊必須深刻理解最終目標與「為什麼這個問題重要」
• 我們希望團隊開始思考洞察、考慮自己團隊能怎麼貢獻
• 我們希望團隊開始思考含義——預想看不到的依賴、需要學會的技術
• 我們喜歡團隊主動爭取特定問題——雖然不能每次答應，但會盡量配合

帶著這些原則，我們就可以開始把目標指派給特定團隊。