文：馬提．凱根（Marty Cagan）

產品目標

概述

我很幸運，在惠普的全盛時期進入公司，以工程師的身分展開職涯。當時大家普遍認為惠普是業界持續創新及執行的例子中最成功、最持久的典範。當時，我加入惠普內部的工程管理培訓專案「惠普之道」（HP Way），學到一套商業目標導向的系統，名為「目標管理」（management by objectives，簡稱MBO）惠普的共同創辦人大衛．普克德（Dave Packard）宣稱：「惠普如今的成就，找不到比MBO貢獻更多的工具了，MBO可說是控制管理的相反模式。」

多年來，幾家公司持續精進及改善MBO系統，其中最著名的是英特爾的傳奇人物安迪．葛洛夫（Andy Grove）。如今，我們使用的商業目標管理系統主要是OKR系統，亦即「目標與關鍵成果法」（objectives and key results，簡稱OKR）。約翰．杜爾（John Doerr）把這個技巧從英特爾帶到剛成立不久的Google。在普克德把惠普的成就歸功於MBO幾十年後，賴瑞．佩吉（Larry Page）也針對OKR流程對Google的貢獻說出了幾乎一樣的評語。OKR概念很簡單，基於2個基本原則：

  • 第一個原則可用巴頓將軍的名言一言蔽之：「不要告訴別人怎麼做事，告訴他們該做什麼就好，他們自然會發揮聰明才智，讓你為之驚喜。」
  • 第二個原則可以用惠普以前的標語道盡：「績效由成果來衡量。」意思是，你推出的功能如果無法解決根本的商業問題，等於沒有解決什麼。

第一個原則，基本上談如何授權及激勵團隊盡全力做好工作。第二個原則，是如何有意義衡量進步。多年來，這行改變很多，但這兩個根本的管理原則依然是頂尖科技公司和團隊固守的基礎。雖然有多種可行的系統和工具可以管理這些商業目標，在本書中，我把焦點放在OKR系統的技巧上。多數頂尖的科技公司使用這套系統多年，已成氣候，目前開始在全球普及。團隊目標的概念可能聽起來直截了當，但在每個產品團隊及組織中有多種制訂目標的方法。組織可能需要經過幾季的執行才會得心應手，找到最適狀態。

OKR技術

OKR技術是管理、專注、調校的工具。就像任何工具一樣，OKR有很多種用法。把這個工具套用在產品團隊時，需注意以下12點：

  1. 目標應該是質化的；關鍵成果需要是量化／可衡量的。
  2. 關鍵成果應該是衡量商業結果，而不是衡量產出或任務。
  3. 公司的其他部門使用OKR的方式略有不同，但是產品管理、設計、技術部門應該鎖定部門的目標，以及每個產品團隊的目標（產品團隊的目標是為了達成部門目標）。別讓個人目標或職能團隊的目標淡化或混淆了焦點。
  4. 為部門找一個合適的節奏（一般而言，部門目標是以每年為基礎，團隊目標是以每季為基礎）。
  5. 部門和每個團隊的目標和關鍵成果數量不能太多（1 到3 個目標最好，每個目標通常有1 到3 個關鍵成果）。
  6. 每個產品團隊必須持續比較進度和目標（通常是每週比較）。
  7. 目標不必涵蓋團隊做的每件小事，但必須涵蓋團隊需要完成的事情。
  8. 要想辦法讓團隊為目標的達成負責。如果他們失敗了，最好找一些同仁或管理者做事後檢討。
  9. 整個部門要認同衡量或評價關鍵成果的方式。這有幾種不同的做法，主要視公司文化而定。重點是整個部門的方法要統一，這樣團隊才知道他們何時可以依賴彼此。以0到1.0的級數來說，級數0是毫無進步。級數0.3只達到基本，亦即你知道自己能達到的程度。級數0.7是指你不只達到基本，還達到你期許自己達到的程度。級數1.0是你達到真正出色的程度，你自己和他人都很驚喜，超乎眾人的期許。
  10. 建立清楚、一致的方法來顯示何時關鍵成果是高誠信的承諾（前面提過），而不是一般目標。換句話說，對多數關鍵成果來說，你應該盡力達到級數0.7的目標。但是高誠信的承諾比較特別，它是二元的，承諾只有履行或沒履行這兩種狀況。
  11. 每個產品團隊努力的目標以及當前的進度都要非常透明化（整個產品部門和技術部門都是如此）。
  12. 管理高層（執行長和高階管理團隊）要為部門的目標和關鍵成果負責。產品長和技術長要為產品團隊的目標負責（並確保團隊實現部門的目標）。每個產品團隊要為上司指派給他們的責任目標，提交出關鍵成果。每季確定每個團隊和部門的OKR時，都會出現一些折衷取捨的流程，那很正常。

