成果導向目標的 OKR 產品管理指南

內容：

• 什麼是 OKR？
• 誰創建了 OKR 框架，為什麼？
• OKR 的局限性是什麼？
• OKR 對領導者的好處
• OKR 對產品管理職能的價值
• 建立穩健的產品 OKR
• 審查產品 OKR 進度
• OKR 與產品策略之間的相互作用
• OKR 在產品發現中的作用
• OKR 和 Scrum 如何相互協同
• 使用 OKR 進行產品決策
• 要避免的 OKR 陷阱

成功的執行領導者的一個標誌是能夠推動朝著既定的業務願景取得重大進展。 雖然領導者必須帶來無數的技能和才能，但稱為目標和關鍵結果 (OKR) 的特定心智模型可以幫助您以更少的時間和精力實現這一進步。

我們為尋求設定和實現雄心勃勃的業務目標的最高管理層和產品負責人編寫了 OKR 指南。 通過為您自己和您管理的職能部門實施 OKR，您將能夠確定對您的業務來說重要的事情，為您的團隊應該實現的目標設定目標，跟踪目標的進展情況，並診斷問題的根本原因意想不到的結果。

什麼是 OKR？

目標和關鍵結果框架（ OKR框架）是一個靈活的、面向行動的結構，用於確定業務優先級、設定可衡量的、以結果為導向的目標，並在組織的各個層面激發行動，為客戶創造價值。

許多組織圍繞 OKR 啟動了自己的特定流程。 我們編寫本指南是為了幫助您塑造和塑造最適合您的需求和環境的流程，而不是從特定公司“導入”可能對您的特定組織弊大於利的特定風格。

首先，每個 OKR 實施都包含兩個組成部分：目標和關鍵結果。

• 目標是定性的願望，代表了企業尋求前進的方向，而不是有形的最終狀態
• 關鍵結果是代表團隊在實現目標方面取得的進展的量化目標

每個團隊在本季度都應該有一個單一的目標。 然後，團隊應決定支持該目標的多個關鍵結果。

舉個例子，想像一下一家銷售炊具的公司。 他們其中一個團隊的目標可能是“成為家庭廚師值得信賴的烹飪鍋供應商”。

該團隊可能會選擇以下三個關鍵結果來支持這一目標：

• 將退款率從 0.5% 降低到 0.2%
• 將重複購買率從 5% 提高到 15%
• 將首選品牌知名度從 10% 提高到 25%

定性目標和定量關鍵結果的特定組合是強大的，因為它推動了團隊每個成員的定向和協同行動。

想像一個只有目標但沒有關鍵結果的團隊。 該團隊不會充分了解他們在實現這些目標方面取得的進展，也不知道要改變哪些行為或採取哪些行動才能取得有意義的進展。

此外，隊友可能會單獨選擇以對他們有意義的方式追求目標，但最終無法很好地協調一致。

例如，一個人可能會針對銷售炊具的企業帳戶，而另一個人可能會針對 SMB。 或者，一個人可能會尋求提高價格以展示品牌實力和聲望，而另一個人可能會尋求降低價格以提高可負擔性和可及性。

使用這些例子，我們可以很容易地看到在團隊層面共享關鍵結果如何幫助團隊成員保持一致。

另一方面，想像一個只有關鍵結果但沒有目標的不同團隊。 該團隊將缺乏做出正確權衡的業務背景，並且可能會以犧牲長期業務成功為代價，在短期內狹隘地優化他們的指標。

而且，他們可能會在嘗試同時處理多個指標時遭受信息過載，而沒有一個總體目標告訴他們在哪些情況下優先考慮哪些指標。

因此，通過將定性願望和定量目標結合在一起，我們調整併激勵團隊採取行動，推動我們的業務向前發展。

在我們深入探討實施 OKR 的最佳實踐之前，讓我們先討論一下發明 OKR 的原因，以及該框架對知名公司的影響。

誰創建了 OKR 框架，為什麼？

