《什麼才是最難的事？》收錄一則“產品經理指南”[註1]，內容主要界定好壞PM的標準。該篇指南緣起於作者Ben Horowitz當時任職Netscape產品經理部主管（現任安霍創投合夥人），發覺部屬各自表述工作職掌，沒有統一做法，才領悟到業界從未有人明確定義產品經理的職責。為了進行內部訓練，寫下這篇流傳一時的文章。
由於我不太理解書裡的部分語意，決定自己動手潤飾。以下翻譯比對過原文，並參考、融合《什麼才是最難的事？》的版本和對岸的翻譯。
Warning: This document was written 15 years ago and is probably not relevant for today’s product managers. I present it here merely as an example of a useful training document.
以下是15年前的文章，觀點可能不符合時下PM的定義。我分享的目的，僅在示範何謂有用的訓練文件。
Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. A good product manager is the CEO of the product. A good product manager takes full responsibility and measures themselves in terms of the success of the product. They are responsible for right product/right time and all that entails. A good product manager knows the context going in (the company, our revenue funding, competition, etc.), and they take responsibility for devising and executing a winning plan (no excuses).
好的PM相當熟悉市場、產品、產品線，以及競品，具備紮實的知識與強大的信心運籌帷幄。好的PM是產品的執行長。好的PM當責，以產品的成功來衡量自身的表現。他們負責判斷出正確的產品、正確的時機，以及其他要件。好的PM清楚切入市場的脈絡（公司現況、營收、競爭對手等等），並負責規劃和執行產品計畫，不找藉口。
評：
先前常在書籍、網路文章看到類似“PM是產品的執行長”這樣的說法。當時認為這句話有道理，但又覺得不太正確。
最近翻閱PMP的資料、觀看線上課程，才發現問題出在哪裡。PM職務會因為組織架構而有差異，同樣是PM的職銜，工作內容可能天差地遠。所以“PM是產品的執行長”這句話若要成立，還有附帶條件－“權”與“責”必須對應。
最貼切的詮釋是在專案型的組織，也就是為了專案成立一組團隊，在專案期間由PM帶領，PM同時擁有管理、考核組員的權力。團隊成員直接回報PM，PM對上、對外負責。像以上的情況，PM擁有完整權限，“權”與“責”才能互相對應，PM自然形同產品的執行長，肩負完全的成敗責任。
Bad product managers have lots of excuses. Not enough funding, the engineering manager is an idiot, Microsoft has 10 times as many engineers working on it, I’m overworked, I don’t get enough direction. Barksdale doesn’t make these kinds of excuses and neither should the CEO of a product.
差的PM藉口一堆：預算不足、工程主管是白痴、微軟有10倍的開發人手、我的工作量太多、方向不明確。Barksdale（曾任 Netscape 的執行長）不曾說過這些藉口，當然產品的執行長也不應該有。
評：
慣性抱怨者的主要問題，在於只有碎嘴，心態陷於被動，沒有解決問題的意願和具體行動，所以只能屈服於現狀繼續抱怨，形成惡性循環。這點不光可以用來評判PM，也適用於其他職務。
Good product managers don’t get all of their time sucked up by the various organizations that must work together to deliver right product right time. They don’t take all the product team minutes, they don’t project manage the various functions, they are not gophers for engineering. They are not part of the product team; they manage the product team. Engineering teams don’t consider Good Product Managers a “marketing resource.” Good product managers are the marketing counterpart of the engineering manager. Good product managers crisply define the target, the “what” (as opposed to the how) and manage the delivery of the “what.” Bad product managers feel best about themselves when they figure out “how”. Good product managers communicate crisply to engineering in writing as well as verbally. Good product managers don’t give direction informally. Good product managers gather information informally.
好的PM不會花費大量時間巴結本該做好工作、準時交付成果的相關部門。他們不會一直佔用產品團隊的時間，不會逐個功能管理，不是工程團隊的小跟班。他們不是產品團隊的一員，而是產品團隊的經理人。好的PM在工程團隊眼中不是“行銷資源”[註2]，在工程主管眼中是具備行銷能力的好夥伴。好的PM明確定義目標，重視“結果”而非達成的“方法”，並且管控結果的產出；差的PM一想出方法就自我感覺良好。好的PM無論透過文件或口頭說明，都能跟工程團隊清楚溝通。好的PM公開下達指示，私下搜集資訊。
評：
為了確保交付物的品質無虞，PM需要與開發團隊討論出合理的允收準則，若是任務範圍偏大，還要分階段設定驗收的里程碑，同時協助專案成員排除困難。為了確保團隊認知同步，良好的工作方法是確實紀錄討論結果，並知會成員。
Good product managers create leveragable collateral, FAQs, presentations, white papers. Bad product managers complain that they spend all day answering questions for the sales force and are swamped. Good product managers anticipate the serious product flaws and build real solutions. Bad product managers put out fires all day. Good product managers take written positions on important issues (competitive silver bullets, tough architectural choices, tough product decisions, markets to attack or yield). Bad product managers voice their opinion verbally and lament that the “powers that be” won’t let it happen. Once bad product managers fail, they point out that they predicted they would fail.
好的PM會準備好附加的參考資料、常見問答集（FAQs）、簡報、白皮書；差的PM抱怨整天忙得焦頭爛額回答銷售人員的疑問。好的PM能預先察覺產品的重大瑕疵，並提出有效的解決方案；差的PM整天忙著救火。好的PM會在重要議題留下書面紀錄，比如絕妙的構想、關鍵的產品架構、關鍵的產品決策、攻佔或退出市場；差的PM只會嘴巴上講一講，感嘆想法被高層否決，失敗了就推說早知如此。
評：
上述段落是我看完這篇文章最大的收穫。因為PM最清楚整個專案的輪廓、產品規格，所以PM是最適合撰寫正式文件的人選。文件寫好之後不是放著好看，除了持續維護內容，最好在關鍵時間點主動安排教育訓練，加速相關業管接軌。
總之，PM應該預作準備，主動出擊。
文字能力是PM的必備項目之一，除了溝通時會大量使用，重要事件的文字紀錄，可以幫助內部做好經驗傳承。依照過往經驗，如果沒做公開紀錄，寶貴的經驗通常只會存留在當事人的腦海裡，不會轉化為共享資源，所以再利用價值很低。而且人的大腦好用歸好用，卻不太可靠，當下如果沒妥善記錄，遲早被時間沖淡記憶。
做好經驗傳承（lessons learned）有很多好處，最起碼能避免類似的錯誤一再發生。
Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).
好的PM要團隊以營收和客戶為重；差的PM要團隊關注微軟開發了哪些新功能。好的PM認為只要努力就能成功研發出好產品；差的PM則認為做出好產品的機會渺茫，或放任工程師著手他們想做的事，比如解決最難的問題。
評：
只談“以客為尊”的PM沒有想到獲利的大前提。如果營利事業已經命在旦夕，是要如何提供優質服務？所以不是客戶要什麼就給什麼。
Good product managers think in terms of delivering superior value to the market place during inbound planning and achieving market share and revenue goals during outbound. Bad product managers get very confused about the differences amongst delivering value, matching competitive features, pricing, and ubiquity. Good product managers decompose problems. Bad product managers combine all problems into one.
好的PM懂得遠慮，在規劃階段思索能通過市場考驗的價值主張，產品推出後則思考搶下市占、達成營收目標的方法；差的PM思考能力有限，搞不懂“價值主張”和“有競爭力的產品特性”之間的差異，也會混淆“訂價”和“普及性”這兩個概念。好的PM會拆解問題，抽絲剝繭；差的PM會攪和問題，剪不斷理還亂。
評：
規劃階段PM可以藉由質性、量化的方法挖掘需求，收斂出產品的關鍵價值主張。開發過程中平衡專案時程與交付成果的品質。上線後透過數據、偵測工具檢視表現，再綜合所有能取得的事實根據發想洞見，必要時修正價值主張，並取得內部共識。
要做好以上環節，需要綜合能力的展現，其中串穿全部的正是邏輯思考。
Good product managers think about the story they want written by the press. Bad product managers think about covering every feature and being really technically accurate with the press. Good product managers ask the press questions. Bad product managers answer any press question. Good product managers assume press and analyst people are really smart. Bad product managers assume that press and analysts are dumb because they don’t understand the difference between “push” and “simulated push.”
好的PM會先設定好新聞效果、想要媒體報導的內容；差的PM會希望媒體鉅細彌遺且正確地介紹產品的每個特性。好的PM主動詢問媒體；差的PM回答媒體所有疑問。好的PM認為記者和分析師很聰明；差的PM認為記者和分析師都是蠢蛋，只因他們分不清楚專業術語的細微差異。
評：
玩運彩的PM不需跟媒體交手，但這段話還是有值得借鏡之處－主動性。好的PM主動出擊，選擇做對的事，並且把事情做對。
Good product managers err on the side of clarity vs. explaining the obvious. Bad product managers never explain the obvious. Good product managers define their job and their success. Bad product managers constantly want to be told what to do.
好的PM有囉唆的毛病，連顯而易見的事情也會解釋清楚；差的PM凡事含糊，剛好相反。好的PM主動界定自己的工作和成功的標準；差的PM等候別人指示。
評：
為了確保團隊成員的認知同步，而且釐清所有模糊地帶，確實有必要頻繁的溝通，不厭其煩地說明，並且再三確認。這麼龜毛的目的是避免重工和非必要的錯誤，尤其收拾善後可能要付出龐大代價。
Good product managers send their status reports in on time every week, because they are disciplined. Bad product managers forget to send in their status reports on time, because they don’t value discipline.
好的PM每週準時遞交進度報告，嚴格自律；差的PM無法準時繳交，忽視紀律。
評：
不只PM需要嚴格自律，多數我們能想到的職務只要缺乏自律，出包率通常偏高。時間一久，容易給人“散漫”的負面印象。
整體來說，我不完全同意這篇指南的觀點，原文部分內容也跟我目前的工作無關。不過我很欣賞作者在擔任產品經理主管期間，主動定義原本處在模糊地帶的PM職掌。
說真的，PM的工作內容也許因為產業、公司性質、組織架構而有差異，但相較於技術職，缺少顯而易見、直接指向成果的產出，這是先天上的弱勢，也能解釋為何當專案成功，PM要先歸功於團隊成員，畢竟再怎麼完善的規劃，還是要靠強力的執行者和合作無間的團隊來落實。
再來是PM的職權。在非專案型的組織中，PM若無考核權、管理權，要讓專案照著預期進行，並非易事，比方時程會很難掌控。當然，也有強人可以做到出色的“虛位領導”，在缺乏職權的劣勢下，還能帶領團隊實現超乎期待的成果。不過這是非常高階的心法，前提是取得團隊信任和尊敬，當事人需要強大的專業能力、人和與主動奉獻的行動力，有策略地找到切入點並逐步做出團隊有感的成績，才能不靠職權建立實質的影響力，否則不太可能達到這般境界。
這篇指南雖然歷史悠久，對於我近期正在著手撰寫的PM手冊，仍有很高的參考價值。
[ 註1 ]
原文：Good Product Manager / Bad Product Manager
[ 註2 ]
另一份Ben Horowitz and David Weiden共同撰寫的文件《Good Product Manager Bad Product Manager》提到，差的PM會狹隘的定義自己的角色為“行銷資源”，工作內容不外乎編寫數據資料、新聞稿、取得客戶回饋等等。
Photo by Carl Heyerdahl on Unsplash