關鍵成果應該是衡量商業結果，而不是衡量產出或任務。

使用OKR制訂產品團隊目標

OKR技術的成效很好，尤其是在大大小小的科技產品公司裡。團隊和組織努力提升執行力的過程中，會得到一些非常重要的經驗和啟示。

OKR是一種通用性很高的工具，組織裡的任何人、任何角色、甚至個人生活中都可以使用。然而，就像任何工具一樣，把它套用在某些地方的效果會優於其他的應用方式。在本書中，我強調產品團隊的重要。前面提過，產品團隊由跨職能的專業人員所組成的，裡面通常包括1位產品經理、1位產品設計師和幾位工程師。此外，團隊中有時也包括有專業技能的其他人才，例如資料分析師、用戶研究員、測試自動化工程師。

前面也提過，每個產品團隊通常負責公司產品或科技的某個重要部分。例如，一個產品團隊可能負責司機使用的行動app，另一個團隊負責乘客使用的行動app，還有一個團隊負責安全支付功能等等。重點是，這些擁有不同技能的人，通常來自公司的不同職能部門，但他們每天跟所屬的跨職能團隊坐在一起工作，解決艱難的事業及技術問題。

如果產品部門也採用OKR，可以依照產品團隊的層級套用。

大型組織通常有20到50個跨職能的產品團隊，每個團隊負責不同的領域，每個產品團隊各有自己的目標。公司使用OKR系統時，管理者要求這些團隊解決的問題，是透過產品團隊的OKR來溝通及追蹤。OKR也可以幫忙確保每個團隊與公司的目標維持一致。

此外，隨著組織規模的擴展，OKR日益成為確保每個產品團隊了解他們該為大局貢獻什麼、協調團隊之間的工作、避免重工的必要工具。了解這點很重要，因為組織開始使用OKR時，通常會想讓每個職能部門自己設立OKR。例如，設計部可能有個目標是轉換「響應式設計」（responsive design）；工程部的目標可能是改善架構的擴展性及績效；品管部的目標可能是測試和發布自動化。

問題是，每個職能部門的成員又隸屬於某個跨職能的產品團隊，有產品團隊相關的業務目標（例如降低招攬顧客的成本，增加每日的活躍用戶數，或縮減吸引新顧客的時間），因此團隊中的每個成員可能承擔著部門與團隊上司交代的幾個目標。

試想，工程部要求工程師花時間重新設計平台，設計部要求設計師改用響應式設計，品管部要求品管人員改進工具。這些任務雖然都是有價值的活動，但這些事情不見得可以幫跨職能的產品團隊解決商業問題。這樣的矛盾，往往導致產品團隊的成員，不知道該把時間花在哪裡，因此讓領導者及個別貢獻者感到困惑、無所適從、失望。但這種問題其實很容易避免，那就是讓產品部門也採用OKR，關鍵是把OKR套用在產品團隊的層級中。這表示不要讓職能團隊或個人的OKR混淆議題。

把個人焦點放在產品團隊的目標上。如果不同的職能部門（例如設計部、工程部、品管部）有更大的目標（例如響應式設計、技術債、測試自動化），應該跟其他的商業目標一起放在領導團隊的層級去討論及排列優先順序，之後再併入相關的產品團隊目標中。

注意，對職能部門的經理來說，抱持跟部門有關的個人目標不是問題，因為他們通常不屬於任何產品團隊不會有目標衝突。例如，用戶體驗設計部門的經理可能要負責執行「改用響應式設計」的策略；工程部門的負責人可能要負責執行「管理技術債」的策略；產品管理部門的負責人可能要負責實現產品願景；品管部門的負責人可能要負責挑選測試自動化的工具。

此外，如果個別貢獻者（例如某位工程師、設計師或產品經理）有少數幾個跟個人成長有關的目標（例如累積某方面的技術知識），通常也不是什麼大問題。這是假設個人不至於為了實現個人目標而妨礙了他在產品團隊中的貢獻，畢竟那才是他們的主要職責。重點在於，產品部門內的OKR是層層推移的，需要從跨職能的產品團隊往上提升到公司層級或事業單位的層級。