英特爾首席執行官安迪·格羅夫 (Andy Grove) 在 1970 年代建立了 OKR 框架，以授權所有職能部門的各級員工識別和獲取商業價值。

他為公司創建新“操作手冊”的動機是因為他在仙童半導體工作時親眼目睹了自上而下的管理控制和一線權力下放的問題。

Grove 將 OKR 視為學習引擎，而不是績效管理系統。 OKR 的目標不是獎勵完成目標的人，也不是懲罰未達到目標的人。 相反，經理和直接下屬都需要根據他們在 OKR 方面取得的進展來反思他們所學到的東西，無論他們是否超過、達到或未達到他們的目標。

Grove 在“目標管理”(MBO) 系統之上構建了 OKR 框架，Peter Drucker 在他 1954 年的著作 The Practice of Management 中分享了這一點，德魯克在書中建議管理者為他們的直接下屬設定明確的目標以實現。

但是，格羅夫試圖避免這種僵化的結構帶來的主要缺點，這種結構將過多的決策權集中在經理和主管手中。 格羅夫在 1983 年出版的《高產出管理》一書中提出了這樣的批評：“如果主管機械地依賴 MBO 系統來評估下屬的績效，或者如果下屬因為沒有明確的目標而放棄利用新出現的機會，那麼兩者都正在以一種小氣的方式行事。”

這就是為什麼目標通常由領導者和經理設定，以及為什麼關鍵結果通常由團隊和個人設定。 通過這種方式，主管和下屬通過在前線的成功合作，共同推動高水平的業務進步。

1999 年，John Doerr 將 OKR 框架帶到了谷歌，進一步推廣了 OKR 框架。 當時，谷歌員工不到 50 人，其創始人拉里佩奇和謝爾蓋布林一年前還是博士生。

正如 Doerr 分享的那樣，“Kleiner Perkins 剛剛投資了 Google，作為 OKR 的堅定擁護者，我主動提出向 Larry、Sergey 和領導團隊介紹 OKR 系統。 拉里和謝爾蓋立即看到了價值。 他們喜歡為公司製定一套季度優先事項。”

通過將精力集中在這些優先事項上，Google 迅速成為互聯網用戶的寵兒，這些用戶以前依賴 Yahoo 或 Lycos 等門戶網站來瀏覽網頁。 Google 於 2004 年首次公開募股，距 OKR 在 Google 實施僅 5 年。

OKR 的局限性是什麼？

我們現在看到 OKR 如何幫助英特爾在 Grove 的領導下從 19 億美元增長到 260 億美元的年收入，以及 OKR 如何幫助谷歌成為互聯網上占主導地位的搜索引擎。

但是，OKR 不是靈丹妙藥——我們需要確保我們不會不小心誤用 OKR。 具體來說，OKR 不應取代業務願景或業務戰略。

願景定義了多年來和幾十年業務的總體方向。 OKR 按季度設置，因此植根於日常執行。 如果沒有指導性願景，領導者就無法制定能夠取得有意義的長期進展的 OKR，因為“有意義的進步”的定義正是由願景設定的。

而且，OKR 不能取代業務戰略； 相反，OKR 有助於為戰略注入活力。 真正的戰略需要診斷和一組護欄來推動權衡，而 OKR 專注於執行以實現符合這些預定義護欄的結果。

我們不會深入探討“如何設定引人注目的願景”或“如何制定制勝戰略”，因為這些主題超出了本指南的範圍。 如果您想具體了解有關願景或戰略的更多信息，我們會在 Product Teacher 舉辦關於願景和戰略的企業研討會。

到目前為止，我們已經了解了 OKR 的來源，並且我們對什麼是 ORK 有了一個很好的工作定義。 但是，作為領導者，我們為什麼要使用 OKR 而不是其他方法？

OKR 對領導者的好處

使用 OKR 框架可為領導者帶來五個主要好處：

1. 衡量進展的能力

首先，OKR 鼓勵我們將業務目標明確化為易於衡量的目標。

