《產品專案管理全書》產品專案經理必備聖經
過去 2011 年 v.s. 現在 2019 年
Marty Cagan 是當前科技類專案管理方面公認的意見領袖。他曾在惠普、網景、eBay等全球最成功的公司擔任高階管理者，負責定義、打造產品。後來創辦矽谷產品團隊公司（SVPG），擔任許多知名公司的產品教練與顧問。2019年受邀至台灣分享產品思維，也是本書的重點精華。
2011年第一版《啟示錄 打造用戶喜愛的產品》，那時 Agile 還不是產品的常用流程，許多現今常見的科技術語，例 Lean Startup、OKR等也尚未普及。現在產品設計師和工程師都可以找到很多、很棒的學習資源，但專為科技產品的產品經理量身打造的資源卻很少，第一版偏重新創公司，第二版則聚焦在科技產業的產品經理。
《矽谷最夯‧產品專案管理全書》(KOBO)將從人才、流程、產品三大面向，以及搭配產品怪獸公司 ( Google、Adobe、Netflix等）產品經理的經驗，幫助我們塑造產品思維。
產品沒有市場價值，也是枉然
這張圖對科技、網路、專案公司來說，應該是非常熟悉的流程。世界各地的公司，不分大小，基本上都採取同樣的運作方式。但是！這種流程方式跟世界上最卓越的公司截然不同。
年度計畫就是這樣產生的！
起頭來自於「創意」，在大多數公司，創意來自內部 ( 高層、老闆) 或外部 ( 當前或潛在客戶 ) 。再來根據商業論證 ( Business Case ) 選出哪些創意是路徑圖中的優先要務，並且預測時麼時候可以完成。白話一點，就是這些創意可以賺多少錢或創造多少價值？需要投入多少成本或時間？
這起頭是不是很熟悉呢？從整體來看可以發現什麼是產品失敗的罪魁禍首：
- 創意源頭不含用戶、顧客導向思維
- 現實冷酷的真相是，不可能知道創意最後會賺多少錢、成本是多少
- 思考產品時的第一個現實是，至少有一半的創意是行不通的 ( 書中提到真正的優秀團隊認為，至少有四分之三的創意想法不會如願奏效 )
跑敏捷，開發速度一定很敏捷！
公司故事繼續往下走，接著產品經理跟利害關係人溝通創意的具體內容，得出「完整」的需求 ( Requirement ) ，產出為了跟設計師和工程師溝通「需要打造什麼產品」的 Spec。設計產出互動和視覺設計，與工程團隊開始合作 ( 咦好像是交棒 )，工程師進行 Agile 跑 Sprint，完成後提供給 QA 測試( 有些沒 QA ， PM 下海探索測試 )。 最後超過預估的日期，老闆或客戶就會抱怨時間拖得太長， PM 沒管理好時程，團隊動作太慢。
這段很常見的流程，是否可以清楚看出為什麼往往導致多數產品失敗了：
- PM 工作只是「收集需求」及「記錄需求」
- 產品開發到最後才把設計師找進來，設計師只能盡量讓需求看起來美美的
- 只是把工程師當成寫程式的工具 ( 書提到也是我真實感受，工程師通常是最好的創新來源，他們接收新技術資訊速度比 PM 、設計師快很多 )
- 咦別騙我，這根本是瀑布式開發啊
- 產出爹 ( 老闆 )不疼、娘 ( 客戶 ) 不愛的孤兒專案，專案導向是只注重產出 Output ，但產品完全是看結果 Outcome
- 顧客驗證 ( Customer Validation ) 的風險集中到最後
- 最後若用戶不買單，則浪費時間和金錢，還有青春的機會成本損失
創造優秀產品傳教士團隊
產品團隊不是傭兵團隊，而是為了幫事業解決難題而存在。
產品團隊有時也稱為專業產品團隊 (Dedicated product team) 或持久產品團隊 (Durable product team) ，強調不是為了某個專案或功能組成的團隊或任務小組，而是跨職能的團隊，是產品願景的信徒，致力為顧客解決問題。
沒有規定跨職能團隊必須有哪些角色，但確實有最低門檻概念，通常包含1位產品經理、1位設計師和2名工程師，視產品規模大小而定。 貝佐斯（Jeff Bezos）提出「兩個皮薩原則（Two-pizza rule），就是把團隊規模維持在這個範圍內。
確定團隊目標和組合後，接下來則是每個團隊職責是什麼？可分成兩個面向，一個面向是工作類型，產品團隊必須對產品的一切活動負責，包括所有專案、功能、問題修復、績效、改良、內容更改等。另一面向是工作範圍，如今大型產品常見的是，產品是完整個顧客體驗（例Facebook），每個團隊各自負責體驗中的某一塊，每一塊雖小，但很有意義。
想建立傳教士團隊，必須讓團隊擁有自主性，可以用自己覺得合適的方式，去解決公司指派的任務。最重要的事，整個團隊都對結果產生責任感。
當個好產品經理好難
正在閱讀此文章的人，大多數為產品經理，此本書也是談如何成為卓越的產品經理，在這段落我針對產品經理分享較多內容，書中有再多介紹產品設計師、工程師職責內容。
作者把醜話講在前頭，首先先釐清現在你的角色是哪一種產品經理？
- 產品經理把每個問題和決策都往上提報給執行長知道， PM 其實只是待辦清單的管理員。
- 產品經理可以招開會議，使所有利害關係人齊聚一堂討論出結論。這種委員會設計（Design by commitee），得出來的結論往往很平庸， PM 其實只是路徑圖管理員。
- 產品經理可以做自己的工作。這是作者想說服我們相信的第3種工作方式。
產品經理關鍵職責
產品經理的職責，他負責評估機會，決定該為顧客打造什麼產品的人。我們常在產品待辦清單（Product Backlog）中描述該開發什麼。聽起來很簡單，方式並不難，真正困難的是確保產品待辦清單上的內容都值得開發。優秀的產品團隊裡，工程師和設計會想要看到那些證據，你要求他們打造的產品真的值得開發。
產品的成功，是團隊中每個人都做了他們該做的事。但產品的失敗，錯誤都歸咎於產品經理。
所以卓越的產品經理有4大責任，整個團隊都依賴這些特質：
- 深入了解顧客：你需要成為熟悉故客的專家，對顧客的問題、痛苦、渴望、想法暸若指掌。想要深入了解顧客，需要質化與量化的學習。質化學習是了解用戶和顧客為什麼有那些行為，例如用戶訪談、焦點團體法；量化學習是了解顧客在做什麼，例數據分析。
- 深入了解資料：其實就是所謂「了解顧客」的前提，大部分是了解他們如何使用你的產品。產品經理每天上班第一件事，是花半小時左右使用分析工具，了解過去 24 小時發生了什麼。主要看銷售分析資料、使用分析資料、 A/B 測試的結果。
- 深入了解事業和利害關係人：成功的產品不僅廣受顧客喜愛，也推動公司的事業發展。這是許多產品經理認為最難產出的貢獻，是對事業、事業的運作方式、產品在事業中扮演的角色有深入的了解。表示你要知道公司的各種利害關係人是誰（執行長、管理高層、業務、行銷、財務、法律、事業發展、客服等），尤其是了解他們面臨的限制。
- 深入了解市場和產業：不僅需要了解競爭對手，還要熟悉科技趨勢、顧客行為和預期，密切追蹤相關的產業分析，了解社群媒體對你的市場和顧客的影響。
團隊交付出結果，而非產出
本書強調的是鎖定結果（Outcome），而不是產出（Output）。典型的產品路徑圖都談產出，然而優秀的團隊需要交付的是商業結果。
再進入團隊要做什麼之前，先了解本書是以「獲得授權的產品團隊（Empowered product team）」為基礎，團隊本身有能力為公司指派給他們解決的商業問題想出最好的解決方案。因此團隊不是丟個產品路徑圖，跟他們說打造什麼功能而已，而是把路徑圖每個項目寫成「該解決的商業問題」，產品團隊要有必要的商業情境（Business context），需要紮實了解公司走向，也需要知道團隊該如何為大局目標做出貢獻。以科技公司來說，商業情境是由2個重要組件提供：
1. 產品願景（Vision）和策略（Startegy）：
產品願景描述努力創造的未來，整個組織想達成的大局以及達成那個願景的計畫，通常是指 2 到 5 年後的未來，請注意這和公司的使命宣言（Mission）不同。主要目的是為了傳播願景，以及激勵團隊（和利害關係人、投資者、合作夥伴，或潛在顧客）幫忙實現這個願景。
Facebook
Mission：賦予人們建立社區的力量，讓世界更加緊密。
Vision: 人們使用 Facebook 與朋友和家人保持聯繫，了解世界上正在發生的事情，分享和表達對他們來說重要的事情產品策略是為了逐步實現產品願景，而打算推出的產品或版本序列（可能是相同產品的不同版本，或是一系列不同或相關產品。
願景和策略的差異，就像卓越領導和卓越管理的差異。領導是負責啟發與指引方向，管理則是幫我們達到目的。最重要的事，產品願景應該要有啟發性，產品策略則應該聚焦。
2. 商業目標：
描述每個產品團隊是為優先要務的具體商業目標。如今，我們使用的目標管理主要是 OKR ，亦即「目標與關鍵成果法（Obejectives and key results）」。
OKR 概念很簡單，基於 2 個基本原則，詳細內容可以參考相關書籍：
- 如何授權及激勵大家盡全力做好工作
- 如何有意義地衡量進步
當要把 OKR 套用在產品團隊時，須注意幾個重點：
- 目標應該是質化的；關鍵成果需要是量化 / 可衡量的
- 關鍵成果應該是衡量商業結果，而不是衡量產出或任務
- 產品團隊必須持續比較進度和目標（通常是每週比較）
- 要想辦法讓團隊為目標的達成負責
- 產品團隊努力的目標以及當前的進度都要非常透明化
產品團隊如何運作？
對多數的團隊來說，有兩大挑戰（目標）需要解決。經驗來說多數的產品團隊比較知道如何達成第 2 個目標（交付紮實的軟體），但不知道如何達成第一個目標：
- 該打造什麼產品（Build the right product），稱之為「產品探索 (Product Discovery) 」
此本書會強調產品探索技術，因為關注的重點是產品經理，產品探索是他們的主要職責。產品經理需要把多數時間放在與產品團隊、關鍵的利害關係人、顧客合作上，找出顧客喜愛又適合事業的解決方案。但產品經理和產品設計師需要確保：通常每天花半小時到一小時時間回答工程師在交付活動提出的問題。
產品探索的目的是為了解決這些關鍵風險：
- 價值風險（Value）：顧客會購買或決定使用嗎？
- 易用性風險（Usable）：顧客知道如何使用嗎？
- 實行性風險（Feasible）：能打造出來嗎？
- 商業可行性風險（Viable）：這個方案有助於事業發展嗎？
2. 交付完整的產品（Build the product right），也就是「產品交付（Product Delivery)」
是工程師有自信且讓我們的事業可以靠譜的產品。需要符合的條件是：
- 穩定 (reliable)
- 可擴展 (scalable)
- 高效能 (performant)
- 可維護 (maintainable)
- 支援多國語言又在地化 (internationalized and localized)
產品探索技術（Product Discovery）
做產品最困難的一點是「最後產出的方案是否能解決用戶問題產生價值」，現實上並沒有時間讓團隊真正「想出」一個可行的解決方案。建議花最快、最便宜方式做規劃，用幾個小時產出原型設計（Prototyping）進行探索驗證原型是否可行，最後才正式進入產品交付的開發階段。
作者介紹了許多實用的產品探索技術，這邊介紹幾個常見的技術：
機會評估（Opportunity assessment）
是為絕大多數產品工作設計的，範圍曾簡單的功能改善到中型專案都適用。主要能夠針對你即將展開的探索流程，回答 4 個關鍵問題：
- 這個任務是為了達成什麼商業目標？（目標）
- 你怎麼知道目標達成了？（關鍵結果）
- 這可以幫客戶解決什麼問題？（顧客問題）
- 我們關注哪種顧客？（目標市場）
客戶信（Customer letter）
是為大型專案或計畫設計的，這些案子通常有多個目標及比較複雜的期望結果，需要解決好幾個顧客問題或商業目標。為了有效溝通價值，產品經理不只要回答機會評估的 4 個問題了。
書中以 Amazon 為例子，他們持續創造出顛覆性的創新發明，除了企業文化、人才濟濟外，打造產品時還會採用一些關鍵技術，其一是所謂的「倒推法（Working backward process）」，亦即從假裝發布新聞稿開始往回做。有一位員工長年在 Amazon 任職，跳槽到諾斯壯百貨調整成客戶信的方式。
新聞稿：產品經理撰寫一份想像的產品上市新聞稿，讓產品團隊知道他們需要交付的東西。這個產品如何改善顧客的生活？對他們有什麼真正的效益？
客戶信：那封信是由對公司非常滿意及印象深刻的假想顧客寫給執行長，說他真心對新產品或重新設計感到滿意、太感激了，並描述那個新產品如何改變或改善他的生活。此外，那封信也附上執行長寫給產品團隊的虛構祝賀信，信中提到產品團隊的貢獻如何促進事業發展。
創業圖（Startup canvas）
是為開發全新的產品現或一個新事業而設計的。在這種情況下，將面臨更廣泛的風險，包括驗證價值主張、想出獲利的方式、規劃把產品賣到顧客手中的方式、計算生產及銷售產品的成本、以及選擇用來追蹤進度的衡量指標，還有判斷市場是否大到足以支撐一個事業的發展。
創業圖以及近似的商業模式圖（Business model canvas）和精實圖（Lean canvas），都是為了儘早發現這些風險，以鼓勵團隊提早解決風險的輕量級工具。
用戶故事對照圖/旅程地圖/體驗地圖（User story/journey/experience map）
一來說是一種二維圖，橫軸是放主要的用戶活動，那是按時間順序從左到右籠統地排列。縱軸是按照細節的細膩度排列。當我們為每想主要活動增添內容、把它變成一組用戶任務時，我們會為每個任務增添故事。
如今大型品牌企業通常会把用戶體驗地圖作為設計商業流程的必要環節，如 IDEO 、eico、星巴克、樂高、 Ikea 等。
我們可以使用這個故事對照圖來建構原型。得到一些原型的意見回饋，就可以輕易更新故事對照圖，即時反應原型的狀態。探索流程結束後，進入交付流程時，圖上的故事既直接轉為產品待辦清單。
許多團隊把逼真的用戶原型和故事對照圖視為技術首選。
顧客訪談
有很多形式，不是單一的技術。有些背後有用戶研究方法為基礎（例脈絡訪查（Contextual inquiry）），有些訪談則是純粹走出辦公室去了解你不知道的事情。但對任何產品經理來說，顧客訪談無疑是最強大、最重要的技能之一，許多突破性產品創意的來源或靈感出自於此。
現在有很多方法可以得到這些答案，如果有用戶研究員通常可以跟他們一起探索，以下是盡量充實知識的一些秘訣：
- 頻率：建立定期的顧客訪談，每週至少要做 2 、 3 小時個顧客訪談
- 目的：訪談期間，不是要你用什麼方法證明什麼，只是想迅速了解及學習
- 地點：觀察顧客的原生環境，可以學到很多東西
- 誰該參與：讓團隊裡的 3 個人參與訪談：產品經理、產品設計師、團隊裡的工程師（工程師輪流出席）。訪談通常是由設計師發問（因為他們通常受過這方面的訓練），產品經理做筆記，開發人員仔細觀察
- 訪談：努力讓訪談保持自然且非正式，問一些開放式問題
創意日/黑客松（Hack days/Hackathon）
分兩種主要類型，有方向的、無方向的。在無方向的自由創意日中，參與者可以探索他們喜歡的任何產品創意，只要概念至少跟公司使命（Mission）有關就行了。在有方向的創意日中，則有一個顧客問題（例如「某種東西真的很難學會」），或指定的商業目標（例如「減少顧客流失率」）。公司要求產品團隊的人自行組織及開發概念，以實現那個目標
原型測試（Prototypes）
你將展示 prototypes 給不同類型的用戶、顧客、利益關係人，你將會在團隊中測試它們，這才是產品經理與設計師的真正工作。這也是為什麼我們需要真正的 「產品設計師」。
再強調一次，所有的 prototypes 都不是真正的、完整的產品。除此之外，有 4 種不同類型的 prototypes，所有優良的產品團隊都要善用，來面對不同的工作、處理不同的風險。有些專門用來量化測試，有些則用來質化測試，所以優良團隊都需要做這些。
- 實行性原型 (Feasibility Prototypes)
- 用戶原型 (User Prototypes, Low-Fidelity or High-Fidelity)
- 即時資料原型 (Live-Data Prototypes)
- 混合原型 (Hybrids)
原型的目的是為了更深入了解用戶和顧客，也是找出原型中的缺點以便修正。一但你認為找到問題了，就要修正圓形。沒有人規定一定要用同樣的原型來測試所有參試者。我們做這種測試不是為了證明什麼，而是為了迅速獲得心得。
「你要有扔掉原型的打算，總之，你一定會扔掉的。」 — 圖靈獎得主、《人月神話》作者 佛瑞德．布魯克斯
總結
對於未來想從事產品經理的 PM 來說，此書真的是大補帖，作者將自身紮實的產品開發實務經驗，結合其他的業界最佳實務為例，系統化地整理出如何開發一個卓越好產品的方法，從人才、流程，到組織文化詳細敘述。
如果你現在已是產品經理，此書絕對是必讀的聖經，依然可以帶給你不同的思維與觀點，無論哪個時期，都能以不同的角度來回顧一下過去所走的方向。
謝謝你的閱讀，如果有希望我分享的書籍或經驗，歡迎留言給我。
如果能給我一些鼓勵，請給我 1–10 個拍手👏
如果覺得文章有幫助到你，請給我 11-30 個拍手👏
如果想看更多文章，請盡情按住拍手（Max 50）讓我們知道 👏