產品的擴展

概述

目前為止討論了產品願景、策略、商業目標。事實上，在公司的草創時期，沒有這些東西仍然可以存活好一陣子。只要滿足早期用戶的需求，通常可以持續經營很久。不過，一旦公司擴展規模，就需要願景和商業目標。只靠少數幾個產品團隊和工程師開發實用的東西並不難，但若要從中型組織、尤其是大型組織獲得卓越的成果，挑戰真的很高。

此外，公司擴展規模後，原始的共同創辦人可能已經離開，留下空缺。產品團隊需要有人遞補。少了這塊，產品團隊幾乎不可能做出好的決策及開發出好東西。這種問題的徵兆通常是以士氣低落、缺乏創新、運作速度減慢的形式出現。

使用OKR擴展產品目標

OKR系統是可擴展的。我認為使用管理及調校任務的工具對有效擴展非常重要，但很多公司確實在擴展OKR的使用時遇到困難。本章將說明，擴展OKR系統的使用時，需要做什麼改變。注意，這裡只談產品和技術部門（亦即產品管理、用戶體驗設計、工程部門等等），雖然你可以把我說明的技術套用在任何規模上，但這裡主要關注成長階段的公司或大企業。

清楚了解組織層級的目標

公司草創時期或規模還小時，每個人基本上都知道其他人在做什麼，以及為什麼那樣做。這時每個產品團隊都提出自己的目標和關鍵成果是很正常的，這會出現一些折衷取捨，接著大家才開始運作。但是組織規模變大時，產品團隊需要更多的協助。他們需要的第一個協助是，清楚了解組織層級的目標。假設公司的兩個首要目標是提高顧客的終身價值，以及在全球拓展事業。假設你有25 個產品團隊，所有的產品團隊可能對這兩個組織目標都有想法，但顯然公司需要精明地規畫哪個團隊追求哪些目標。有些團隊可能只專注追求一個目標，有些團隊可能要兼顧兩個目標，還有一些團隊負責處理兩個目標以外的重要工作。領導（尤其是產品長、技術長、設計長）需要討論公司的目標，以及哪些團隊最適合實現哪個目標。

確定執行的協調性與利益能相互呼應

公司的規模一大，許多產品團隊支援其他產品團隊是很常見的現象。這些支援團隊通常稱為平台產品團隊或共用服務產品團隊。他們有高度的共用性，但又和一般的產品團隊有點不一樣，通常不是直接服務顧客，而是間接服務顧客，通常是透過更高層級、方案導向的產品團隊。這些平台團隊可能會收到多數或甚至所有較高層級產品團隊的要求，它們的任務是協助那些產品團隊成功。但領導高層還是要幫這些團隊協調目標，確定相依性協調妥當，彼此的利益相互呼應。
從提交成果中找出落差與優先順序

一旦有了目標，會出現一個非常重要的調整流程。在那個流程中，領導團隊會注意產品團隊提交的關鍵成果，找出目標與成果的落差，然後思考怎麼調整來消除落差（例如，徵召其他的團隊來協助，或檢討工作的優先順序）。

串連工作任務

公司的規模一大，很難知道產品團隊正努力追求哪些目標以及它們的進度如何。現在有很多線上工具，可以幫組織把目標透明化。但即使有那些工具，仍要靠管理高層把那些團隊串連起來。

積極追蹤與管理進度

組織愈大，高誠信的承諾項目愈多，那些項目需要積極管理和追蹤。交付經理在追蹤及管理這些相依性和承諾方面扮演關鍵要角。

領導者和管理高層責任增加

許多大企業裡，基本上分成數個事業單位。這種情況下，應該會出現公司層級的OKR，但也會有事業單位層級的OKR，那是由產品團隊的OKR彙整而成。總之，大規模使用OKR時，領導者和管理高層肩負組織協調一致的責任更大，也需要確保每個產品團隊都了解如何融入組合中，以及該貢獻什麼。

本文摘錄自《矽谷最夯・產品專案管理全書：專案管理大師教你用可實踐的流程打造人人都喜歡的產品》

作者：馬提．凱根（Marty Cagan）
譯者：洪慧芳

責任編輯：潘柏翰
核稿編輯：翁世航



Source
列印