換句話說，OKRs 是一種強制功能，它讓我們用語言表達我們對業務到底關心什麼，我們為什麼關心它，以及哪些結果很重要。 我們建立問責制和透明度，避免以後“擇優”取得好結果。

假設貴組織的一個關鍵結果是“本季度新客戶獲取率提高 10%”。 如果一個團隊最終“增加了現有客戶的合同價值”，但沒有“增加新客戶的獲取率”，作為領導者，您會立即知道這不是您想要實現的結果。

也許，作為領導者，您已經確定“獲得新客戶”對於推動病毒式增長至關重要，每個新獲得的客戶都會增加您獲得下一個新客戶的可能性。

但是，如果你只讓你的團隊負責“增加收入”，那麼他們會認為“增加合同價值”是增加收入的好方法，而不會理解你想要的戰略是以贏得新客戶為中心。

避免櫻桃採摘對於運行 A/B 測試尤為重要。 任何實驗都可以很容易地在幾十個可能的指標上產生變化，並且當他們的結果實際上未能為客戶創造真正價值時，有人可以輕鬆地選擇“只有積極的結果”來使他們的測試看起來不錯。

因此，通過預先設置成功指標，OKR 可以推動問責制和透明度。

2. 努力實現業務目標

其次，當團隊清楚他們尋求移動的指標時，他們會根據這些指標調整他們的工作。 當團隊指標進入業務目標時，我們可以授權我們的團隊高速做出分散的決策，以幫助業務取得成功。

一旦給定的團隊知道他們將使用哪些指標來衡量他們的進度，我們就可以讓他們決定要運行哪些計劃，哪些人應該在這些計劃上運行，以及他們想要實施什麼樣的流程。 一旦我們的團隊說服我們，他們選擇的指標證明在實現業務目標方面取得了進展，作為領導者，我們就可以擔任顧問角色，而不是執行角色。

作為執行領導者，我們的目標應該是讓所有團隊“緊密結合但鬆散結合”。 換句話說，團隊應該瞄準同一個業務方向，但他們不應該受到行政干預或行政批准的瓶頸。

當領導者感到不得不對每個細節進行微觀管理時，他們的效率和戰略性就會大大降低。 另一方面，當團隊獲得授權並緊密合作時，領導者可以專注於更可擴展地使用自己的時間和精力。

3. 根據學習靈活改變

第三，OKR 可以而且應該根據我們從客戶和我們經營的市場中學到的東西而改變。

在某些方面，團隊可能會決定只有三個關鍵結果對給定目標真正重要； 在其他方面，團隊可能決定他們需要跟踪五個獨立的關鍵結果。

而且，隨著每個業務線按照自己的節奏經歷不同的成熟階段（例如啟動、增長或衰退），我們需要定期重新評估業務目標。

通過 OKR 框架，我們有辦法改變我們的目標和我們團隊的目標，以專注於為我們的客戶和投資者提供最相關、價值最高的工作。

4. 跨越不同層次的能力

第四，OKR 可以跨不同層級進行伸縮； 也就是說，前線的 OKR 可以升級為中層管理人員的 OKR，而中層管理人員又可以升級為高層領導的 OKR。

正如 Doerr 自己在談到他在英特爾工作的經歷時所說的那樣：“看到 Andy Grove 的 [CEO 級別的 OKR]、我的經理的 OKR 以及我的同事的 OKR 對我來說非常強大。 我很快就能夠將我的工作直接與公司的目標聯繫起來。”

OKR 的價值在於它可以在任何層級實施，無論是對 CEO 還是對一線員工。 執行層面的“關鍵成果”流入下一級的“目標”； 並且，一線團隊的成就會回流到執行團隊的成果中。

當 CEO 使用 OKR 集中精力時，他們會清楚地定義公司下一季度的發展方向，並在公司層面製定清晰易懂的目標。

從那裡，各個部門的負責人可以將每個目標轉化為各自職能的目標。 然後，每個職能部門都可以採用這些目標並為他們的團隊創造關鍵成果，然後他們為個人創造他們自己的目標和關鍵成果。

