做產品真是哭夭難！ — Marty Cagan 演講 70 分鐘中文逐字翻譯（附贈 YouTube 錄影）
Marty Cagan 是享譽全球的產品大師，【INSPIRED: 產品專案管理全書】的作者，擔任許多知名公司的產品教練與顧問，也是全球的產品社群中的思想領先者。曾和許多資深的產品經理一起工作 (或有私交) ，包含任職於 Netflix、Google、Apple、Adobe、BBC 的產品經理。他參與了第一家網路產品公司 Netscape 的創業歷程，然後再到 eBay 擔任產品與設計副總 (VP of Product and Design) ，之後創辦了 Silicon Valley Product Group，網羅眾多資深產品人，專門為科技公司做產品顧問。
Marty Cagan 長達 70 分鐘的演講，有以下內容：
• 1/ 前言
• 2/ 突破敏捷的挫敗感？
• 3/ 你想要真正的 Product Team？
• 4/ 怎樣讓老闆們信任 Product Team？
• 5/ 要花多少時間在 Prototyping？
• 6/ 滿腦子只有單一方案？
• 7/ 道德上該推出產品嗎？
• 8/ 只有無盡的產品優化？
• 9/ 勢不兩立的量化與質化？
• 10/ 產品管理的核心能力？
• 11/ 輔導產品經理
• 12/ 贏得信任的被授權團隊
每個段落皆附上了 Marty Cagan 的原始投影片，以及 YouTube 影片中該段落開始的時間軸。此外，還有另外一小時的 Q&A 問答互動時間，但礙於本文篇幅已經太長，希望下次再寫成另一篇文章。如果你也想看 Q&A，別忘了拍手鼓勵喔！
Medium 估計本文閱讀時間 44 分鐘，而原本的英文演講錄影長達 70 分鐘。如果你有 70 分鐘的話，去看影片還是非常值得的喔！😆
好，讓我們開始吧。
已完成 Q&A 文章，趕快存起來，讓自己記得接力讀完：
1/ 前言
(影片秒數: 6:29)
如果你已經做產品一段時間，就會遇到很多困難與挑戰；如果沒遇到什麼困難，那表示你還做得不夠久。所以説，做產品遇到困難是很正常的事情，這也讓我想跟大家談談這些困難。這些跟我一直以來的寫作內容有關，跟我每一個合作的團隊也都有關，都是很真實很生動的主題，也令我發現「把這些問題攤開來」大家一起聊，會很有幫助。但我也要說，如果你是做產品的新手，這個分享會聽起來很有難度，因為我們會談論比較深的主題。我反而擔心你聽完以後，你可能會被嚇跑而不想做產品了！
(影片秒數: 8:56)
我對「產品團隊」(Product Team) 總是非常感興趣，因為每一個偉大的產品總有一個偉大的團隊，沒有厲害的各種角色組合在一起，就沒有偉大的產品。但我花特別多時間跟大家談談產品管理、產品經理，因為已經有很多人在談論設計、工程，但幾乎沒什麼人談產品，我覺得這是一個很大的空缺。
我也不諱言地說，我們產業最大的問題就是「有足夠的設計和工程，但常常沒有足夠的產品經理」。也不是說誰比較聰明，就是沒有人好好地訓練這些人，沒人教他們如何做產品。我非常幸運，可從很多厲害的人身上學習產品，這些人知道怎麼學習做產品。這些主管們真的知道自己在談論什麼，也會花心思引導你。我生涯的第一個 10 年在 HP 擔任工程師，在這 10 年的職涯中，至少都有一個人明確告訴我如何做得更好，讓我以為大家都這麼幸運。但真實世界並不是這樣，特別對產品經理來說，沒什麼人告訴他們如何做得更好。
這對「敏捷運動」 (Agile Movement) 來說也是很不幸的事情，特別在我們的同溫層中，當幾乎每個人都在呼籲要變得更敏捷的時候。有些人參加完 Certified Scrum Product Owner (CSPO) 訓練課程，就覺得自己是產品經理了，但其實這課程並不能教你如何當好產品經理，所以上完課的人還不足以勝任。「產品負責人」 (Product Owner) 的職責只佔了「產品經理」 (Product Manager) 約 5% 的工作內容。所以說，雖然 CSPO 是重要的訓練，但這不會教你如何當好 PM，這是整個產業的重要問題。
要學好做產品，目前多數人都仰賴一個「會做好產品的人」，跟他一起工作，且這人會花心力引導、訓練新人。理論上，只要能跟到這樣的人，任何背景的人都可以做好產品經理，不管你是工程、行銷、業務、客服。
稍微介紹我自己，我在 HP 從做工程師開始，然後加入了 Netscape。Netscape 是第一家網路原生的公司，也是現在 Mozilla 的原生地，有很多厲害的人，也是現代產品經理的原生地。在 Netscape 之前，在網路世代之前，做產品的方式被稱為 Microsoft Style，當然 Microsoft 現在追上網路時代了。Netscape 是第一個要考慮網路使用環境來做產品的公司，所以 Microsoft Style 做產品的方式對網路公司並不管用。
所以 Netscape 是第一個遇到這些問題的公司，因此在 Netscape 的人開始尋找做現代網路產品的方法，其中包含 Ben Horowitz。他寫了一本書是【什麼才是經營最難的事？】 (The Hard Thing About Hard Things)，可說是一本為新創公司創辦人和產品經理所寫的書。他最近寫了一本新書是 What You Do Is Who You Are ，其實也是一本關於 Product Culture 的書，建議大家閱讀。
Netscape 所找到的產品方法，很快地隨著 Netscape 人才換工作的過程，而擴散到其他公司，包含 Google、Amazon、Facebook、LinkedIn、Twitter，等等等。
因為 Netscape 在瀏覽器的戰爭中輸給了 Microsoft，所以很多人才離開並加入了其他公司，而我就加入了 eBay 擔任 Head of Product and Design，是一段很棒的經歷。再後來我很希望多跟新創公司一起工作，所以當時就和 5 個人一起，針對新創和成長階段的公司，給予諮詢與投資。過程中我也寫了一本關於產品的書 INSPIRED，去年出了第二版，被翻譯成數十種語言，這也是我今天在這裡的原因，為了新書出版。
接下來要分享的議題，都是做產品的常見問題，但他們彼此之間沒有先後順序，不過我敢說這是全世界都常見的問題。
2/ 突破敏捷的挫敗感？
(影片秒數: 16:44)
其中一個很常見的問題，是最近對於「精實」 (Lean) 和「敏捷」 (Agile) 方法的挫敗感，甚至是反撲。這和先前的炒作宣傳有關，讓很多人不了解精實和敏捷的核心原則。為了避免這個情況，我們先來回顧精實和敏捷的核心原則。
(影片秒數: 18:23)
敏捷的核心原則
當我們來看看敏捷和精實，個別其實就是幾個核心原則。
就敏捷來說，去除所有外圍的東西，只剩兩個核心原則：
第一是「要頻繁的發佈」，頻繁的意思是「至少每兩週發佈一次」。如果你每月或每季才發佈一次，就算你自稱敏捷，你其實沒有獲得任何敏捷的好處。好的產品團隊甚至每天發佈好幾次，就是所謂的「持續交付」 (Continuous Delivery)。也不是說大家都要做持續交付，但若你不是每兩週發布一次，這會是很大的問題。
第二是「團隊要被賦權且被問責」，被賦權的意思是「交由團隊來找解決問題的最佳方法」。舉例來說，不是由管理層告知團隊「請串接日本當地 LN 公司的行動支付」，而是告訴團隊「我們眼前看到的問題，是太少日本當地人購買我們的產品，海外轉換率實在太低了，請你們解決這個問題」。如果串接了日本當地 LN 公司的行動支付，沒有解決這個問題，團隊就要繼續探索其他方案。
很多團隊被告知要更加敏捷，但其實管理層一直給團隊「待完成的功能清單」（傳統意義上的產品路線圖 Product Roadmap），每月或每季都跟團隊説「請做這些功能」，這在任何意義上來說都不是敏捷。
這是敏捷遇到的很大問題，很多團隊沒被問責或沒被賦權。
就精實來說，背後也是只有兩個核心原則：
第一是「我們要快速學習才能創新」，創新源自於我們能夠嘗試多少點子，因為我們知道大部分的點子都行不通。
第二是「我們得要消除浪費」，所謂的浪費就是花了 4 個月才發現「這不是解決問題的好方法」，這就是浪費。在新創我常看見的浪費就是「我們正在做一個 MVP 」(Minimum Viable Product 最小可行性產品)。然後我就會問「太好了，那可以讓我看看 MVP 嗎？」結果他們就說「正在做了，還要 4 個月」。坦白說，這根本不是 MVP，只是個半成品、是不成熟的產品。真正的 MVP 只需要 4 小時或 4 天，不是 4 個月。
這些是精實和敏捷的核心原則，千萬不能放棄。那麼，到底是什麼原因，造成精實與敏捷的挫敗和反撲呢？
補充： 因為 Marty Cagan 指的是原型 (prototypes)，他認為所有的 MVP 都應該改名，被稱為 prototypes，如此就只需要 4 小時或 4 天，後面會說明更多。(影片秒數: 22:20)
為何「敏捷」還不足夠？
可能很多人看過這張圖，來自一個很有名的敏捷教練 Henrik Kniberg，他長時間在 Spotify 擔任教練。不過上次我跟他吃晚餐的時候，他說現在到 Minecraft 當工程師了，因為太想念當工程師的感覺了！
他想傳達的是「瀑布式」和「敏捷」的差異，以做一台車子來比喻。瀑布式流程會花好幾個月來確認每一個汽車零件，但敏捷會先做一個「可被測試」的東西。如果這個東西不管用，那就再做一個，看看我們做出來的東西是不是越來越靠近一台真正的車子。
但如果你是一個產品公司，這其實是一個真的很慢也很浪費的過程。
(影片秒數: 23:43)
在一個產品公司裡面，我們發現做產品有兩個非常不一樣的目標與階段。任何一個科技產品公司，都會遇到這兩種挑戰。
第一，我們要搞清楚「探索該打造的產品」，我稱之為「產品探索」(Product Discovery)。這個意思是要找到一個產品方案，符合以下四個條件：
- 對用戶有價值 (valuable)：就是顧客會買單
- 易於使用 (usable)：意思就是顧客能自己搞懂如何使用
- 可被打造 (feasible)：是我們知道如何打造
- 商業上可行 (viable)：我們的事業能夠處理這個產品，包含宣傳、銷售、客服，也有收益
第二，我們要「交付完整的產品」，也就是「產品交付」(Product Delivery)，是交付工程師有自信的產品，讓我們的事業可以靠譜的營運這個產品。這個最終產品要符合的條件是：
- 穩定 (reliable)
- 可擴展 (scalable)
- 高效能 (performant)
- 可維護 (maintainable)
- 支援多國語言又在地化 (internationalized and localized)
這些都是完整產品應具備的特性。有些人會說第一個是 “build the right product”，第二個是 “build the product right”。
「探索」和「交付」是非常不一樣的目標與挑戰，而令很多團隊遇到問題的情況，就是公司「要同一群人，在同一時間，處理這兩個挑戰」。例如，有些公司會叫團隊「交付產品時，也要確保這是正確的產品」，但這並不合理，會造成很多浪費。
補充：就我的親身經驗來說，叫團隊「交付產品時，也要確保這是正確的產品」，可能造成兩種浪費。第一種是團隊小心謹慎的閉門工作了 4 個月，發佈產品後發現這是錯誤的產品。第二種是團隊超級迅速的發佈了好幾次產品，其中有些成功了，但也創造了極大的技術債，打造了難以維護、難以擴張、很低效能的產品，得再花 4 個月償還技術債，令團隊無法繼續迅速發布。(影片秒數: 25:50)
「探索與交付」的循環迭代
所以，在產品開發團隊中，我們會分離這兩種活動、這兩種風險。
第一種，在探索階段，我們嘗試想出一個 valuable, usable, feasible, viable 的產品。
第二種，在交付階段，我們現在知道要打造什麼產品，我們有合理的信心去賣出這個產品、支持我們的事業，所以現在可以請工程團隊以可靠的方式打造這個產品。
我想要特別說明，這只是一個簡單的描述，不是完整的流程。舉例來說，現在已有很多交付階段的工作流程，其中 2 個最有名的流程是 Scrum 和 Kanban，除了這 2 個最受歡迎，還有很多其他的交付流程。同樣的，現在也有很多探索階段的工作流程，例如有多達 50 種探索階段的工作流程。
所以說，這只是個概念上的工作模式，想跟大家傳達的是： 我們要去解決問題，而不只是打造路線圖上的功能，我們被賦予的是解決問題的目標（而不是打造功能的目標）。
你可能聽過 OKR (Objective and Key Results 目標和關鍵成果) 的管理方法，這個管理方法正是發明於採用這種工作模式的公司，因為這種方法才能建立被授權的工作團隊，被賦予達成目標而不是打造功能。當團隊被賦予解決問題的目標，團隊才能找到解決問題的最佳路徑，然後再交付可靠的產品。而產品待辦事項清單 (Product Backlog)，就是探索階段中產出的有信心的待辦事項，等待在交付階段中被實現。
正如先前描述這個工作模式的一些方法，有人說探索階段就是 build the right thing，然後交付階段是 build the thing right。這裡再舉更多例子，一個是在 Google 的例子，Google 他們會說探索是 fake it，而交付是 make it，串起來就是 “fake it before you make it”。在 Facebook 的例子，他們會說 “move fast, don’t break things” (在探索階段要 move fast，在交付階段要 don’t break things)。我最喜歡的例子則是 AirBnB，這個描述方式對工程團隊來說是特別詭異，但他們刻意如此。他們描述探索階段是 build things that don’t scale，然後他們描述交付階段是 build things that do scale。
這就是大體上的工作模式，不管他們怎麼描述、不管有沒有精確的文字，我遇到的優良團隊都是這麼做產品。他們確保在最開始就面對產品失敗的 4 大風險，在探索階段知道應該打造什麼產品，然後才去交付產品。
補充：Marty Cagan 在 INSPIRED 書中，介紹了產品失敗的 4 大風險，分別是• 1/ 實行性風險 (Feasibility Risk)： 團隊確知需求，但手邊並沒有解決問題的技術，或技術尚未成熟，就是「我們知道要做什麼產品，但是做不出來」的狀況• 2/ 易用性風險 (Usability Risk)： 顧客想用這個產品，但不知如何使用，或太少人克服使用門檻，就是「產品做出來了，但是好多顧客看不懂、不會用」的狀況• 3/ 價值風險 (Value Risk)： 這個產品並沒有解決顧客需求，為顧客帶來價值，就是「產品做出來了，某些顧客也會用了，但後來都不繼續用，因為沒有滿足需求」的狀況• 4/ 商業可行性風險 (Business Viability Risk)： 這個產品對公司沒有商業價值，或無法在市場競爭中存活，就是「產品做出來了，顧客也愛用，但是無法賺錢，或拿不到更多預算與資金，或無法贏過競爭者」的狀況也可在這篇和這篇文章，找到簡短介紹。
在探索中用 Prototypes，不是 MVP！
在交付階段，工程師最重要的工作就是寫程式、打造真正的產品。在探索階段，我們只需要「原型」 (prototypes)，而不是「產品」 (products)。
(影片秒數: 29:23)
在探索階段只需要原型 (prototypes)，MVP 其實應該要是原型才對。MVP 這個名稱造成很多誤會，因為 MVP (Minimum Viable Product) 中的 P，把應該要是 prototypes 的東西誤稱為 products。所以，我總是在探索階段運用 prototypes，以免他人誤會。
(除了名稱上的誤會，) 如果你花 4 個月打造一個 MVP，這會是一個很大的問題。花 4 個月才打造一個 MVP，在探索階段來說實在是超級慢，但在交付階段可能又太快速了，所以沒有人會對此滿意。請記得，在探索階段打造 prototypes，在交付階段打造 products。
補充：關於 Marty Cagan 提到的產品探索技巧，可以參考 INSPIRED 的第 4 篇，第 33 到 56 章，裡面介紹了產品探索的原則、產品探索的技術概觀、用於探索階段的 4 大類產品原型、以及測試 4 大風險的主要技術。在本次演講的其他段落，將會多次提到產品原型 (Prototypes) 和 MVP 的混淆問題，並解說使用產品原型的重要性，你也可以先繼續往下讀。
3/ 你想要真正的 Product Team？
當我認識一個產品團隊的時候，我會觀察 3 件事，來判斷他們做產品的能力有多深。
第一件事，就是他們是否在進入交付階段前，就著手處理讓產品失敗的 4 大風險，這時候通常不需要寫任何一行程式碼。
第二件事，就是他們實際上用什麼方式解決問題。我期待他們結合了產品經理、設計師、工程師，讓彼此交互切磋，然後產生一個最好的方法。他們是用共同協作的模式來解決問題，還是用依序接力的方式來解決問題？在過去瀑布式 (Waterfall) 的模式下，產品經理會定義產品需求規格，然後丟給設計師來負責把畫面弄好看，然後再把一整包爛攤子丟給工程師。若是在衝刺規劃會議 (Sprint Planning) 上才第一次跟大家說「開始打造這一切」，雖然有 Scrum 裡面的衝刺規劃會議，且這些人說他們很敏捷 (agile)，但這根本不是敏捷，這只是瀑布式，因為人們就是在彼此接手各種工作而已。
第三件事，就是他們被賦予的目標。如果他們被賦予的是發佈功能，那只是個「產出」 (output)。如果他們被賦予的是解決問題，那正是個「成果」 (outcome)。我期待看到的是專注在成果 (outcome)，並以成果來衡量自己的團隊。
如果有發生這三件事，其他的議題也就不太重要，為此我就能判斷這是一個良好的團隊。
(影片秒數: 32:20)
很多公司，也可說是大多數我在世界各地遇到的公司，大體上都知道做產品的基本知識。他們知道不只需要工程師，還需要產品經理、設計師，大多數都建立了跨專業跨領域的團隊。有些公司稱這樣的編制為「產品團隊」，這也是我常用的稱呼，而有些則喜歡用 Spotify 的方式稱呼為 Squad。這些都很好，但問題是要建立這樣的團隊編制並不難，困難的是要能在前面那 3 件事上面，落實的夠徹底、夠深遠。很多公司仍然只是制定產品路線圖，賦予給團隊的任務不是探索與交付，只是設計與開發。
有些公司甚至還聲稱有「探索階段」，但實質上我知道他們並沒有這麼做，因為我會用這個問題來探測：「你們在探索階段會測試多少原型？你們在交付階段又會打造多少？」如果他們說：「喔，上個月我們在探索階段測試了 10 個項目，然後這個月我們打造了 10 個項目。」這樣我就知道這不是探索，這只是設計，也許附帶一點點易用性測試，並不是真的在測試點子。如果他們很認真實施探索階段，很認真的測試 4 大風險，他們必然要拋棄非常多當初的點子，至少要拋棄一半。附帶一提，真正優良的產品公司甚至會拋棄 80% 到 90% 的原始點子。微軟最近在哈佛商業評論 (Harvard Business Review) 上公開地說，他們大概只有 10% 的點子真的可行。
如果他們沒有真正落實探索階段，儘管這些公司稱呼團隊為「產品團隊」 (Product Team) 或 Squad，他們實際上仍然只是個「功能團隊」 (Feature Team)，而且世界上大多數的公司都是這個樣子。他們有產品經理 (Product Manager)、有設計師和工程師，但他們的產品經理實際上只是個專案經理 (Project Manager)，這真的很常見。
我們回顧一下打造產品的 4 大風險： 價值 (Value)、易用性 (Usability) 、實行性 (Feasibility)、商業可行性 (Viability)。你可能知道設計師要負責易用性，當然他們大可以貢獻更多。你也知道工程師要負責實行性，當然他們也是大可以貢獻更多。
如果你只是一個被交付「路線圖」 (Roadmap) 的功能團隊 (Feature Team)，實際上有一個不那麼明顯的狀況正在發生： 若某個公司內的高管 (executives) 或利益相關人 (stakeholders)，只要他們要求把某個項目加到產品路線圖中，這個人其實就負責了該項目的價值風險 (value risk)。舉例來說，如果某個人說「我們必須加上 PayPal 這個支付方式」，不管是誰說的，這個人肯定是相信這件事有價值，他才這麼說，否則他就不會這樣說。同時間，這人其實也負責了這個項目的「商業可行性」 (business viability)。這時候，產品經理實際上要負責的是專案管理。
如果這是一個被授權的產品團隊 (Empowered Product Team)，他們被交付的是問題與目標，而不是產品路線圖。在真正的產品團隊中，產品經理則要負責的是這個解法能夠 (為用戶) 帶來價值，在商業上也可行。所以說，當我們要談論現代的產品經理，我們要在真正的產品團隊中談論，而不是在功能團隊中談論，這才是我們應該談論的事情。
我也必須要誠實的說，功能團隊中產品經理的工作，遠遠比產品團隊中產品經理的工作簡單許多。在產品團隊中工作的產品經理，要承受更大的壓力、需要具備更多的技能、每天可能要睡得更少。這不是說專案管理不重要，這很重要，但這不是產品經理工作中的核心。
我也想跟你說，這個問題在很多地方都有出現。譬如說，有很多網路時代前就存在的公司，他們常常說自己需要做數位轉型 (Digital Transformation)，但他們就只是設置了一個功能團隊，然後他們還沒搞清楚，為什麼這沒有帶來什麼改變。數位轉型需要的是產品團隊，但他們還沒搞懂。為什麼這麼說呢？因為這些要做數位轉型的公司，其實就是想和 Amazon 這種公司競爭，但產品團隊正是 Amazon 和 Google 採用的模式。很不幸的是，就算功能團隊看起來和產品團隊很像，他們終究不是 (因為沒有實質內涵)。
坦白說我不知道在台灣的情況，就算是在舊金山、紐約、西雅圖，也只有 10% 到 20% 的公司有真正的產品團隊，剩下的都是功能團隊，這真的是全世界都很常見的問題。很多人常常以為這些卓越的產品團隊都在舊金山，到了南韓或新加坡就很難看到這種團隊，事實上不是這樣。首先，在舊金山，也有很多糟糕的團隊，我看過很多。這對我來說當然很驚訝，因為過個馬路就有另一個卓越的團隊、來自卓越的公司。其次，在全世界各個角落都有卓越的產品團隊，我遇過的一些頂尖團隊其實在北京、班加洛、斯德哥爾摩、柏林，到處都有。
補充：就我的親身經驗來說，產品路線圖 (Roadmap) 在某些情境下非常必要，有助於產品團隊在較大型的組織內溝通協作，因此路線圖 (Roadmap)本身不是問題，問題在於該組織或團隊運用路線圖的心態。如果我們能 (能為自己和團隊) 醞釀出使用路線圖的健康心態，才能趨吉避凶、利大於弊。健康的心態可能是：• 1/ 路線圖不等於承諾： 不是一張甘特圖，不是一個發布計畫• 2/ 只是一個雛形，有彈性調整空間： 這只是一個策略的原型，呈現我們目前對於解決問題、達成目標的可能路徑• 3/ 只是一個工具，用來凝聚團隊： 這同時是一個溝通與協商的工具，促使團隊理解資源有限，我們必須取捨，而在取捨的過程中，我們彼此盡可能溝通、討論、釐清利弊得失，為了凝聚團隊在後續執行的方向感醞釀出上述心態並不容易，前提仍然是我們能取得「信任」，進而獲得來自老闆們、相關協作團隊們的部分授權。在沒有信任的情況下，路線圖只會成為一個利益爭奪的場所，產品團隊也會失去對路線圖的掌握度，變成功能團隊 (Feature Team)。關於信任，正好銜接到下個主題 - 如何取得信任？
4/ 怎樣讓老闆們信任 Product Team？
(影片秒數: 40:15)
好，來談下一個問題。雖然這些問題沒有按照順序，但如同我說的，這些是一旦你開始做產品，就開始體會的問題。
現在，其實很容易讓產品團隊學到各種探索的技巧，迅速的測試，然後判斷一個產品概念是否可行。今天如果一個高管説「我們需要串接 PayPal 這個支付方法」，如果你學會了現代產品方法的探索技巧，只要幾天的時間，你就可以搞清楚它能否帶來效果，而且是在動工以前就搞清楚。
很多團隊擅長這些探索與測試的技巧，但仍然發生很不幸的情況。當高管或利益相關人説「我們需要做這個、做那個」，而產品團隊幾天後回頭說「我們不打算做這些，因為測試後發現這些構想不可行，原因如下…」。問題是，經過幾次這樣的情況，高管們開始覺得很挫敗，因為他們只聽到「這些不可行」，他們肯定會納悶「那你們到底要做什麼？」
我試著跟產品團隊説，你們的工作不只是告訴大家「為何這些不可行」，你們的工作還必須告訴大家「這些構想更能解決問題、更有機會成功」。如果今天的課題是「國際交易支付量過低」，產品團隊除了告訴大家「串接 PayPal 不是個好方法」，還必須告訴大家「PayPal 以外還有哪些方法」可以解決問題，這才是優良產品團隊和新手產品團隊的差別。優良的產品團隊知道，自己還必須提出可行的方案，而且這些方案要更有機會成功。
我們可以在很多公司，見證這種做法的影響力。因為，只要產品團隊開始展現這些能力，高管們開始認定這些團隊是「問題排除者 」 (Problem Solver)，而不是「阻礙者」 (Blocker)。只會驗證點子 (validating ideas) 的團隊是阻礙者，你可以在很多公司看到這樣的症狀。
5/ 要花多少時間在 Prototyping？
(影片秒數: 42:40)
這是一個棘手的問題，讓我來告訴你為什麼。
大家都知道，在開工以前，花點時間想一想手上的問題，是個不錯的做事方法。但問題是這樣的，的確我們有很多思考問題、架構問題、規劃工作的技巧，但你必須非常注意時間，因為從你接下問題的那一刻，有個碼表就被啟動了，公司的執行長和高管們心裡就開始算時間，他們心裡會算「好，又過了一天…又過了一個月…」，就是這個碼表在計時。如果你花了大部分的時間做規劃，你就沒剩多少時間去提出一個可能成功的方案。然後，很快地你的老闆們就失去耐性。
因此，我時常試著告訴團隊，你必須控制你的步調，不能做一大堆分析而已。做產品最困難的部分不是規劃，最困難的是「提出可能成功的方案」。當我說「可能成功的方案」，意思要能「促使顧客轉換」到你的產品，不管先前他們用誰的產品。這聽起來簡單，做起來非常難。
很多新手產品人會用「功能均等」 (Feature Parity) 的策略，以為只要具備「頭號競爭對手提供的所有功能或服務」，就可以擁有很多客戶，但經驗上這幾乎不可能成功。事實上，前面提到的 Ben Horowitz 曾這樣跟產品團隊說：「功能均等」不會成功，因為要讓顧客願意轉換到我們的新產品，顧客得相信新產品能提供比過去好上 10 倍的成果，顧客才會願意忍受所有轉換過程的痛苦與風險。要量化「好上 10 倍」，其實也很困難。好奇問一下，現場有多少人用 Slack？噢！真驚人，幾乎是所有人。你的公司可能從 HipChat 轉換到 Slack，這個過程並不簡單。你們願意轉換，因為你們團隊認為 Slack 是企業通訊軟體最好的選項。
這就是為什麼做產品很困難，你的產品必須被認為是「顯著的好上很多」，而這不會從「產品規劃」 (Product Planning) 中達成。你可以做一堆規劃但產品也不怎麼樣，因為這要從「製作原型」 (prototyping) 來達成。這就是產品探索 (Product Discovery)，嘗試各種點子、驗證哪些概念可行，持續在探索中迭代，直到找到有可能成功的方案。
所以我想強調的是，如果你要解決一個困難的問題，你的確需要花一點時間做規劃、做分析，我們有很棒的方法，只要花你幾個小時，但你應該要花大部分的時間來做探索 (Discovery)、提出一個有可能成功的方案。如果你不這麼做，你不會有更多時間。
有點抱歉的是，我接下來舉的例子會用到刻板印象。有很多產品經理來自管理學院、MBAs，有很多因素讓 MBA 畢業生們喜愛做規劃，他們很愛手上的試算表，他們就從中獲得很多樂趣。遇到這樣的人，恩，我會說「ok 很好，但這不是你的工作！」這也只是簡單的部分，困難的部分是當你把手弄髒的時候，你必須坐下來、找設計師和工程師，一起提出可行的方案，任何世界上的規劃技巧都不會帶你找到可行的方案。
當然我只是打趣地亂說話，我認識很多卓越的產品經理來自 MBAs。但因為 MBAs 有這樣的思維習慣，每當我雇用 MBA 背景的產品經理，我必須打破這樣的習慣。舉例來說，MBA 有些受歡迎的產品技巧，像是用途理論 (Jobs To-Be-Done)。別誤會我，這是個不錯的技巧，但我很少推薦它，因為做完全套流程實在太花時間。如果你真的走完全部流程，你幾乎沒剩多少時間來提出可行的方案，時間成本昂貴到你無法負擔。如果你是 Samsung 要推出新手機，如果這是個長期的計畫，你可以負擔這樣昂貴的成本，也許合理。但對在座的所有人，這不合理，因為我們有更輕量、更快、更低成本的規劃技巧，只花幾個小時，然後立刻開始做探索等實際的工作。
我想更清楚的指出，如果你是產品經理或產品設計師，你大部分的工作天都應該花在製作原型 (prototyping)。當然，是由產品設計師製作這些原型，然後由產品經理來親自試用、測試、從中學習，但你們也是一起透過製作原型 (prototyping) 來迭代 (iterate)。產品經理與設計師運用原型，工程師運用程式碼，這就說明了我們如何一起工作。基本上這就是你大部分的工作，你將展示 prototypes 給不同類型的用戶、顧客、利益關係人，你將會在團隊中測試它們，這才是產品經理與設計師的真正工作。這也是為什麼我們需要真正的 「產品設計師」(Product Designer)，今日設計師受訓練的方式也正是透過製作原型 (prototyping)，這對我們很關鍵。
再強調一次，所有的 prototypes 都是 MVP，但我更喜歡用 prototypes 來稱呼，因為我想強調這不是真正的、完整的產品。除此之外，有 4 種不同類型的 prototypes，所有優良的產品團隊都要善用 4 種 prototypes，我們實際上也需要 4 種 prototypes 來面對不同的工作、處理不同的風險。有些專門用來量化測試，有些則用來質化測試，所以優良團隊都需要做這些。
以上，就是為什麼我們要平衡 planning 與 prototyping。
補充：關於 Marty Cagan 提到的 4 種原型，在 INSPIRED 的第 45 到 49 章，分別介紹了原型的原則，以及 4 種原型• 實行性原型 (Feasibility Prototypes)
• 用戶原型 (User Prototypes, Low-Fidelity or High-Fidelity)
• 即時資料原型 (Live-Data Prototypes)
• 混合原型 (Hybrids)也可以在這篇和這篇文章中，找到產品原型 (Prototypes)的簡短介紹。至於如何測試產品原型，可以在這篇文章中，找到進行產品原型測試的更詳細說明，或是參考 INSPIRED 的第 4 篇，第 50 到 56 章
6/ 滿腦子只有單一方案？
(影片秒數: 50:40)
這個問題，和前一個很相關，也是人類的天性，很常見。當我們被賦予一個問題，例如要改善國際的購買比例，或要降低流失率，或要增加營收，或要找到新市場的第一個參考客戶，不管是什麼目標、要解決什麼問題，我們很自然的會立刻獲得一些點子，不管是自己想的或他人提供的。然後，我們就決定嘗試這個點子，立刻開始製作原型。這很好，但問題是，如果這是我們唯一認真考慮的點子，而且這個原型其實最後不成功，那然後呢？該怎麼辦？
很多團隊接著採取的行動，就是繼續製作原型 (prototyping)、繼續 20、30、50 次迭代，直到他們用完所有的時間，或直到放棄。其實，你真正想要理解的是「總是有很多種解決問題的方法」，所以當你在做少量規劃的時候，你要確保自己記得「這裡有 5 種解決問題的方法」，至少要把這件事記在心上。我們認為其中一個方法最好，所以從這裡開始，但如果我們沒獲得成果，我們就要嘗試下一個。
舉例來說，有個 Teresa Torres 和我都呼籲的方法，叫做「機會與方案樹狀圖」 (Opportunity Solution Tree，可看這篇文章了解更多)。如果你沒聽過 Teresa，她是個很棒的產品探索教練，是她讓這個方法流行起來。這是個快速、輕量的規劃技巧，讓我們架構自己的工作。
7/ 道德上應該推出產品嗎？
(影片秒數: 52:57)
這是一個完全不同的主題，但這在我們產業中也不是個秘密，就是說我們不夠用心思考道德上的風險。
前面我提到產品失敗的 4 大風險： 價值 (Value)、易用性 (Usability) 、實行性 (Feasibility)、商業可行性 (Viability)。除此之外，我常鼓勵團隊多考慮第 5 個風險，也就是道德風險 (Ethical Risk)，就是問自己：我們應該打造這個產品嗎？
換句話說，就算用戶喜歡我們的產品，這對用戶來說真的是件好事嗎？舉例來說，用戶是個 14 歲的青少年，你成功的讓他一天花 4 小時在手機上，這是件好事嗎？如果這是個教育類的科技產品，可能是件好事，但如果這是個遊戲，也許不是件好事。這是我們要留意的事情，而且不只是對用戶，也要想這對社會是好的嗎？對我們事業是好的嗎？這合法嗎？有些公司正在嘗試的事情，可能在法律的邊緣上，這顯然不是件好事。
同時，你也要了解，公司在大多數時候都不刻意造成問題，大部分都是無意的。但我想強調的是，產品經理通常是第一群看到潛在問題的人，因為他們就在第一線，觀察對顧客與用戶的影響。所以，如果你看到打造中的產品有什麼問題，你真的會想要提出這個議題，向你的主管提出討論，甚至向你的執行長提出。當然，這是個很敏感的問題，你需要和緩地、輕巧地提出，你要確保自己做足功課，真正瞭解事業如何運作。總之，很顯然地我們這個產業，應該在這方面做得更多。
8/ 只有無盡的產品優化？
(影片秒數: 55:09)
這也是個完全不同的問題，但也真的很常見。
今日，有非常多做產品優化上很棒的工具，例如 Optimizely、Google Optimize。說清楚一點，這裡講的「產品優化」 (optimization)，指的是低風險、線上流量、即時資料的 AB Testing。我們基本上是微調各種元件，看哪一個成效更好，最常見的就是做在轉換漏斗 (funnel) 上。我強烈建議每個團隊，只要你有正在線上的產品，你獲得了真實的流量，你就應該執行這些測試，沒有任何不這麼做的理由。
但問題是，我看到很多公司，這就是他們做的所有事情了。我可以告訴你，如果這是你唯一做的事情，你正在一個緩慢死亡的道路上，因為這只是「捕捉價值」 (value capture) 的活動，就像提高價格一樣。這是件好事，沒什麼不對，但如果你只做這件事，你只是逐漸消耗價值而已。我們身為產品人的工作，是要創造更多價值，大於我們捕捉到的價值。產品探索 (Product Discovery) 就為了「創造價值」 (value creation)，產品優化 (Product Optimization) 只為了捕捉價值 (value capture)。
所以，不要只做產品優化，要確保你創造更多價值。
9/ 勢不兩立的量化與質化？
(影片秒數: 56:47)
再來一個問題，這某種程度上碰觸到公司文化。當你剛認識一間公司，很快的你可以稍微看出他們的文化。有些是極度偏重量化驅動的文化，他們的執行長非常相信量化驅動的決策，又有另一些公司的執行長極度相信她或他的直覺，這則是非常質化導向的文化，這些都是很文化性的現象。
我總會試著跟兩類型的老闆們解釋，每一個優秀的產品公司，沒有例外，都必須擅長兩種方法，因為它們回答很不一樣的問題。
量化測試告訴我們「實際上發生哪些現象」，但它的限制和主要的問題，就是無法告訴我們為什麼。量化分析能告訴我們「App 中 3% 的用戶使用此功能」，但它沒辦法告訴我們「為何另外 97% 的用戶不使用」，質化測試就在此時派上用場。所以，好的公司都必須擅長兩種技巧。
就以 Google 來說，這家以數據為典範的公司，擁有如此巨大流量的公司，其實長期以來都在做質化測試。又以 Apple 來說，這家以質化洞見為典範的公司，他們的量化分析也做得一樣好。我會這麼說： 在 Google 的標準測試要基於量化方法，但當他們要獲得解釋時，就會運用質化方法；在 Apple 每天都做質化的測試，但當他們要獲得數據時，就會運用量化方法。他們兩種都用，因為兩種都有偏誤，兩種很不一樣但都有用。
10/ 產品管理的核心能力？
(影片秒數: 59:22)
基本上，幾乎所有之前提到的議題，都有賴於具備核心能力的產品經理。在今天的開頭，我提到我們產業的一個大問題，就是大部分的產品人 — 不管職稱是產品負責人 (Product Owner) 還是產品經理 (Product Manager) — 都欠缺足夠的訓練，他們還沒真正學會如何做好自己的工作。也就是說，他們還不具備足夠的核心能力。
這裡要清楚解釋一下，產品經理 (Product Manager) 是工作上的職稱，而產品負責人 (Product Owner) 是這些人在敏捷團隊中扮演的角色。正如同交付經理 (Deliver Manager) 是工作上的職稱，而敏捷專家 (Scrum Master) 是這些人在敏捷團隊中扮演的角色。如果你有一個產品負責人，其本身的工作職稱不是產品經理，那是另一個問題，通常你要確保產品經理就是產品負責人。
回到產品經理的核心能力，到底是什麼呢？
產品經理的 4 大核心能力
(影片秒數: 60:30)
我認為有 4 個核心能力：
• 對用戶和顧客的深入知識
• 對用戶資料的深入知識
• 對事業的深入知識
• 對產業的深入知識
作為一個產品經理，你的產品團隊有賴你提供以上知識。不過我也要說，如果你是功能團隊 (Feature Team) 的產品經理，那麼你並不需要這些，你最需要的是足夠的專案管理能力。如果希望在被授權的產品團隊擔任產品經理，那這些也就是你給自己的約定。和你一起工作的設計師和工程師也都有賴你為團隊提供這些知識，因為要是你沒有，那每一個決定都要提報給執行長或某個高管 (executive)，或者你要召集很多利益相關人會議 (stakeholder meeting)，在會議中要大家對每一個決定投票，這些都是惡夢。
(1) 對用戶和顧客的深入知識
第一個，對用戶和顧客的深入知識，這通常要產品經理花上 3 到 4 個月來養成。我時常收到產品經理的抱怨，多到我無法告訴你有多頻繁，這些人會抱怨執行長 (CEO) 持續地推翻自己的決定。遇到這種狀況，我會問這些產品經理：「好，那請告訴我，上次你遇到客戶是什麼時候？」通常答案是上個月或上一季，然後我接著問：「好，那上次你的執行長 (CEO) 遇到客戶是什麼時候？」通常答案是「幾乎每一天」，因為執行長 (CEO) 會頻繁地拜訪客戶、或客戶會自己找上門。如果是這樣，那我就會說：「聽著，如果我是你的執行長 (CEO) ，我也不會信任你的決定。為何世上會有執行長 (CEO) ，讓不瞭解客戶的產品經理 (Product Manager) 做決定呢？」期待發生這種事，並不實際。
產品經理最基本的知識，就是要真的非常了解用戶或客戶。我到現在都還記得，第一個輔導我擔任產品經理的人告訴我的事情，那是我剛從工程師轉任產品經理的時候。這裡補充一下，在我當產品經理的生涯中，除了在 eBay，我都負責為工程師製作產品，我很愛打造開發者工具與產品，這很好玩。我自己當過工程師，要為工程師打造產品，我心想「我沒問題的，我很了解顧客，他們就和我一樣！」那個輔導我的人，他的名字是 Mike Bako，他知道我其實根本不了解我們的客戶。他跟我說：「聽者，在你被允許做任何決定以前，你必須先去拜訪 30 個客戶。」這裡指的是 HP 的客戶，所以他給銷售團隊打了幾通電話，然後跟我說：「你要開始一個 3 週的出差，然後拜訪 15 個美國公司，以及 15 個歐洲公司，等你拜訪完我們再來聊。」
這在 HP 是很常見很正常的出差，但在這 3 週的旅行之後，我成為了一個完全不同的人。首先，我發現有上百種「顧客跟我們不一樣」的方式，特別是很多 HP 客戶公司內的工程師，跟我們非常不一樣。這些客戶可能是銀行、保險公司，他們的工程師所受的訓練和我們很不一樣，有些人甚至不把自己稱作工程師，可能只叫自己是分析師或程序員。
當然，Mike 早就知道我和顧客不一樣，所以我必須去見見這些人。對我來說，這 3 週是個瞭解顧客的速成班，讓我真正理解顧客需要什麼、遇到什麼困難，我們當然有很多產品可以滿足他們，但這些需求就是跟我們內部的需求很不一樣。除此之外，我也和很多顧客建立的關係，直到今天我們會在 LinkedIn 上聯繫，甚至我到法國時也會碰面。同時，我也和銷售團隊建立了關係，所以我有了一整個網絡，幫助我了解顧客、了解我們銷售和行銷產品的過程，這裡有太多我不知道的事情。
這就是產品經理要具備的第一個能力，你必須被認為是最了解用戶或顧客的一位專家。對大眾 2C 產品來說這可能不會太難，但對企業 2B 軟體來說這需要很多工作，因為 B2B 產品可以很複雜，要各種不同的用戶，包含負責評估採購、負責批審預算的人，產品經理要了解這裡面的動態關係。
(2) 對用戶資料的深入知識
第二個，要對顧客使用產品所產生的實際資料，有深入的知識。這是今天對比我當年初次做產品時的最大差異，那時候是網際網路之前的時代，我們不像今天有這麼多的數據。今天的產品經理，每天早上剛開始時，應該要花 1 到 1.5 小時在數據工具上。至少有 3 種看數據的角度與工具，第一種是看用戶如何在各種裝置上使用產品，第二種是看長期的數據變化，第三種是看銷售數據和銷售行銷活動的表現。
團隊有賴產品經理具備這些知識，所以當我們每週做即時數據測試的時候，團隊希望知道我們的產品表現如何。這是另一種了解用戶的方式，產品經理必須帶給團隊。
(3) 對事業的深入知識
第三個，必須非常了解你所屬的事業。我必須誠實的說，很多產品經理最不喜歡的工作就是第三個，但這也是 4 個核心能力中第二重要的部分，最重要的是瞭解用戶。如果你聽過這句話「在被授權的產品團隊，一位厲害的產品經理就如同這個產品的執行長 (CEO) 」，這就是在講第三個核心能力，因為另一個必須如此瞭解事業的工作，就是擔任執行長 (CEO) 。
所謂的瞭解事業，就是說你要很了解「哪些營收支付了這個產品的開發與營運？經費從哪來？成本結構是如何？」你還必須了解產品如何被行銷、如何被銷售、如何進入市場、如何抵達顧客面前，你還必須了解過程中的各種限制，例如政府法規、隱私、商業合約等所有的限制，甚至還有我們如何做售後服務、如何異業合作。你必須了解這個事業的各種面向，因為你必須確保團隊打造的產品能夠成功抵達顧客面前、為公司創造營收、支付相關的成本，這就是第三個核心能力。
(4) 對產業的深入知識
第四個，對產業很深的認識，譬如說，目前的競爭格局、重大趨勢。機器學習對我們的產品重要嗎？你必須有個看法。做產品很大的挑戰是要一直往未來思考，冰上曲棍球的俚語説「注意冰球即將前往的地方，而不是它走過的地方」，意思就是要看向未來的趨勢，而不是今天的情況。
所以，這些就是產品經理被期待的標準，這就是夠格的產品經理的內涵。如果你是產品經理，你主管的職責就是確保達到標準，否則你不能為團隊做任何決定。
11/ 輔導產品經理
(影片秒數: 70:16)
我可以跟你保證，如果產品經理的主管們真的落實這件事，今天將是很不一樣的世界。很可惜的是他們沒有做到，因為他們多數人也不知道這是怎麼一回事、他們自己從沒做過、他們從沒看其他人做好過、或他們從沒待過這樣運作的公司，所以對他們來說這也很困難。但總之，就我的底線來說，每當我遇到不夠格的產品經理，通常都是他們沒被好好的訓練、沒被好好的輔導，所以我的挫折感不是針對這位產品經理，是針對他們的主管，因為我們要對主管問責，確保他們帶好產品經理。
我時常跟主管們說，你頂多就和你最弱的那個產品經理一樣強，所以你真的要好好花時間輔導和提升產品經理們，這是產品領導者最重要的職責，這真的要說的很清楚。當然，還有其他很重要的職責，例如產品策略、願景、目標，但所有事情都有賴於具備夠強的產品經理。產品團隊也就只能跟他們的產品經理一樣強，如果產品經理不夠格，那麼你就是浪費優秀的工程師、設計師，而這些人都需要公司負擔很大筆的支出。
補充： Marty Cagan 對輔導產品經理有多重視？他目前在 SVPG 部落格上，至少寫了 11 篇關於「如何輔導產品經理」的文章，值得一讀。例如，Coaching Tools – The Assessment 這篇文章，分享了如何衡量現任或候選產品經理的狀態與能力，分成用 People, Process, Product 三面向。而在 Coaching Tools – The Plan ，則談到衡量之後如何建立能力發展計畫。最後一個例子，在 Coaching Tools – The One on One 中，則分享了「一對一定期會談」的原則，這是個輔導過程中最重要、最簡單、也最容易被忽視的工具。12/ 贏得信任的被授權團隊
(影片秒數: 71:58)
最後一個問題，講完這個就可以進 Q&A 時間。關於「被授權的產品團隊」 (Empowered Product Team)，如果你不確定自己的團隊是「被授權的產品團隊」或「功能團隊」 (Feature Team) ？首先呢，如果你有這個困惑，你們很可能就是個功能團隊，但我當然很希望你能對此感到肯定。
其實有一組簡單的 3 個測驗，通過了表示這是一家有「被授權的產品團隊」的良好公司。
第一個，你們有真正的跨專業跨領域團隊嗎？這個意思是說，對你們的產品來說，要做好這個產品，需要哪些專業技能？通常來說，是需要產品經理和產品設計師。當我說產品設計師，我指的是一位精通服務設計 (Service Design)、交互設計 (Interaction Design)、視覺設計 (Visual Design)、甚至通常是受過用戶研究 (User Research) 訓練的人，這是一個典型的「產品與用戶體驗設計師」 (Product / UX Designer) 的技能組合。更直白的說，我們真正仰賴的技能是交互設計 (Interaction Design)，這比視覺設計 (Visual Design) 的要求還更多，當然視覺設計很重要，特別對消費性產品來說，只不過這是很普遍的技能。
第二個，真的被授權嗎？具體來說，他們有被賦予要解決的問題嗎，而不是被賦予要交付的功能？要被解決的問題，可能是商業的問題、用戶的問題，總之就是一個待解決的問題，而不是要交付的功能，或要完成的專案。而且，團隊被允許使用最佳的方式來解決問題嗎？這些是備授權的團隊的主要概念。
第三個，他們被問責和被衡量的方式，是根據解決問題了嗎？換句話說，是衡量他們的成果 (outcome)，而不是他們的產出 (output)？
事實上，大部分的產品團隊和產品公司，並不常討論「上市時間」 (Time to Market)。但請不要誤會我，期限在產品公司是很重要，但問題是要滿足期限其實並不困難。如果你已經持續做科技產品一段時間了，你總會找到方法滿足任何被要求的期限。我總會砍功能、降低品質，直到我們找到方法在期限前完成，但這就變成一個空洞的勝利。
對產品公司來說，真正重要的不是 「上市時間」 (Time to Market)，而是「變現時間」 (Time to Money)。我說變現時間並不每次都指金錢，變現時間的重點是「真正解決問題的時刻」 (time to actually solving the problem)。如果問題是流失率是毫無永續性的 12%，我們知道我們的商業模式將會崩解，除非我們把流失率降低到 6%，那我們就是要把問題搞定，在降到 6% 之前都不能慶祝。這就是我們說的變現時間，就是那麼降到 6% 的時刻，這可能表示需要 100 種不同的功能或重新改版，或任何該做的事情。
補充： 關於產品團隊的組成，Marty Cagan 在 INSPIRED 的第 2 篇，第 9 到 21 章介紹了建立產品團隊的原則、團隊中每個角色的定位，以及擴展團隊時需添加的角色，甚至還建議了高階主管們的分工方式，值得一讀。
總之，這就是我們尋找的三件事。如果你的團隊有這三件事，我們認為這就是你們想要的境界，所有我認識的世上最好的團隊，都很真實的落實這三件事。你會發現，這裡面沒什麼神奇的魔法，你沒有什麼做不到這三件事的理由。你沒有這麼做的主要理由，通常主要原因是執行長 (CEO) 還不信任這個產品團隊。現在，為了獲得這樣的信任，我們要回到有能力展現核心能力的產品經理身上，就是先前我談的那些能力，就是這些讓我們贏得執行長 (CEO) 的信任。
補充： 為了集結更多產品經理的實戰經驗分享，三眼怪 3PM 網羅了海內外業界產品開發相關領域的朋友們，來分享更多實戰經驗、職涯心得，三眼怪說『不同產業、不同產品領域、不同商業模式之下 PM 的工作也都不盡相同，我們希望連結世界各地優秀的台灣 PM 們，藉由分享優質的內容協助 PM 社群交流學習』，還用心整理了【PM 總動員系列索引】海內外台灣產品經理的實戰經驗與知識精華 這篇索引文！🔖好了，這是我的郵件信箱，想找我的人都歡迎寫信給我，讓我們現在開始問答討論吧！
這些就是 Marty Cagan 去年 11 月在台灣的演講內容，非常感謝當天支援活動的超多夥伴，以及 ProductTank / MTP 全球社群的牽線。除此之外，也要感謝 4 位贊助夥伴，分別是 PicCollage、arc() x codementor、Mozilla Taiwan、Pinkoi，讓 200 多位觀眾近距離和 Marty Cagan 互動。
謝謝你讀到這裏，相信你（跟我們一樣）有很強的學習動機，才讀完上萬字！
