【摘錄一】
第11章：敘事性寫作（The Written Narrative）
上一章講述了一對一教練的重要性。那個方法可以提供不間斷的機制，協助產品開發人員發揮潛能。在本章，我要探討的是本人最鍾愛的教練工具：敘事性寫作，這有助於造就不同凡響的產品開發人員。
先承認，在我運用的各種技巧當中，敘事性寫作最讓人心生抗拒。事實上，有些人基本上是受我強迫才使用這項技能。他們並不是懷疑它的效用，而存粹是對它深感痛苦。而且我發現，最有必要熟練說故事技能的人，往往是那些最抗拒它的人。
產品開發人員（尤其是產品經理），必須隨時都能提出論點來應對爭議。雖然這在小事上不常見，但在面臨代價高昂、風險重大的事情時，例如大型功能開發與專案（尤其是重大的新嘗試），自然會有許多人提出疑問和挑戰。在這種情況下，一般是要應對公司各主管的質疑，而這往往要從說服團隊成員著手。
本章的教練方法是，要求產品開發人員寫一篇敘事文章，闡述他們的論點和建議。先說明，我講的不是任何詳細說明文件。那類文件的用意不是要說服人，只是用來描述想要打造的產品相關細節。
我談論的是大約6頁的文章，內容以說故事手法講述產品開發人員力圖解決的問題、為什麼這對客戶和公司具有價值，以及提出解決問題的策略。如果寫得斐然成章，讀者將獲得啟發並被你說服。
亞馬遜公司就是以這種說故事手法為核心，闡述他們如何營運與創新。亞馬遜比我所知的任何公司更加擁護敘事性寫作，我想亞馬遜能成為全球最具持續創新能力的公司之一，絕非偶然。
產品開發人員在工作起始會議上舉手發言、拋出一些數據點，使自己看起來熱衷而且有自信，並不是件困難的事。這種會議如同委員會設計（design by committee，是指專案有多人參與設計，卻沒有一致的計畫或是看法）那樣糟糕，每個人深受挫折，最後只會向會議室裡最高薪的人尋求指引。
當發生這種狀況時，我很清楚產品開發人員沒有做好必要的功課、未能真正理解會議的主題，導致論點很薄弱。他們沒有充分地考量各種不同觀點及應對種種限制。此時，要求他們寫敘事文章可以彰顯這些事實。
我們常見產品開發人員發言時夸夸其談，假裝很清楚自己在講什麼。然而，要求他們提交敘事文章，他們就難以裝腔作勢。前網景（Netscape）公司工程師、亞馬遜資深人員布雷德．波特（BradPorter）說過：「亞馬遜已經向大家揭曉祕訣，速度和規模都是利器……，接下來就看他們有沒有實行的專業能力。」
儘管亞馬遜有二十五年持續創新紀錄，但我認識的產品開發人員多半竭力避免敘事性寫作，儘管這項最有價值的工作，真的可以快速推進自我、做出更好決策。
確實，很少有產品開發人員在敘事性寫作，和挑戰浮誇言論漏洞上受過專業訓練。無論如何，管理者可以在這方面教練產品開發人員。
先要求他們以說故事手法寫下數頁文本，然後讓他們設想關鍵主管與利害關係人可能提出的顧慮或反對意見，據以製作常見問答集附加在文本後面。他們必須細思慢想、明確回答各項問題，接著去找有顧慮或持反對意見的人，一起檢視他們的問答集。當主管讀過文本和問答集之後，就能看出產品開發人員是否確實做足了功課。
產品開發人員可以像亞馬遜那樣，運用說故事技巧來啟動決策會議。即使你決定用PowerPoint做簡報，我向你保證，只要先練就出色的敘事寫作技能，製作簡報時將能輕而易舉發揮創意，靈感會直接從敘事功力泉湧而出。你的簡報會突飛猛進，看過的人都會對你顯而易見的準備功夫印象深刻。
我自己也是在職涯初期被人說服，才學會了敘事寫作技能，我很慶幸那位管理者當年把我推出舒適圈，使我學有所成。我從此轉而信仰說故事的力量。現在我依然頻繁地運用這項技能。當我準備新的主題簡報時，會要求自己先寫一份完整的敘事文稿，並反覆修改直到條理分明且引人入勝。接著，把文稿拿給敬重的人過目，我知道他們會實話實說，在通過這關考驗之後，我才會著手創造簡報。
如果你還沒試過敘事性寫作，我期許你在下一項重要工作時嘗試看看，雖然這可能會帶給你不安。務必要兼容並蓄團隊成員和利害關係人的多元觀點，也要多花些時間使你說的故事更加清晰、簡明和扣人心弦。我確信，這會造就你成為更加卓越的產品開發人員。
【摘錄二】
第13章：捨我其誰的責任感
本書前面幾章提供了一組教練工具和技巧，是設計來促進產品經理勝任職務。在本章與接下來幾個章節，我將探討關於行為和心態的教練方法。
優秀的產品開發人員不但要具備稱職的技能與知識，對於產品的心態也要有效益，而且要始終如一在決策和互動方面，展現良好的判斷能力。我在本章將闡述產品開發人員必不可少的一種心態，借助它可以區別具有負責人思維和只有雇員思維二者之間的差異。
我要事先聲明，對許多人來說，本章的主題頗為敏感，因為觸及了個人問題，像是不同心態看待工作，對於異國文化民眾尤其如此。因此， 我要提醒大家，我全然只是分享心目中，最卓越科技產品開發團隊的做法和各種技巧。我無意多說一般公司做事的方法（我在序言已說明自己對這些公司的看法），只想討論那些最出色的高招，而且只是藉由客觀成果而不是主觀標準，來判斷哪種做法最超群拔類。
多數產品領導人想必都聽說過，「要雇用具有負責人思維而不是只有雇員思維的人」，但這真正的意思是什麼呢？實質上又有多重要呢？
傑夫．貝佐斯（Jeff Bezos）曾在1997 年寫給股東的信函指出：
「我們將繼續專注於聘用和留住多才多藝的員工，並持續以員工認股權而非現金來獎賞他們。我們深知，這方面的能力會大幅影響公司的成就。積極的員工必須實質像負責人那樣思考事情。」
他也在2019 年致股東的信函重申了這個關鍵要點。貝佐斯試圖傳達的極重要訊息是，負責人心態是卓越的管理者能幫產品開發人員發展的最關鍵素質之一。所以，我們要認真看待「像負責人那樣思考」這概念。
這有點類似「要傳教士團隊而非傭兵團隊」，但事實上，要使產品開發人員因有意義的事情（比如扣人心弦的產品願景）而情緒激動並非難事，但要促使他們像負責人那樣思考絕非易事。
雖然多數負責人行事作風像傳教士，但並不是所有傳教士的行為舉止都像負責人。賦權給產品開發團隊，給予團隊解決問題的主導權，這樣他們才能找出最佳方法來解決問題。
賦權的模式仰賴具有負責人思維的產品開發人員，但他們一般不會純粹因為獲得賦權，就能像負責人那樣思考事情。
我（凱根）昔日擔任技術主管、考慮接下產品經理職務時，曾不可避免地問過「為什麼？」那時我的啟蒙者使我明白其中道理的情景，仍歷歷在目。
那人告訴我，具備負責人思維的產品經理意味著，必須實質感受到對顧客有應盡的義務和責任。為什麼？因為產品經理主導產品開發團隊，而團隊管理者與公司主管會依據相關言行來評判產品經理。
他還告訴我，產品開發團隊的設計師與工程師，仰賴產品經理提供必要的策略脈絡，好構想最優越的解決方案。為什麼？因為當產品經理給予團隊策略脈絡和待解問題，而不只是向他們講述解決方案的必要條件，團隊能夠更完善地達成任務。
他也告訴我，要做到這些，產品經理必須「做足功課」，關於顧客、資料、商業與產業的知識和技能必須完備（我真的已覆誦過這句話數千次）。為什麼？因為設計師和工程師需要團隊裡擁有這些知識及懂得脈絡的人，而產品經理正是憑藉這些使團隊達成指定任務。
他亦告訴我，產品經理要致力想出能克服潛在障礙的方法，而且要設想實際可能出現很多阻礙。為什麼？因為科技產品從來不是唾手可得的事物。我記得他是這麼說的：「人們總是能夠找到許多交不出產品的好理由，而產品經理的職責就是想方設法來克服每個障礙。」
他並告訴我，擔任產品經理的績效是以成果來衡量（這是當今人人朗朗上口的話，事實上在1980 年代曾是彰顯高效能的標語）。為什麼？ 因為產品經理始終要審慎不把產出（output）與成果（outcome）混為一談。客戶在意的是成果，而不是我們的努力或行動。
他還告訴我，想要成功理當努力與公司裡相互依存的人建立及維繫各種關係。為什麼？因為在公司（尤其是大型公司）裡，有很多人負責確保各種資產（銷售力、營收、客群、信譽）受到保護，他們必須知悉、尊重形形色色相關限制，並想出商業上可行的解決方案，以善盡守護職責。
他也告訴我，公司領導者會不斷評判產品經理有沒有做足功課、言行是否像個負責人、能不能照料好產品開發團隊。為什麼？因為採行賦權模式的公司主管知道，產品經理是礦坑裡的金絲雀（危險的預兆）。
他亦告訴我，當出師不利時，產品經理要自己扛起責任，而在無往不利時要歸功於團隊。為什麼？因為傑出的領導者和負責人都這麼做。
他並告訴我，產品經理要善盡激勵和啟迪團隊人心的職責。為什麼？因為我們需要的是傳教士團隊而不是傭兵團隊。
最後，他告訴我，產品經理有責任保障團隊獲得成功，但沒有權力指使團隊成員（多數產品經理應當都已耳熟能詳）。為什麼？因為切實與設計師和工程師協作才能持續創新，而這必須是一種同儕友伴關係， 而不是下屬聽命上司的關係（還有其他一些理由，我會在後面的章節說明）。
以上這些並不是一字不差的引述，但我回憶起這些話深感通情達理。當我教練產品經理時，總是力圖把同樣的訊息傳達給他們，盼望他們以負責人而非雇員的心態來思考事情。
總結來說，負責人思維與雇員思維主要的差異在於，前者對結果當責不讓，後者只負責做事。我常試著說服非凡的設計師與工程師考慮產品管理的職位，雖然有一些成功的案例，但也時常遭人拒絕，而我最常聽到的一個理由是，他們無意對結果（與相應的壓力）負責。
我了解也尊重他們的選擇，然而我同意貝佐斯的看法，確信負責人心態至關緊要，對於產品經理尤其如此。
【摘錄三】
第15章：思考能力
在前面探討教練主題的系列章節裡，我講述了一項評量產品開發人員能力的工具，然後提供了一些範例，詳細說明如何制訂教練計畫，以協助他們首先具備稱職的能力，然後全面發揮潛能。
我們還討論了一對一教練的重要性，以及敘事寫作技巧。我們也談論除了技能與技術之外，產品開發人員應有的心態，包括像負責人而不是如同雇員那樣思考事情。
在本章，我將處理心態的另一個層面，也就是思考能力。我要承認這是有點尷尬的議題，但它可能是勝任的產品開發人員最重要的一項能力。人們常會把有思考能力的人簡化成聰明的人。我也是這樣的人。然而，聰明的語意含糊不清，恐會模糊了真正的議題。
當我們說某個人聰明，多半是指他有智慧。然而，我們先要認清，智慧和思考能力判然有別。有效率地思考（以及在產品職涯功成名就）確實需要一定程度的智慧。但是，我見過無數顯然有智慧的人白白浪費了頭腦，只因他們不知道如何（或是無意）透過思考來實際解決難題。
其次，我們必須認清，獲取知識與應用知識截然不同。谷歌提供了彈指可得的大量資源，使獲取知識變得前所未見地容易，但這對於幫助人們實際學會思考和應用知識，卻幾乎毫無建樹。為什麼思考非常重要？因為產品開發團隊的核心要務全然在於解決問題。
我熱愛與設計師和工程師合作，因為他們的工作精髓就是思考。這也是我偏好招募設計師與工程師加入產品管理行列的原因。確實，他們是創客（makers），但從事用戶體驗設計與實體化工程基本上就是要解決問題。設計師和工程師都擅長解決有許多限制的難題。這實際上是他們每天都在做的事。
同樣地，產品經理也務必是能夠解決問題的人。他們不從事用戶體驗設計，也不建構可擴充、容錯的解決方案，而致力於化解客戶的商務、產業，以及自家事業相關的種種侷限。他們始終想著，解決方案切合客戶的需求嗎？它實質上優於備選方案嗎？這是公司能有效行銷和銷售的產品嗎？公司負擔得起打造它的成本嗎？相關的客戶服務和支援沒問題嗎？有遵從法律與規範的各項限制嗎？
此外，科技產品和服務還面臨一些特殊挑戰，其中之一是必須同時化解三種類型的約束：產品、設計與工程上的限制。因此，相關三方必須要建立真正的協作關係（這是下一章的主題）。
很顯然，從事任何職務都需要某種程度的思考與解決問題能力。然而，對於產品經理、設計師與工程師來說，那是核心能力。我們不難看出一位產品經理的思考能力是否薄弱。我非常鼓勵大家提出種種疑問，前提是提問前要事先做足功課，並且應先運用智慧努力思考過問題。但很顯然有太多提問者沒做到這點。
優秀的產品公司在面試時，會試著判斷應徵者思考與解決問題的能力是否良好。重點不在於應試者能不能正確解答問題，而在於當他不知道答案時會怎麼做。
這時關鍵性的思考和解決問題能力就格外重要。
我最青睞的培養良好思考能力的方法是敘事性寫作，這已在前面章節討論過。我曾在那一章警示，不習慣思考艱難問題的人會對敘事性寫作備感煎熬。而他們往往最有必要掌握說故事的技巧。我們可以從這方面看清某些人確實不適合擔任產品經理。
但只要他們有必備的智慧，而且願意善用智慧勤懇學習，我相信他們絕對能夠增進思考與解決問題的能力。無論如何，他們還需要管理者積極教練，而且必須真心誠意勤學苦練。
【摘錄四】
第36章：領導者側寫──艾波．安德伍（April Underwood）
◇ 領導力之路
安德伍研習資訊系統和商業，職涯最初擔任研發者。寫了幾年程式之後，她成為線上旅遊平台Travelocity的軟體工程師，並且立刻在第一線為Travelocity與雅虎和美國線上等當時的網際網路巨擘公司的夥伴關係效勞。
通過工程師的工作，安德伍開始將科技選項和商業策略連結起來，並且發現產品管理有助於促進二者齊頭並進。
她堅持不懈地表明自己有志成為產品經理，而且持續向Travelocity和事業夥伴展現自己結合工程師與商務人士兩種角色的嫻熟能力，於是她在2005年如願以償，首度出任產品經理。
我在2007年結識安德伍，當時她已取得企業管理碩士學位、在蘋果公司完成實習，並且曾在谷歌面向夥伴的科技組織裡擴展領導經驗。
安德伍後來加入推特擔任平台事業產品經理，五年內公司員工從一五○人驟增為四千人。在這段期間，她同時領導著產品經理團隊、商務開發團隊以及產品行銷團隊，職能與日俱增。這使她具備了日後出任更高階領導角色的條件。
2015年，她轉任Slack軟體公司平台事業主管，並且迅速升任副總負責產品事業，最終在公司營收與員工人數持續近四年高度成長後，出任產品長。她監督Slack公司平台事業和產品所有面向，以及設計和研發。Slack得以在企業應用軟體業界出類拔萃，仰賴的就是關鍵的設計和研發。
安德伍也在2015年與推特前同事們共同創辦#Angels，現今從事著新創公司投資與諮詢事業。
◇ 行動領導力
安德伍的職涯凸顯出通往產品管理的途徑不計其數，而且產品管理有著不可限量的角色版本。她指出：
在職涯初期，網路公司泡沫剛破滅，那時我搬離了矽谷，而且滿心認為典型的產品經理就是：有生意頭腦的企管碩士而且擁有工程和科技背景。
當我首次表明有志往產品管理方面發展，人們告訴我首先必須取得企管碩士學位。進入企管研究所時，我在當時的東家Travelocity獲得了升任產品經理的機會。 我接下了產品經理職務，同時也繼續企管研究所的學業。在2007年我拿到企管碩士學位後，業界已經天翻地覆：市場千變萬化、產品經理的角色日趨著重強效的科技相關技能。由於我曾經擔任過工程師，因而自許對這些變化做好了準備，但是在2007年加入谷歌公司後，我才發現自己無法成為產品經理，因為我當時沒有電腦科學相關學位。門檻真是愈來愈高。
我當上產品領導者迄今已有十三年，從而發現了一些明確的模式：
產品經理的典型角色會因應市場的需求而變化。
當科技成為創新的核心動力和機會的來源，具備愈多科技能力的產品經理就愈受重用。在行動科技當道之際，擁有設計鑑賞能力，又能打造出轉換成本低廉的應用程式的產品經理，更成為難能可貴的人才。當創新的前沿地帶轉移到營運（比如運輸、房地產、接待服務、外送服務），我們繞了一圈回歸到珍視產品經理必備的商業價值取向。
以上不同類型的產品經理並沒有哪一個明確地勝出，但是異質多元更勝過唯一標準。
我在Slack組建了一個產品經理組織，並在五年內使它成長了五倍。當年我在延攬產品經理上特別注重他們實際經驗方面的特點、他們從先前打造的產品養成的主題內容專長、他們前公司的成長階段。在決定那些特點最重要的過程中，我得以縮小攬才範圍，從而聘雇到得力的產品經理。
產品領導者晉升為公司領導者的必備條件是，具有既深且廣的角色功能。
產品領導者不僅要在定義和打造產品上領先群倫，同時也要了解，唯有使目標客群明白他們確實需要某項產品，才能讓產品大發利市。任何平台只有在研發者和用戶都賦予產品價值的情況下，才會真正妙用無窮。我們必須依據能使商業健全的原則來打造產品。以上這些有關行銷、夥伴、財務等的洞見，對於創造產品至關緊要。我在職涯裡扮演過多種不同角色，有時是出於個人選擇以學習新的技能，而有時則是受到個人無法控制的原因驅策。
如今，在獲得產品主管的經驗之後，我領悟到這些迂迴的過程實際上是我最富價值的資產。它們助益我了解如何徵才和策進他們的發展，使他們有能力擔任不同的領導角色。它們也有助於我在不同組織之間架起橋樑，並且使我銘記產品始終是為更遠大的公司使命服務，不可反其道而行。
【摘錄五】
第43章：對平台開發團隊賦權
在前面的章節，我引介了兩種主要的產品開發團隊類型，並且講述了平台開發團隊如何創造槓桿作用，以及助益顧客體驗團隊包容複雜性。
平台開發團隊為其他團隊略去細節、簡化了各項服務和技術架構根本的複雜性，從而提高了賦權等級。賦權給平台開發團隊一直是個棘手的議題。因為顧客體驗團隊的目的在於，為用戶和顧客解決問題，平台開發團隊則實質對顧客體驗團隊賦能，使他們能夠以更好的方式化解顧客的難題。
因此，平台開發團隊做出的是間接的貢獻。
一旦明白了這會如何影響平台開發團隊，我們就能分辨他們和顧客體驗團隊各自的職責所在。一方面，他們的主要工作是，推進著團隊的目的。我們留待稍後再來細說這個部分。
無論如何，所有產品開發團隊另有一些我們稱為「維持業務正常運行」（keep-the-lights-on）的職責。也就是日常的使公司業務持續運轉的必要工作，例如修正程式錯誤、處理產品性能相關問題、為公司在法規遵循等沒有協商餘地的事情上增添應對能力。
事實上，平台開發團隊這方面的工作，往往多過一般的顧客體驗團隊，這是出於平台開發團隊必須對依賴他們的團隊賦能。平台開發團隊可能有一成、有時甚至近五成的這類工作。
所以，把這些「維持業務正常運行」的工作區隔出來後，有兩種主要的方式來對平台開發團隊賦權，以使他們邁步前進：設定團隊共同目標以及平台作為一項產品的目標。
◇ 團隊共同目標
平台開發團隊最常藉助團隊共同目標，好高效完成主要工作。團隊共同目標使平台開發團隊，與一個或更多的顧客體驗團隊的目標一致。
我們會在第57章探討團隊共同目標的機制。當前我們只要明白，團隊之間理當協作以探索和發展解決方案。有時，協作基本上非常需要各團隊像合而為一那樣密切合作。
以內容管理系統（CMS）為例，假設你有一個平台開發團隊，專民管理內容的後端儲存（backend storage）和應用程式介面存取權限（API access），而且另有一個顧客體驗團隊管理面向用戶的工作流程。再進一步假設，你的內容管理系統雖然對圖像內容行得通，但為了因應新的市場擴展策略，必須要擴增支援影像內容。
這時，平台開發團隊和顧客體驗團隊有了團隊共同目標，兩個團隊理應密切合作以敲定最妥適的用戶體驗，以及如何將它具體落實。在其他情況下，團隊協作可能較為片片段段。平台開發團隊和顧客體驗團隊有必要選定一種應用程式介面，做為雙方某種形式的合作契約，然後兩邊就能大抵獨立地完成工作。
比如說，電商公司增添新的支付方法時，平台開發團隊要管理所有支付上的複雜性，並提供應用程式介面給顧客體驗團隊。負責結帳體驗的團隊創造面向用戶的流程（前端），而平台開發團隊則實現前端與後端支付處理的整合。兩團隊在測試和交付過程也要密切合作。
不論雙方協作是水乳交融或是片片段段，重要的是兩團隊要有共同的策略脈絡和目標。他們理應在工作價值和意義上彼此心領神會。
◇ 平台即是產品目標
某些公司的產品就是平台。他們銷售應用程式介面給顧客和用戶（通常是研發者）好用來打造各自的產品。我們稱這種平台為外部開發者平台。
在這種情況下，平台就是產品，就該如同產品一般對待。顧客與用戶雖是研發者而不是消費者，但他們使用的確實就是產品。
請留意，當前有個方興未艾的趨勢：愈來愈多公司對內部平台和外部平台產品的管理正日漸趨同。這些平台產品的目標往往近似顧客體驗產品，用於增長顧客人數、促使顧客適應產品性能、改善客戶營利狀況（以外部開發者平台來說）。
平台開發團隊和顧客體驗團隊就如同產品開發團隊，如果我們遇上重大的品質問題、性能問題、研發者體驗問題，不要只是顧慮日常的「維持業務正常運行」職責，而要把工作提升到團隊目標的層次。
在對平台開發團隊賦權方面，如果你能明辨尋常「維持業務正常運行」的工作和主要工作的差異，至少就能使平台開發團隊與顧客體驗團隊的賦權層次並駕齊驅。
第11章：敘事性寫作（The Written Narrative）
上一章講述了一對一教練的重要性。那個方法可以提供不間斷的機制，協助產品開發人員發揮潛能。在本章，我要探討的是本人最鍾愛的教練工具：敘事性寫作，這有助於造就不同凡響的產品開發人員。
先承認，在我運用的各種技巧當中，敘事性寫作最讓人心生抗拒。事實上，有些人基本上是受我強迫才使用這項技能。他們並不是懷疑它的效用，而存粹是對它深感痛苦。而且我發現，最有必要熟練說故事技能的人，往往是那些最抗拒它的人。
產品開發人員（尤其是產品經理），必須隨時都能提出論點來應對爭議。雖然這在小事上不常見，但在面臨代價高昂、風險重大的事情時，例如大型功能開發與專案（尤其是重大的新嘗試），自然會有許多人提出疑問和挑戰。在這種情況下，一般是要應對公司各主管的質疑，而這往往要從說服團隊成員著手。
本章的教練方法是，要求產品開發人員寫一篇敘事文章，闡述他們的論點和建議。先說明，我講的不是任何詳細說明文件。那類文件的用意不是要說服人，只是用來描述想要打造的產品相關細節。
我談論的是大約6頁的文章，內容以說故事手法講述產品開發人員力圖解決的問題、為什麼這對客戶和公司具有價值，以及提出解決問題的策略。如果寫得斐然成章，讀者將獲得啟發並被你說服。
亞馬遜公司就是以這種說故事手法為核心，闡述他們如何營運與創新。亞馬遜比我所知的任何公司更加擁護敘事性寫作，我想亞馬遜能成為全球最具持續創新能力的公司之一，絕非偶然。
產品開發人員在工作起始會議上舉手發言、拋出一些數據點，使自己看起來熱衷而且有自信，並不是件困難的事。這種會議如同委員會設計（design by committee，是指專案有多人參與設計，卻沒有一致的計畫或是看法）那樣糟糕，每個人深受挫折，最後只會向會議室裡最高薪的人尋求指引。
當發生這種狀況時，我很清楚產品開發人員沒有做好必要的功課、未能真正理解會議的主題，導致論點很薄弱。他們沒有充分地考量各種不同觀點及應對種種限制。此時，要求他們寫敘事文章可以彰顯這些事實。
我們常見產品開發人員發言時夸夸其談，假裝很清楚自己在講什麼。然而，要求他們提交敘事文章，他們就難以裝腔作勢。前網景（Netscape）公司工程師、亞馬遜資深人員布雷德．波特（BradPorter）說過：「亞馬遜已經向大家揭曉祕訣，速度和規模都是利器……，接下來就看他們有沒有實行的專業能力。」
儘管亞馬遜有二十五年持續創新紀錄，但我認識的產品開發人員多半竭力避免敘事性寫作，儘管這項最有價值的工作，真的可以快速推進自我、做出更好決策。
確實，很少有產品開發人員在敘事性寫作，和挑戰浮誇言論漏洞上受過專業訓練。無論如何，管理者可以在這方面教練產品開發人員。
先要求他們以說故事手法寫下數頁文本，然後讓他們設想關鍵主管與利害關係人可能提出的顧慮或反對意見，據以製作常見問答集附加在文本後面。他們必須細思慢想、明確回答各項問題，接著去找有顧慮或持反對意見的人，一起檢視他們的問答集。當主管讀過文本和問答集之後，就能看出產品開發人員是否確實做足了功課。
產品開發人員可以像亞馬遜那樣，運用說故事技巧來啟動決策會議。即使你決定用PowerPoint做簡報，我向你保證，只要先練就出色的敘事寫作技能，製作簡報時將能輕而易舉發揮創意，靈感會直接從敘事功力泉湧而出。你的簡報會突飛猛進，看過的人都會對你顯而易見的準備功夫印象深刻。
我自己也是在職涯初期被人說服，才學會了敘事寫作技能，我很慶幸那位管理者當年把我推出舒適圈，使我學有所成。我從此轉而信仰說故事的力量。現在我依然頻繁地運用這項技能。當我準備新的主題簡報時，會要求自己先寫一份完整的敘事文稿，並反覆修改直到條理分明且引人入勝。接著，把文稿拿給敬重的人過目，我知道他們會實話實說，在通過這關考驗之後，我才會著手創造簡報。
如果你還沒試過敘事性寫作，我期許你在下一項重要工作時嘗試看看，雖然這可能會帶給你不安。務必要兼容並蓄團隊成員和利害關係人的多元觀點，也要多花些時間使你說的故事更加清晰、簡明和扣人心弦。我確信，這會造就你成為更加卓越的產品開發人員。
【摘錄二】
第13章：捨我其誰的責任感
本書前面幾章提供了一組教練工具和技巧，是設計來促進產品經理勝任職務。在本章與接下來幾個章節，我將探討關於行為和心態的教練方法。
優秀的產品開發人員不但要具備稱職的技能與知識，對於產品的心態也要有效益，而且要始終如一在決策和互動方面，展現良好的判斷能力。我在本章將闡述產品開發人員必不可少的一種心態，借助它可以區別具有負責人思維和只有雇員思維二者之間的差異。
我要事先聲明，對許多人來說，本章的主題頗為敏感，因為觸及了個人問題，像是不同心態看待工作，對於異國文化民眾尤其如此。因此， 我要提醒大家，我全然只是分享心目中，最卓越科技產品開發團隊的做法和各種技巧。我無意多說一般公司做事的方法（我在序言已說明自己對這些公司的看法），只想討論那些最出色的高招，而且只是藉由客觀成果而不是主觀標準，來判斷哪種做法最超群拔類。
多數產品領導人想必都聽說過，「要雇用具有負責人思維而不是只有雇員思維的人」，但這真正的意思是什麼呢？實質上又有多重要呢？
傑夫．貝佐斯（Jeff Bezos）曾在1997 年寫給股東的信函指出：
「我們將繼續專注於聘用和留住多才多藝的員工，並持續以員工認股權而非現金來獎賞他們。我們深知，這方面的能力會大幅影響公司的成就。積極的員工必須實質像負責人那樣思考事情。」
他也在2019 年致股東的信函重申了這個關鍵要點。貝佐斯試圖傳達的極重要訊息是，負責人心態是卓越的管理者能幫產品開發人員發展的最關鍵素質之一。所以，我們要認真看待「像負責人那樣思考」這概念。
這有點類似「要傳教士團隊而非傭兵團隊」，但事實上，要使產品開發人員因有意義的事情（比如扣人心弦的產品願景）而情緒激動並非難事，但要促使他們像負責人那樣思考絕非易事。
雖然多數負責人行事作風像傳教士，但並不是所有傳教士的行為舉止都像負責人。賦權給產品開發團隊，給予團隊解決問題的主導權，這樣他們才能找出最佳方法來解決問題。
賦權的模式仰賴具有負責人思維的產品開發人員，但他們一般不會純粹因為獲得賦權，就能像負責人那樣思考事情。
我（凱根）昔日擔任技術主管、考慮接下產品經理職務時，曾不可避免地問過「為什麼？」那時我的啟蒙者使我明白其中道理的情景，仍歷歷在目。
那人告訴我，具備負責人思維的產品經理意味著，必須實質感受到對顧客有應盡的義務和責任。為什麼？因為產品經理主導產品開發團隊，而團隊管理者與公司主管會依據相關言行來評判產品經理。
他還告訴我，產品開發團隊的設計師與工程師，仰賴產品經理提供必要的策略脈絡，好構想最優越的解決方案。為什麼？因為當產品經理給予團隊策略脈絡和待解問題，而不只是向他們講述解決方案的必要條件，團隊能夠更完善地達成任務。
他也告訴我，要做到這些，產品經理必須「做足功課」，關於顧客、資料、商業與產業的知識和技能必須完備（我真的已覆誦過這句話數千次）。為什麼？因為設計師和工程師需要團隊裡擁有這些知識及懂得脈絡的人，而產品經理正是憑藉這些使團隊達成指定任務。
他亦告訴我，產品經理要致力想出能克服潛在障礙的方法，而且要設想實際可能出現很多阻礙。為什麼？因為科技產品從來不是唾手可得的事物。我記得他是這麼說的：「人們總是能夠找到許多交不出產品的好理由，而產品經理的職責就是想方設法來克服每個障礙。」
他並告訴我，擔任產品經理的績效是以成果來衡量（這是當今人人朗朗上口的話，事實上在1980 年代曾是彰顯高效能的標語）。為什麼？ 因為產品經理始終要審慎不把產出（output）與成果（outcome）混為一談。客戶在意的是成果，而不是我們的努力或行動。
他還告訴我，想要成功理當努力與公司裡相互依存的人建立及維繫各種關係。為什麼？因為在公司（尤其是大型公司）裡，有很多人負責確保各種資產（銷售力、營收、客群、信譽）受到保護，他們必須知悉、尊重形形色色相關限制，並想出商業上可行的解決方案，以善盡守護職責。
他也告訴我，公司領導者會不斷評判產品經理有沒有做足功課、言行是否像個負責人、能不能照料好產品開發團隊。為什麼？因為採行賦權模式的公司主管知道，產品經理是礦坑裡的金絲雀（危險的預兆）。
他亦告訴我，當出師不利時，產品經理要自己扛起責任，而在無往不利時要歸功於團隊。為什麼？因為傑出的領導者和負責人都這麼做。
他並告訴我，產品經理要善盡激勵和啟迪團隊人心的職責。為什麼？因為我們需要的是傳教士團隊而不是傭兵團隊。
最後，他告訴我，產品經理有責任保障團隊獲得成功，但沒有權力指使團隊成員（多數產品經理應當都已耳熟能詳）。為什麼？因為切實與設計師和工程師協作才能持續創新，而這必須是一種同儕友伴關係， 而不是下屬聽命上司的關係（還有其他一些理由，我會在後面的章節說明）。
以上這些並不是一字不差的引述，但我回憶起這些話深感通情達理。當我教練產品經理時，總是力圖把同樣的訊息傳達給他們，盼望他們以負責人而非雇員的心態來思考事情。
總結來說，負責人思維與雇員思維主要的差異在於，前者對結果當責不讓，後者只負責做事。我常試著說服非凡的設計師與工程師考慮產品管理的職位，雖然有一些成功的案例，但也時常遭人拒絕，而我最常聽到的一個理由是，他們無意對結果（與相應的壓力）負責。
我了解也尊重他們的選擇，然而我同意貝佐斯的看法，確信負責人心態至關緊要，對於產品經理尤其如此。
【摘錄三】
第15章：思考能力
在前面探討教練主題的系列章節裡，我講述了一項評量產品開發人員能力的工具，然後提供了一些範例，詳細說明如何制訂教練計畫，以協助他們首先具備稱職的能力，然後全面發揮潛能。
我們還討論了一對一教練的重要性，以及敘事寫作技巧。我們也談論除了技能與技術之外，產品開發人員應有的心態，包括像負責人而不是如同雇員那樣思考事情。
在本章，我將處理心態的另一個層面，也就是思考能力。我要承認這是有點尷尬的議題，但它可能是勝任的產品開發人員最重要的一項能力。人們常會把有思考能力的人簡化成聰明的人。我也是這樣的人。然而，聰明的語意含糊不清，恐會模糊了真正的議題。
當我們說某個人聰明，多半是指他有智慧。然而，我們先要認清，智慧和思考能力判然有別。有效率地思考（以及在產品職涯功成名就）確實需要一定程度的智慧。但是，我見過無數顯然有智慧的人白白浪費了頭腦，只因他們不知道如何（或是無意）透過思考來實際解決難題。
其次，我們必須認清，獲取知識與應用知識截然不同。谷歌提供了彈指可得的大量資源，使獲取知識變得前所未見地容易，但這對於幫助人們實際學會思考和應用知識，卻幾乎毫無建樹。為什麼思考非常重要？因為產品開發團隊的核心要務全然在於解決問題。
我熱愛與設計師和工程師合作，因為他們的工作精髓就是思考。這也是我偏好招募設計師與工程師加入產品管理行列的原因。確實，他們是創客（makers），但從事用戶體驗設計與實體化工程基本上就是要解決問題。設計師和工程師都擅長解決有許多限制的難題。這實際上是他們每天都在做的事。
同樣地，產品經理也務必是能夠解決問題的人。他們不從事用戶體驗設計，也不建構可擴充、容錯的解決方案，而致力於化解客戶的商務、產業，以及自家事業相關的種種侷限。他們始終想著，解決方案切合客戶的需求嗎？它實質上優於備選方案嗎？這是公司能有效行銷和銷售的產品嗎？公司負擔得起打造它的成本嗎？相關的客戶服務和支援沒問題嗎？有遵從法律與規範的各項限制嗎？
此外，科技產品和服務還面臨一些特殊挑戰，其中之一是必須同時化解三種類型的約束：產品、設計與工程上的限制。因此，相關三方必須要建立真正的協作關係（這是下一章的主題）。
很顯然，從事任何職務都需要某種程度的思考與解決問題能力。然而，對於產品經理、設計師與工程師來說，那是核心能力。我們不難看出一位產品經理的思考能力是否薄弱。我非常鼓勵大家提出種種疑問，前提是提問前要事先做足功課，並且應先運用智慧努力思考過問題。但很顯然有太多提問者沒做到這點。
優秀的產品公司在面試時，會試著判斷應徵者思考與解決問題的能力是否良好。重點不在於應試者能不能正確解答問題，而在於當他不知道答案時會怎麼做。
這時關鍵性的思考和解決問題能力就格外重要。
我最青睞的培養良好思考能力的方法是敘事性寫作，這已在前面章節討論過。我曾在那一章警示，不習慣思考艱難問題的人會對敘事性寫作備感煎熬。而他們往往最有必要掌握說故事的技巧。我們可以從這方面看清某些人確實不適合擔任產品經理。
但只要他們有必備的智慧，而且願意善用智慧勤懇學習，我相信他們絕對能夠增進思考與解決問題的能力。無論如何，他們還需要管理者積極教練，而且必須真心誠意勤學苦練。
【摘錄四】
第36章：領導者側寫──艾波．安德伍（April Underwood）
◇ 領導力之路
安德伍研習資訊系統和商業，職涯最初擔任研發者。寫了幾年程式之後，她成為線上旅遊平台Travelocity的軟體工程師，並且立刻在第一線為Travelocity與雅虎和美國線上等當時的網際網路巨擘公司的夥伴關係效勞。
通過工程師的工作，安德伍開始將科技選項和商業策略連結起來，並且發現產品管理有助於促進二者齊頭並進。
她堅持不懈地表明自己有志成為產品經理，而且持續向Travelocity和事業夥伴展現自己結合工程師與商務人士兩種角色的嫻熟能力，於是她在2005年如願以償，首度出任產品經理。
我在2007年結識安德伍，當時她已取得企業管理碩士學位、在蘋果公司完成實習，並且曾在谷歌面向夥伴的科技組織裡擴展領導經驗。
安德伍後來加入推特擔任平台事業產品經理，五年內公司員工從一五○人驟增為四千人。在這段期間，她同時領導著產品經理團隊、商務開發團隊以及產品行銷團隊，職能與日俱增。這使她具備了日後出任更高階領導角色的條件。
2015年，她轉任Slack軟體公司平台事業主管，並且迅速升任副總負責產品事業，最終在公司營收與員工人數持續近四年高度成長後，出任產品長。她監督Slack公司平台事業和產品所有面向，以及設計和研發。Slack得以在企業應用軟體業界出類拔萃，仰賴的就是關鍵的設計和研發。
安德伍也在2015年與推特前同事們共同創辦#Angels，現今從事著新創公司投資與諮詢事業。
◇ 行動領導力
安德伍的職涯凸顯出通往產品管理的途徑不計其數，而且產品管理有著不可限量的角色版本。她指出：
在職涯初期，網路公司泡沫剛破滅，那時我搬離了矽谷，而且滿心認為典型的產品經理就是：有生意頭腦的企管碩士而且擁有工程和科技背景。
當我首次表明有志往產品管理方面發展，人們告訴我首先必須取得企管碩士學位。進入企管研究所時，我在當時的東家Travelocity獲得了升任產品經理的機會。 我接下了產品經理職務，同時也繼續企管研究所的學業。在2007年我拿到企管碩士學位後，業界已經天翻地覆：市場千變萬化、產品經理的角色日趨著重強效的科技相關技能。由於我曾經擔任過工程師，因而自許對這些變化做好了準備，但是在2007年加入谷歌公司後，我才發現自己無法成為產品經理，因為我當時沒有電腦科學相關學位。門檻真是愈來愈高。
我當上產品領導者迄今已有十三年，從而發現了一些明確的模式：
產品經理的典型角色會因應市場的需求而變化。
當科技成為創新的核心動力和機會的來源，具備愈多科技能力的產品經理就愈受重用。在行動科技當道之際，擁有設計鑑賞能力，又能打造出轉換成本低廉的應用程式的產品經理，更成為難能可貴的人才。當創新的前沿地帶轉移到營運（比如運輸、房地產、接待服務、外送服務），我們繞了一圈回歸到珍視產品經理必備的商業價值取向。
以上不同類型的產品經理並沒有哪一個明確地勝出，但是異質多元更勝過唯一標準。
我在Slack組建了一個產品經理組織，並在五年內使它成長了五倍。當年我在延攬產品經理上特別注重他們實際經驗方面的特點、他們從先前打造的產品養成的主題內容專長、他們前公司的成長階段。在決定那些特點最重要的過程中，我得以縮小攬才範圍，從而聘雇到得力的產品經理。
產品領導者晉升為公司領導者的必備條件是，具有既深且廣的角色功能。
產品領導者不僅要在定義和打造產品上領先群倫，同時也要了解，唯有使目標客群明白他們確實需要某項產品，才能讓產品大發利市。任何平台只有在研發者和用戶都賦予產品價值的情況下，才會真正妙用無窮。我們必須依據能使商業健全的原則來打造產品。以上這些有關行銷、夥伴、財務等的洞見，對於創造產品至關緊要。我在職涯裡扮演過多種不同角色，有時是出於個人選擇以學習新的技能，而有時則是受到個人無法控制的原因驅策。
如今，在獲得產品主管的經驗之後，我領悟到這些迂迴的過程實際上是我最富價值的資產。它們助益我了解如何徵才和策進他們的發展，使他們有能力擔任不同的領導角色。它們也有助於我在不同組織之間架起橋樑，並且使我銘記產品始終是為更遠大的公司使命服務，不可反其道而行。
【摘錄五】
第43章：對平台開發團隊賦權
在前面的章節，我引介了兩種主要的產品開發團隊類型，並且講述了平台開發團隊如何創造槓桿作用，以及助益顧客體驗團隊包容複雜性。
平台開發團隊為其他團隊略去細節、簡化了各項服務和技術架構根本的複雜性，從而提高了賦權等級。賦權給平台開發團隊一直是個棘手的議題。因為顧客體驗團隊的目的在於，為用戶和顧客解決問題，平台開發團隊則實質對顧客體驗團隊賦能，使他們能夠以更好的方式化解顧客的難題。
因此，平台開發團隊做出的是間接的貢獻。
一旦明白了這會如何影響平台開發團隊，我們就能分辨他們和顧客體驗團隊各自的職責所在。一方面，他們的主要工作是，推進著團隊的目的。我們留待稍後再來細說這個部分。
無論如何，所有產品開發團隊另有一些我們稱為「維持業務正常運行」（keep-the-lights-on）的職責。也就是日常的使公司業務持續運轉的必要工作，例如修正程式錯誤、處理產品性能相關問題、為公司在法規遵循等沒有協商餘地的事情上增添應對能力。
事實上，平台開發團隊這方面的工作，往往多過一般的顧客體驗團隊，這是出於平台開發團隊必須對依賴他們的團隊賦能。平台開發團隊可能有一成、有時甚至近五成的這類工作。
所以，把這些「維持業務正常運行」的工作區隔出來後，有兩種主要的方式來對平台開發團隊賦權，以使他們邁步前進：設定團隊共同目標以及平台作為一項產品的目標。
◇ 團隊共同目標
平台開發團隊最常藉助團隊共同目標，好高效完成主要工作。團隊共同目標使平台開發團隊，與一個或更多的顧客體驗團隊的目標一致。
我們會在第57章探討團隊共同目標的機制。當前我們只要明白，團隊之間理當協作以探索和發展解決方案。有時，協作基本上非常需要各團隊像合而為一那樣密切合作。
以內容管理系統（CMS）為例，假設你有一個平台開發團隊，專民管理內容的後端儲存（backend storage）和應用程式介面存取權限（API access），而且另有一個顧客體驗團隊管理面向用戶的工作流程。再進一步假設，你的內容管理系統雖然對圖像內容行得通，但為了因應新的市場擴展策略，必須要擴增支援影像內容。
這時，平台開發團隊和顧客體驗團隊有了團隊共同目標，兩個團隊理應密切合作以敲定最妥適的用戶體驗，以及如何將它具體落實。在其他情況下，團隊協作可能較為片片段段。平台開發團隊和顧客體驗團隊有必要選定一種應用程式介面，做為雙方某種形式的合作契約，然後兩邊就能大抵獨立地完成工作。
比如說，電商公司增添新的支付方法時，平台開發團隊要管理所有支付上的複雜性，並提供應用程式介面給顧客體驗團隊。負責結帳體驗的團隊創造面向用戶的流程（前端），而平台開發團隊則實現前端與後端支付處理的整合。兩團隊在測試和交付過程也要密切合作。
不論雙方協作是水乳交融或是片片段段，重要的是兩團隊要有共同的策略脈絡和目標。他們理應在工作價值和意義上彼此心領神會。
◇ 平台即是產品目標
某些公司的產品就是平台。他們銷售應用程式介面給顧客和用戶（通常是研發者）好用來打造各自的產品。我們稱這種平台為外部開發者平台。
在這種情況下，平台就是產品，就該如同產品一般對待。顧客與用戶雖是研發者而不是消費者，但他們使用的確實就是產品。
請留意，當前有個方興未艾的趨勢：愈來愈多公司對內部平台和外部平台產品的管理正日漸趨同。這些平台產品的目標往往近似顧客體驗產品，用於增長顧客人數、促使顧客適應產品性能、改善客戶營利狀況（以外部開發者平台來說）。
平台開發團隊和顧客體驗團隊就如同產品開發團隊，如果我們遇上重大的品質問題、性能問題、研發者體驗問題，不要只是顧慮日常的「維持業務正常運行」職責，而要把工作提升到團隊目標的層次。
在對平台開發團隊賦權方面，如果你能明辨尋常「維持業務正常運行」的工作和主要工作的差異，至少就能使平台開發團隊與顧客體驗團隊的賦權層次並駕齊驅。