通過在所有級別推動這種伸縮對齊，執行領導可以提供跨職能和資歷的清晰度和激發動力。

5.一致性和標準化

最後，OKR 為我們提供了一種通用語言來指導我們的團隊。 當我們擁有一致性和標準化時，我們最終可以作為一個組織走得更快、更遠。

跨團隊協調是公司成功和失敗的最大放大器之一。 通過授權團隊使用同一種語言，我們可以推動更好的協作、談判和解決問題。

當兩個團隊在 OKR 框架中的目標發生衝突時，他們可以共同修改各自的目標和指標，使他們的進度不再相互衝突，而是相互協同。

例如，假設客戶成功團隊的目標是減少當前客戶的流失，而銷售團隊的目標可能是接觸各種新徽標。

如果沒有適當的 OKR，這兩個團隊可能會發生衝突。 如果銷售團隊引入許多最初購買但隨後流失的新徽標，那麼客戶成功團隊將受到影響。 而且，如果客戶成功團隊強迫銷售團隊在讓他們購買之前對徽標進行資格認證，那麼銷售團隊就會受到影響。

但是，有了 OKR，這個假設的客戶成功團隊可以與他們假設的銷售團隊合作，完善各自的關鍵結果。 客戶成功可以根據“合格客戶的流失”來衡量他們的進展，而銷售可以根據“與新的合格客戶的對話”來衡量他們的進展。

這樣，兩個團隊都不會花時間在無法發現價值的劣質客戶上，從而使整個公司能夠專注於將從他們的產品中獲益最多的客戶。

OKR 對產品管理職能的價值

每個產品都力求為客戶創造巨大價值，以便企業可以為自己獲取價值。 但具有挑戰性的是，產品可以在多個方向實現商業價值，其中一些方向與其他方向相互排斥。

例如，產品是否應該專注於獲得新用戶？ 還是應該專注於推動現有用戶的更多參與？ 也許它應該專注於通過其當前用戶群獲利？ 或者它應該改為從當前收入流中提高盈利能力？

我們需要提前選擇本季度應該解決的目標。 畢竟，專注於這些目標之一通常是以不同的可能目標為代價的：

• 獲得更多用戶可能需要犧牲利潤來為客戶獲取提供資金
• 推動即時利潤可能需要付費牆，這會導致用戶參與度下降

因此，用OKR來指導產品的方向，可以顯著加速產品對業務的影響。

我們如何決定 PM 團隊的 OKR？ 我們可以使用 Miro 的這個 OKR 模板作為起點。 Miro 提供的模板已經預先填充了內容功能和合作夥伴與活動功能的示例。

那麼，讓我們用產品管理示例填充此模板。 假設產品負責人設定了“成為客戶值得信賴的技術合作夥伴”的目標，並取得了以下三個主要成果：

• 增加每個用戶每月完成的平均工作流程數
• 增加每月活躍用戶數
• 增加產品的集成數量

然後，每個關鍵結果都由產品總監領導，產品總監將他們的特定關鍵結果轉化為目標，以指導各自的產品經理。

考慮負責“完成的工作流程”的產品總監。 他們的團隊可能會取得以下主要成果：

• 完成大量 A/B 測試
• 完成一些可用性測試
• 將工作流完成時間加快一定百分比

然後，每個產品經理都會有自己的目標，然後他們會在設計、工程和其他職能部門的對應部門中為他們的產品群創造關鍵結果。

下面是這個特定產品團隊的示意圖：

OKR 學習引擎對 PM 團隊特別有幫助，原因有以下三個：

1. 鼓勵實驗和學習而不是功能交付
2. 通過豐富的客戶背景為自下而上的發現創造空間
3. 為成功提供護欄

首先，產品經理要有實驗能力。 請記住，產品管理就是要最大化優勢並謹慎承擔風險，而項目管理則專注於最小化劣勢； 這兩個學科既相關又不同。

