本文來自Marty Cagan去年11月在臺灣的演講視頻，視頻來源Youtube視頻，已被逐字翻譯成了繁體。但仍存在差別，針對一些難以理解的語句，我再次進行了翻譯，原文由3PM LAB出品。
因為演講內容與我產品的引路人對做產品的理念也十分相似，非常推崇，所以細心整理分享，希望對大家也有幫助，開始吧！
全文共19500字，閱讀時間50分鐘建議先收藏
Marty Cagan是享譽全球的產品大師，【INSPIRED:產品項目管理全書】的作者，擔任許多知名公司的產品教練與顧問，也是全球的產品社群中的思想領先者。曾和許多資深的產品經理一起工作(或有私交) ，包含任職於Netflix、Google、Apple、Adobe、BBC的產品經理。他參與了第一家網路產品公司Netscape的創業歷程，然後再到eBay擔任產品與設計副總(VP of Product and Design) ，之後創辦了Silicon Valley Product Group，網羅眾多資深產品人，專門為科技公司做產品顧問。
透過ProductTank Taipei社群的籌備，Marty Cagan去年11月難得第一次來臺灣演講。為了向更多朋友分享Marty Cagan的產品心得，社群夥伴們張羅了當天錄影錄音的支援設備，並釋出影片。為了加速內容的傳播與擴散，我重看了錄影，將演講內容翻譯成中文，並自行編修為每一段加上標題、刪除了部分的聊天內容、加上段落補充說明，希望能幫助大家吸收演講內容。
Marty Cagan 長達70 分鐘的演講，有以下內容：（百分比為大概位置便於直接查看）
1/前言（10%）
2/突破敏捷的挫敗感？（20%）
3/你想要真正的Product Team？（45%）
4/怎樣讓老闆們信任Product Team？（55%）
5/要花多少時間在Prototyping？（60%）
6/滿腦子只有單一方案？（65%）
7/道德上該推出產品嗎？（68%）
8/只有無盡的產品優化？（70%）
9/勢不兩立的量化與質化？（72%）
10/產品管理的核心能力？（75%）
11/輔導產品經理（85%）
12/贏得信任的被授權團隊（88%）
此外，還有另外一小時的Q&A 問答互動時間，但礙於本文篇幅已經太長，希望下次再寫成另一篇文章。如果你也想看Q&A，別忘了拍手鼓勵喔！
估計本文閱讀時間44分鐘，而原本的英文演講錄影長達70分鐘。如果你有70分鐘的話，去看影片還是非常值得的喔！
好，讓我們開始吧。
1/ 前言
PRODUCT IS HARD — An Open Discussion on Product Management
(影片秒數: 6:29 )
如果你已經做產品一段時間，就會遇到很多困難與挑戰；如果沒遇到什麼困難，那表示你還做得不夠久。所以說，做產品遇到困難是很正常的事情，這也讓我想跟大家談談這些困難。這些跟我一直以來的寫作內容有關，跟我每一個合作的團隊也都有關，都是很真實很生動的主題，也令我發現「把這些問題攤開來」大家一起聊，會很有幫助。但我也要說，如果你是做產品的新手，這個分享會聽起來很有難度，因為我們會談論比較深的主題。我反而擔心你聽完以後，你可能會被嚇跑而不想做產品了！
About Marty Cagan
(影片秒數: 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 天，後面會說明更多。
Conventional Lean and Agile
(影片秒數: 22:20 )
為何「敏捷」還不足夠？
可能很多人看過這張圖，來自一個很有名的敏捷教練Henrik Kniberg，他長時間在Spotify 擔任教練。不過上次我跟他吃晚餐的時候，他說現在到Minecraft 當工程師了，因為太想念當工程師的感覺了！
他想傳達的是「瀑布式」和「敏捷」的差異，以做一臺車子來比喻。瀑布式流程會花好幾個月來確認每一個汽車零件，但敏捷會先做一個「可被測試」的東西。如果這個東西不管用，那就再做一個，看看我們做出來的東西是不是越來越靠近一臺真正的車子。
但如果你是一個產品公司，這其實是一個真的很慢也很浪費的過程。
Problem of Conventional Lean and Agile
(影片秒數: 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 個月重構，令團隊無法繼續迅速發佈。
Discovery and Delivery
(影片秒數: 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)。
Prototypes in Discovery, Products in Delivery
(影片秒數: 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的混淆問題，並解說使用產品原型的重要性。
請記得，在探索階段打造prototypes，在交付階段打造products
3/ 你想要真正的Product Team？
當我認識一個產品團隊的時候，我會觀察3件事，來判斷他們做產品的能力怎麼樣。
第一件事，就是他們是否在進入交付階段前，就著手避免讓產品失敗的4 大風險，這時候通常不需要寫任何一行程式碼。
第二件事，就是他們實際上用什麼方式解決問題。我期待他們結合了產品經理、設計師、工程師，讓彼此交互切磋，然後產生一個最好的方法。他們是用共同協作的模式來解決問題，還是用依序接力的方式來解決問題？在過去瀑布式(Waterfall) 的模式下，產品經理會定義產品需求規格，然後丟給設計師來負責把畫面弄好看，然後再把一整包爛攤子丟給工程師。若是在衝刺規劃會議(Sprint Planning) 上才第一次跟大家說「開始打造這一切」，雖然有Scrum 裡面的衝刺規劃會議，且這些人說他們很敏捷(agile)，但這根本不是敏捷，這只是瀑布式，因為人們就是在彼此接手各種工作而已。
第三件事，就是他們被賦予的目標。如果他們被賦予的是發佈功能，那只是個「產出」 (output)。如果他們被賦予的是解決問題，那就是個「成果」 (outcome)。我期待看到的是專注在成果(outcome)，並以成果來衡量自己的團隊。如果有發生這三件事，其他的議題也就不太重要，為此我就能判斷這是一個良好的團隊。
Feature Teams vs. Product Teams
(影片秒數: 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% 的公司有真正的產品團隊，剩下的都是功能團隊，這真的是全世界都很常見的問題。很多人常常以為這些卓越的產品團隊都在舊金山，到了南韓或新加坡就很難看到這種團隊，事實上不是這樣。首先，在舊金山，也有很多糟糕的團隊，我看過很多。這對我來說當然很驚訝，因為過個馬路就有另一個卓越的團隊、來自卓越的公司。其次，在全世界各個角落都有卓越的產品團隊，我遇過的一些頂尖團隊其實在北京、班加洛、斯德哥爾摩、柏林，到處都有。
4/ 怎樣讓老闆們信任Product Team？
Validating Ideas vs. Discovery Solutions
(影片秒數: 40:15 )
好，來談下一個問題。雖然這些問題沒有按照順序，但如同我說的，這些是一旦你開始做產品，就開始體會的問題。
現在，其實很容易讓產品團隊學到各種探索的技巧，快速測試的方法，然後判斷一個產品概念是否可行。今天如果一個高管說「我們需要串接PayPal 這個支付方法」，如果你學會了現代產品方法的探索技巧，只要幾天的時間，你就可以搞清楚它能否帶來效果，而且是在動工以前就搞清楚。
很多團隊擅長這些探索與測試的技巧，但仍然發生很不幸的情況。當高管或利益相關人說「我們需要做這個、做那個」，而產品團隊幾天後回頭說「我們不打算做這些，因為測試後發現這些構想不可行，原因如下…」。問題是，經過幾次這樣的情況，高管們開始覺得很挫敗，因為他們只聽到「這些不可行」，他們肯定會納悶「那你們到底要做什麼？」
我試著跟產品團隊說，你們的工作不只是告訴大家「為何這些不可行」，你們的工作還必須告訴大家「這些構想更能解決問題、更有機會成功」。如果今天的課題是「國際交易支付量過低」，產品團隊除了告訴大家「串接PayPal 不是個好方法」，還必須告訴大家「PayPal 以外還有哪些方法」可以解決問題，這才是優良產品團隊和新手產品團隊的差別。優良的產品團隊知道，自己還必須提出可行的方案，而且這些方案要更有機會成功。
我們可以在很多公司，見證這種做法的影響力。因為，只要產品團隊開始展現這些能力，高管們開始認定這些團隊是「問題排除者」 (Problem Solver)，而不是「阻礙者」 (Blocker)。只會驗證點子(validating ideas) 的團隊是阻礙者，你可以在很多公司看到這樣的症狀。
5/ 要花多少時間在Prototyping？
Planning vs. 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)。別誤會我，這是個不錯的技巧，但我很少推薦它，因為做完全套流程實在太花時間。如果你真的走完全部流程，你幾乎沒剩多少時間來提出可行的方案，時間成本昂貴到你無法負擔。如果你是三星要推出新手機，如果這是個長期的計劃，你可以負擔這樣昂貴的成本，也許合理。但對在座的所有人，這不合理，因為我們有更輕量、更快、更低成本的規劃技巧，只花幾個小時，然後立刻開始做探索等實際的工作。
我想更清楚的指出，如果你是產品經理或產品設計師，你大部分的工作時間都應該花在製作原型(prototyping)。當然，是由產品設計師製作這些原型，然後由產品經理來親自試用、測試、從中學習，但你們也是一起透過製作原型(prototyping) 來迭代(iterate)。產品經理與設計師運用原型，工程師運用程序代碼，這就是我說的如何一起工作。基本上這就是你大部分的工作，你將展示原型給不同類型的用戶、顧客、利益關係人，你將會在團隊中測試它們，這才是產品經理與設計師的真正工作。這也是為什麼我們需要真正的「產品設計師」(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) 也可在這篇文章，找到簡短介紹。
6/ 滿腦子只有單一方案？
Not Considering Alternative Solutions or Approaches
(影片秒數: 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 小時在手機上，這是件好事嗎？如果這是個教育類的科技產品，可能是件好事，但如果這是個遊戲，也許不是件好事。這是我們要留意的事情，而且不只是對用戶，也要想這對社會是好的嗎？對我們事業是好的嗎？這合法嗎？有些公司正在嘗試的事情，可能在法律的邊緣上，這顯然不是件好事。
同時，你也要了解，公司在大多數時候都不刻意造成問題，大部分都是無意的。但我想強調的是，產品經理通常是第一群看到潛在問題的人，因為他們就在第一線，觀察對顧客與用戶的影響。所以，如果你看到打造中的產品有什麼問題，你真的會提出這個議題，向你的主管提出討論，甚至向你的CEO提出。當然，這是個很敏感的問題，你需要委婉一些的提出，你要確保自己做足功課，真正瞭解事業如何運作。總之，很顯然，我們這個產業，應該在這方面做得更多。
8/ 只有無盡的產品優化？
Confusing Optimization with Discovery
(影片秒數: 55:09 )
這也是個完全不相關的問題，但也真的很常見。
今日，有非常多做產品優化上很棒的工具，例如Optimizely、Google Optimize。說清楚一點，這裡講的「產品優化」 (optimization)，指的是低風險、線上流量、即時資料的AB Testing。我們基本上是微調各模塊，看哪一個成效更好，最常見的就是做在轉換漏斗(funnel) 上。我強烈建議每個團隊，只要你有正在線上的產品，你獲得了真實的流量，你就應該執行這些測試，沒有任何不這麼做的理由。
但問題是，我看到很多公司，他們只在做這件事情。我可以告訴你，如果這是你唯一做的事情，你正在一個緩慢死亡的道路上，因為這只是「捕捉價值」 (value capture) 的行為，就像提高價格一樣。這是件好事，沒什麼不對，但如果你只做這件事，你只是逐漸消耗價值而已。我們身為產品人的工作，是要創造更多價值，大餘我們捕捉到的價值。產品探索(Product Discovery) 就為了「創造價值」 (value creation)，產品優化(Product Optimization) 只為了放大價值。
所以，不要只做產品優化，要確保你創造更多價值。
9/ 勢不兩立的量化與質化？
Qualitative vs. Quantitative Learning
(影片秒數: 56:47 )
再來一個問題，這個問題某種程度上碰觸到了公司文化。當你剛認識一間公司，很快的你可以稍微看出他們的文化。有些是極度偏重量化驅動的文化，他們的CEO非常相信量化驅動的決策，又有另一些公司的CEO極度相信她或他的直覺，這則是非常質化導向的文化，這些都是很有公司文化的表現。
我總會試著跟兩類型的老闆們解釋，每一個優秀的產品公司，沒有例外，都必須擅長兩種方法，因為它們回答很不一樣的問題。
量化測試告訴我們「實際上發生哪些現象」，但它的限制和主要的問題，就是無法告訴我們為什麼。量化分析能告訴我們「App 中3% 的用戶使用此功能」，但它沒辦法告訴我們「為何另外97% 的用戶不使用」，質化測試就在此時派上用場。所以，好的公司都必須擅長兩種技巧。
就以Google 來說，這家以數據為典範的公司，擁有如此巨大流量的公司，其實長期以來都在做質化測試。又以Apple 來說，這家以質化洞見為典範的公司，他們的量化分析也做得一樣好。我會這麼說：在Google 的標準測試要基於量化方法，但當他們要獲得解釋時，就會運用質化方法；在Apple 每天都做質化的測試，但當他們要獲得數據時，就會運用量化方法。他們兩種都用，因為只有單一一種都會造成偏差，很不一樣但都有用。
10/ 產品管理的核心能力？
Product Management Competence
(影片秒數: 59:22 )
基本上，幾乎所有之前提到的議題，都有賴於具備核心能力的產品經理。在今天的開頭，我提到我們產業的一個大問題，就是大部分的產品人— 不管職稱是產品負責人(Product Owner) 還是產品經理(Product Manager) — 都欠缺足夠的訓練，他們還沒真正學會如何做好自己的工作。也就是說，他們還不具備足夠的核心能力。
這裡要清楚解釋一下，產品經理(Product Manager) 是工作上的職稱，而產品負責人(Product Owner) 是這些人在敏捷團隊中扮演的角色。正如同交付經理(Deliver Manager) 是工作上的職稱，而敏捷專家(Scrum Master) 是這些人在敏捷團隊中扮演的角色。如果你有一個產品負責人，其本身的工作職稱不是產品經理，那是另一個問題，通常你要確保產品經理就是產品負責人。
回到產品經理的核心能力，到底是什麼呢？
產品經理的4 大核心能力
Product Manager Competence
(影片秒數: 60:30 )
我認為有4 個核心能力：
對用戶和顧客的深入研究
對用戶操作的深入研究
對行業的深入研究
對產業的深入研究
作為一個產品經理，你的產品團隊有賴你提供以上知識。不過我也要說，如果你是功能團隊(Feature Team) 的產品經理，那麼你並不需要這些，你最需要的是足夠的項目管理能力。如果希望在被授權的產品團隊擔任產品經理，那這些也就是你給自己的約定。和你一起工作的設計師和工程師也都希望你為團隊提供這些知識，因為要是你沒有，那每一個決策都要提報給CEO或某個高管(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 )
我可以跟你保證，如果產品經理的主管們真的落實這件事，今天將是很不一樣的世界。很可惜的是他們沒有做到，因為他們多數人也不知道這是怎麼一回事、他們自己從沒做過、他們從沒看其他人做好過、或他們從沒待過這樣運作的公司，所以對他們來說這也很困難。但總之，就我的底線來說，每當我遇到不夠格的產品經理，通常都是他們沒被好好的訓練、沒被好好的輔導，所以我的挫折感不是針對這位產品經理，是針對他們的主管，因為我們要對主管問責，確保他們帶好產品經理。
我時常跟主管們說，你頂多就和你最弱的那個產品經理一樣強，所以你真的要好好花時間輔導和提升產品經理們，這是產品領導者最重要的職責，這真的要說的很清楚。當然，還有其他很重要的職責，例如產品策略、願景、目標，但所有事情都有賴於具備夠強的產品經理。產品團隊也就只能跟他們的產品經理一樣強，如果產品經理不夠格，那麼你就是浪費優秀的工程師、設計師，而這些人都需要公司負擔很大筆的支出。
(影片秒數: 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 種不同的功能或重新改版，或任何該做的事情。
總之，這就是我們尋找的三件事。如果你的團隊有這三件事，我們認為這就是你們想要的境界，所有我認識的世上最好的團隊，都很真實的落實這三件事。你會發現，這裡面沒什麼神奇的魔法，你沒有什麼做不到這三件事的理由。你沒有這麼做的主要理由通常主要原因是CEO 還不信任這個產品團隊。現在，為了獲得這樣的信任，我們要回到有能力展現核心能力的產品經理身上，就是先前我談的那些能力，就是這些讓我們贏得執行長CEO的信任。
END
內容回顧
1/前言（10%）
2/突破敏捷的挫敗感？（20%）
3/你想要真正的Product Team？（45%）
4/怎樣讓老闆們信任Product Team？（55%）
5/要花多少時間在Prototyping？（60%）
6/滿腦子只有單一方案？（65%）
7/道德上該推出產品嗎？（68%）
8/只有無盡的產品優化？（70%）
9/勢不兩立的量化與質化？（72%）
10/產品管理的核心能力？（75%）
11/輔導產品經理（85%）
12/贏得信任的被授權團隊88（88%）
如果你已經看到了這裡，那我真的很佩服你，想必你也一定有了一些收穫，消耗一下變成自己的思考，然後一起討論下吧？
視頻來源：Youtube https://www.youtube.com/watch?v=99go9sKp70I&feature=youtu.be&t=389
本文由作者@Adam旺仔 在PMCAFF社區發佈，轉載請註明作者及出處。
閱讀更多 PMCAFF產品經理社區 的文章