如果我們強迫產品經理進入項目管理模式，他們的唯一目標是在某個已知的截止日期前交付一些已知的功能，那麼產品開發就會轉變為項目交付。 當我們未能為產品經理提供向客戶學習和開展範圍廣泛的實驗的空間時，我們就會導致我們的產品停滯不前，並導致我們的公司落後於那些花時間了解客戶痛點的競爭對手。

附帶說明一下，從傳統項目管理過渡到現代產品管理超出了本 OKR 指南的範圍。 如果您希望開始這種轉型，我們可以通過產品教師提供企業研討會和 1:1 指導。

其次，通過使用 OKR，我們使分散的自下而上的發現成為我們組織內的主要創新形式，而不是在執行領導層阻礙創新。

產品經理往往比行政領導更接近客戶背景，無論是通過客戶訪談、客戶跟踪、客戶反饋分析還是數據分析。 因此，產品經理應該有權為他們的客戶做出產品決策，而不是迫使高管們不得不放棄寶貴的時間來做出戰術性的產品選擇。

最後，OKR 為成功建立了護欄，並將客戶的成功與業務的成功聯繫起來。

畢竟，客戶是“神一般的不滿”，有無數的痛點我們可以為他們解決； 他們的期望隨著時間的推移而增長。 其中一些痛點在解決後，根本不會為企業帶來價值。 因此，確定哪些業務槓桿很重要是一個強大的過濾器，可以幫助產品經理確定正確類型的客戶痛點的優先級。

例如，考慮一個房地產網站，用戶可以在其中輸入地址以獲得估計的房屋估價。 此房屋估價工作流程的假設產品經理可能會確定他們可以通過僅刪除工作流程中的一個步驟來改進“完成工作流程的時間”、“工作流程完成率”或“用戶滿意度”。 此步驟恰好詢問用戶是否願意與房地產經紀人討論他們的需求，並且少數用戶已向客戶支持團隊投訴此步驟對他們來說很煩人。

至關重要的是，此步驟是獲取商業價值的貨幣化步驟。 如果此產品經理刪除此號召性用語，則該產品將不再為業務獲取價值。

有了 OKR，這個假設的產品經理將意識到他們的產品的重點是為業務獲取價值，因此不會嘗試刪除這個工作流程步驟，即使它會為客戶創造價值。 換句話說，即使此 PM 的關鍵結果之一是“客戶工作流程完成時間”，他們也不會為了產品指標的短期收益而犧牲業務的長期生存能力。

我們現在了解 OKR 對產品管理團隊的價值。 而且，隨著公司發現以產品為主導的增長的力量——即使用產品來實現非產品職能（如銷售和營銷）的目標——任何職能的執行領導者都必須了解如何設置穩健的產品 OKR。

建立穩健的產品 OKR

為了幫助您構建適用於您的組織的產品 OKR，讓我們來看看針對目標和關鍵結果的最佳實踐和反模式：

為每個團隊設定一個目標

在實施 OKR 時，我們需要記住，每個團隊一次只能追求一個目標。 雖然不同的目標可以在多個季度中排序，但任何給定的季度都應該只有一個活躍的目標。

例如，我曾經領導過一個面向房地產經紀人的 CRM 移動應用程序，其目標如下：“讓房地產經紀人能夠以更少的努力推動更多的房屋銷售。”

我本可以將此目標分解為三個較小的目標，如下所示：

• 使房地產經紀人能夠通過我們的產品相互協作
• 加強房地產經紀人的在線知名度
• 使盡可能多的低價值流程自動化

但是，如果我最終使用這三個單獨的目標，我就會遇到一個問題：我應該關注哪個目標？ 當團隊在理論上有多個優先級時，他們最終在實踐中的優先級為零。

當然，在領導層面，我們認識到企業必須兼顧多個相互衝突的優先事項。 即便如此，這些優先事項之一對於給定的團隊來說是最緊迫的； 所有其他目標可以安排在未來，也可以分配給不同的專門團隊。

您在本季度尋求實現的目標越多，您必須擁有越多敬業的團隊； 活動目標的數量與團隊數量呈線性關係。 而且，由於每家企業的營運資金都有限，因此每家企業一次只能有這麼多目標。

澄清一下，我們不能忽視現實世界的需求； 相反，我們必須就現在優先考慮什麼與以後優先考慮什麼做出艱難的選擇。

非生產性目標的例子

雖然沒有適用於每個企業和每個環境的普遍良好的目標，但我們應該避免選擇普遍糟糕的目標。

首先，我們應該避免在一個季度內無法取得有意義進展的目標。 例如，如果我們的組織尚未在西班牙開展業務，那麼“成為西班牙的市場領導者”就沒有意義。

相反，我們可以將此目標定義為“了解我們是否可以切實可行地進入西班牙市場。” 通過將目標範圍限定在一個季度內是合理的，我們可以針對目標設定具體的關鍵結果。

其次，我們應該避免設定強制特定產品結果的目標，尤其是在我們不清楚客戶痛點的情況下。

例如，一個非生產性目標可能是“淘汰最少使用的功能以提高利潤率”。 雖然這在表面層面上可能有意義，但我們可能沒有意識到特定的“密碼恢復”功能是一種低使用率的功能，但對客戶來說卻具有極高的價值。

當客戶無法更改自己的密碼並且必須聯繫支持團隊尋求幫助時，他們會感到沮喪並且更有可能轉向競爭解決方案。 即使我們可以節省幾千美元的維護成本，我們也可能會因客戶流失而損失數万美元或更多。

另一個無用的目標可能是“縮小我們的功能集與競爭對手的功能集之間的距離”。 當我們要求我們的團隊追趕競爭對手而不是了解我們自己的客戶時，我們的產品就會偏離解決真正的客戶痛點，並失去為我們的業務獲取價值的能力。

畢竟，我們的競爭對手服務於他們自己的特定客戶群，而我們服務於我們自己的特定客戶群； 每個客戶群都有不同的需求。 因此，我們的業務目標必須植根於我們客戶群的特定環境，而不是競爭對手的客戶群。

如果我們因為不知道客戶有什麼痛點而試圖模仿競爭對手，那麼圍繞發現客戶痛點設定目標比圍繞競爭特性平價設定目標要更有成效。

現在我們了解了好目標和壞目標是什麼樣子的，讓我們討論選擇關鍵結果的最佳實踐。

設置良好的關鍵結果

關鍵結果應該確定團隊是否在選定的業務目標方面取得了進展。 因此，關鍵結果包含三個組成部分：

• 我們正在衡量的指標
• 指標的當前狀態
• 該指標的目標最終狀態

謹防設置便於衡量但與所選目標不一致的關鍵結果。 例如，考慮“為用戶創建更強大的工作流程”的業務目標。 許多團隊可能決定衡量“每月活躍用戶”，因為它很容易檢測和衡量。 然而，“每月活躍用戶”並不是一個可以證明在“為用戶創建更強大的工作流程”方面取得進展的指標。

畢竟，一個團隊可以創建更深入的工作流程，但最終仍會擁有相同數量的月活躍用戶。 或者，一個團隊可以通過提供提高工作流程意識的功能來吸引更多的每月活躍用戶，但該團隊可能無法有意義地深化當前的工作流程。

此外，每個目標應該有 3-5 個關鍵結果。 理想情況下，每個關鍵結果都應該彼此不同，並涵蓋目標的不同組成部分。 超過 5 個關鍵結果可能會導致注意力不集中，而少於 3 個關鍵結果可能會導致失去全面覆蓋。

例如，假設我的目標是“讓房地產經紀人能夠以更少的努力推動更多的房屋銷售”。 這三個關鍵結果可以放在一起說得通：

• 將銷售線索轉化率從 30% 提高到 34%
• 將每個代理商的平均每月房屋銷售額從 1.5 增加到 1.8
• 將房屋價值估算的準確性從 85% 提高到 90%

建立可行的目標

此外，關鍵結果需要有目標——我們不能簡單地衡量一個指標然後就收工了。 為了使我們的團隊能夠執行的目標，它們需要是 SMART 目標：

在設定這些目標時，我們應該鼓勵我們的團隊選擇具有激勵性但並非不可能的延伸目標。

如果團隊有一個他們將在 100% 的時間內實現的目標，他們就沒有理由保持好奇和創新。 但是，如果團隊有一個他們可能只有 20% 的時間可以實現的目標，他們就會感到失望和氣餒，因為他們的目標感覺很遙遠且無法實現。

一個好的經驗法則是 OKR 目標應該可以實現 60-80%。 也就是說，一個團隊自然應該能夠在沒有額外努力的情況下達到 60-80% 的目標，但需要付出一些努力才能達到 100% 的目標。

非生產性關鍵結果的示例

作為領導者，我們需要指導我們的團隊為他們的目標選擇有意義的關鍵結果。

首先，關鍵結果不應該是“虛榮”的結果，即隨著時間的推移自然會出現的結果。 例如，無論團隊在本季度的努力如何，“總觀看次數”或“用戶帳戶總數”只能向上增長。

一般來說，百分比和比率往往是比總數更好的面向結果的目標。 例如，“活躍用戶帳戶的百分比”比“總用戶帳戶”更有意義，因為隨著時間的推移，活躍帳戶的百分比告訴我們產品是否正在為客戶創造持久的重複價值。

其次，我們關注的關鍵結果應該對業務真正重要； 也就是說，關鍵結果應該與客戶價值或用戶價值相關聯。

Logins and views are rarely good choices for key results. When a customer logs in, they haven't received value from the product yet. Similarly, when a customer views a particular page, their pain has likely not been solved yet.

Completed workflows tend to be better measures of customer value than logins or views. And, somewhat counterintuitively, customer interviews tend to be strong choices for key results. By interviewing customers, teams can identify unmet customer pain, which can then guide them towards making valuable product decisions.

Now our teams have a system of objectives and key results in place. But, we still need to set up regular reviews to drive learnings and iterative improvement across the organization.

Reviewing product OKR progress

As leaders and managers, we need to regularly review the progress that our teams have made against their set OKRs, so that we can encourage them to reflect, learn, and improve.

Keep in mind that OKRs are not meant for performance management – you should not encourage promotions or demotions based on OKRs, as that tends to incentivize “gaming the system.” That is, teams will be incentivized to pick a target that will make them look good, rather than selecting a target that truly drives customer learning and business value.

Focus on rewarding teams that demonstrate thoughtful learning rather than thoughtless execution. After all, the teams that learn are the ones that will create long-term value.

We should formally review OKRs with our teams at least once per quarter. Some product-led organizations review OKRs every 6 weeks, and others might review them every 4 weeks. On the other hand, a 2 week cadence for formal reviews is usually not a good use of time.

Furthermore, we should encourage teams to spin up dashboards so that we can check in at any time on their progress without having to schedule a meeting. By encouraging information flow, we spur the organization to move faster and farther.

Using key result goals to drive learning and business growth

The key result goals that teams have set will lead to one of three possible outcomes:

• The team meets 60-80% of the target
• The team exceeds 80% of the target
• The team doesn't achieve at least 60% of the target

If the team meets the target, then they should spend time reflecting on their learnings. Which initiatives and processes were effective? How could the team have achieved better results? Were there surprises that we didn't expect?

If the team overshoots the target, that's 結語

Executive leaders should consider implementing an OKR learning engine to empower their teams to create business value at all levels.

By combining qualitative business objectives with measurable outcomes, you motivate your teams and your direct reports to improve over time.

OKRs should not be rigidly implemented—instead, different organizations will have different best practices around OKRs. Consider which kinds of processes make the most sense for you, whether those are formal executive readouts or lightweight syncs.