www.pmcaff.com

本文為PMCAFF作者?Adam旺仔?于社區(qū)發(fā)布

本文來自Marty Cagan去年11月在臺灣的演講視頻，視頻來源Youtube視頻，已被逐字翻譯成了繁體。但仍存在差別，針對一些難以理解的語句，我再次進(jìn)行了翻譯，原文由3PM LAB出品。

因為演講內(nèi)容與我產(chǎn)品的引路人對做產(chǎn)品的理念也十分相似，非常推崇，所以細(xì)心整理分享，希望對大家也有幫助，開始吧！

全文共19500字，閱讀時間50分鐘

建議先收藏

Marty Cagan是享譽(yù)全球的產(chǎn)品大師，【INSPIRED:產(chǎn)品項目管理全書】的作者，擔(dān)任許多知名公司的產(chǎn)品教練與顧問，也是全球的產(chǎn)品社群中的思想領(lǐng)先者。曾和許多資深的產(chǎn)品經(jīng)理一起工作(或有私交) ，包含任職于Netflix、Google、Apple、Adobe、BBC的產(chǎn)品經(jīng)理。他參與了第一家網(wǎng)路產(chǎn)品公司Netscape的創(chuàng)業(yè)歷程，然后再到eBay擔(dān)任產(chǎn)品與設(shè)計副總(VP of Product and Design) ，之后創(chuàng)辦了Silicon Valley Product Group，網(wǎng)羅眾多資深產(chǎn)品人，專門為科技公司做產(chǎn)品顧問。

Marty Cagan 在臺北演講

透過ProductTank Taipei社群的籌備，Marty Cagan去年11月難得第一次來臺灣演講。為了向更多朋友分享Marty Cagan的產(chǎn)品心得，社群伙伴們張羅了當(dāng)天錄影錄音的支援設(shè)備，并釋出影片。為了加速內(nèi)容的傳播與擴(kuò)散，我重看了錄影，將演講內(nèi)容翻譯成中文，并自行編修為每一段加上標(biāo)題、刪除了部分的聊天內(nèi)容、加上段落補(bǔ)充說明，希望能幫助大家吸收演講內(nèi)容。

Marty Cagan 在臺北演講，現(xiàn)場坐滿200 位觀眾

Marty Cagan 長達(dá)70 分鐘的演講，有以下內(nèi)容：

（百分比為大概位置便于直接查看）

• 1/前言（10%）

• 2/突破敏捷的挫敗感？（20%）

• 3/你想要真正的Product Team？（45%）

• 4/怎樣讓老板們信任Product Team？（55%）

• 5/要花多少時間在Prototyping？（60%）

• 6/滿腦子只有單一方案？（65%）

• 7/道德上該推出產(chǎn)品嗎？（68%）

• 8/只有無盡的產(chǎn)品優(yōu)化？（70%）

• 9/勢不兩立的量化與質(zhì)化？（72%）

• 10/產(chǎn)品管理的核心能力？（75%）

• 11/輔導(dǎo)產(chǎn)品經(jīng)理（85%）

• 12/贏得信任的被授權(quán)團(tuán)隊（88%）

此外，還有另外一小時的Q&A 問答互動時間，但礙于本文篇幅已經(jīng)太長，希望下次再寫成另一篇文章。如果你也想看Q&A，別忘了拍手鼓勵喔！

估計本文閱讀時間44分鐘，而原本的英文演講錄影長達(dá)70分鐘。如果你有70分鐘的話，去看影片還是非常值得的喔！????

好，讓我們開始吧。

1/ 前言

PRODUCT IS HARD — An Open Discussion on Product Management

(影片秒數(shù):?6:29?)

如果你已經(jīng)做產(chǎn)品一段時間，就會遇到很多困難與挑戰(zhàn)；如果沒遇到什么困難，那表示你還做得不夠久。所以說，做產(chǎn)品遇到困難是很正常的事情，這也讓我想跟大家談?wù)勥@些困難。這些跟我一直以來的寫作內(nèi)容有關(guān)，跟我每一個合作的團(tuán)隊也都有關(guān)，都是很真實很生動的主題，也令我發(fā)現(xiàn)「把這些問題攤開來」大家一起聊，會很有幫助。但我也要說，如果你是做產(chǎn)品的新手，這個分享會聽起來很有難度，因為我們會談?wù)摫容^深的主題。我反而擔(dān)心你聽完以后，你可能會被嚇跑而不想做產(chǎn)品了！

About Marty Cagan

(影片秒數(shù):?8:56?)

我對「產(chǎn)品團(tuán)隊」(Product Team) 總是非常感興趣，因為每一個偉大的產(chǎn)品總有一個偉大的團(tuán)隊，沒有厲害的各種角色組合在一起，就沒有偉大的產(chǎn)品。但我花特別多時間跟大家談?wù)劗a(chǎn)品管理、產(chǎn)品經(jīng)理，因為已經(jīng)有很多人在談?wù)撛O(shè)計、技術(shù)，但幾乎沒什么人談產(chǎn)品，我覺得這是一個很大的空缺。

我也不諱言地說，我們產(chǎn)業(yè)最大的問題就是「有足夠的設(shè)計和工程，但常常沒有足夠的產(chǎn)品經(jīng)理」。也不是說誰比較聰明，就是沒有人好好地訓(xùn)練這些人，沒人教他們?nèi)绾巫霎a(chǎn)品。我非常幸運(yùn)，可從很多厲害的人身上學(xué)習(xí)產(chǎn)品，這些人知道怎么學(xué)習(xí)做產(chǎn)品。這些主管們真的知道自己在談?wù)撌裁?#xff0c;也會花心思引導(dǎo)你。我生涯的第一個10 年在HP 擔(dān)任工程師，在這10 年的職涯中，至少都有一個人明確告訴我如何做得更好，讓我以為大家都這么幸運(yùn)。但真實世界并不是這樣，特別對產(chǎn)品經(jīng)理來說，沒什么人告訴他們?nèi)绾巫龅酶谩?/p>

這對「敏捷開發(fā)」 (Agile Movement) 來說也是很不幸的事情，特別在我們的同行中，當(dāng)幾乎每個人都在呼吁要變得更敏捷的時候。有些人參加完Certified Scrum Product Owner (CSPO) 訓(xùn)練課程，就覺得自己是產(chǎn)品經(jīng)理了，但其實這課程并不能教你如何當(dāng)好產(chǎn)品經(jīng)理，所以上完課的人還不足以勝任。「產(chǎn)品負(fù)責(zé)人」 (Product Owner) 的職責(zé)只占了「產(chǎn)品經(jīng)理」 (Product Manager) 約5% 的工作內(nèi)容。所以說，雖然CSPO 是重要的訓(xùn)練，但這不會教你如何當(dāng)好PM，這是整個產(chǎn)業(yè)的重要問題。

要學(xué)好做產(chǎn)品，目前多數(shù)人都仰賴一個「會做好產(chǎn)品的人」，跟他一起工作，且這人會花心力引導(dǎo)、訓(xùn)練新人。理論上，只要能跟到這樣的人，任何背景的人都可以做好產(chǎn)品經(jīng)理，不管你是技術(shù)、營銷、業(yè)務(wù)、客服。

稍微介紹我自己，我在HP 從做工程師開始，然后加入了Netscape。Netscape 是第一家互聯(lián)網(wǎng)的公司，也是現(xiàn)在Mozilla 的原生地，有很多厲害的人，也是現(xiàn)代產(chǎn)品經(jīng)理的原生地。在Netscape 之前，在互聯(lián)網(wǎng)時代之前，做產(chǎn)品的方式被稱為Microsoft Style，當(dāng)然Microsoft 現(xiàn)在追上網(wǎng)絡(luò)時代了。Netscape 是第一個要考慮網(wǎng)絡(luò)使用環(huán)境來做產(chǎn)品的公司，所以Microsoft Style 做產(chǎn)品的方式對網(wǎng)絡(luò)公司并不管用。

所以Netscape是第一個遇到這些問題的公司，因此在Netscape的人開始尋找做現(xiàn)代網(wǎng)絡(luò)產(chǎn)品的方法，其中包含Ben Horowitz。他寫了一本書是【什么才是經(jīng)營最難的事？】 (The Hard Thing About Hard Things)，可說是一本為新創(chuàng)業(yè)公司創(chuàng)始人和產(chǎn)品經(jīng)理所寫的書。他最近寫了一本新書是What You Do Is Who You Are，其實也是一本關(guān)于Product Culture的書，建議大家閱讀。

Netscape 所找到的產(chǎn)品方法，很快地隨著Netscape 人才換工作的過程，而擴(kuò)散到其他公司，包含Google、Amazon、Facebook、LinkedIn、Twitter，等等等。

因為Netscape在瀏覽器的戰(zhàn)爭中輸給了Microsoft，所以很多人才離開并加入了其他公司，而我就加入了eBay擔(dān)任Head of Product and Design，這是一段很棒的經(jīng)歷。再后來我很希望多跟新創(chuàng)業(yè)公司一起工作，所以當(dāng)時就和5個人一起，針對創(chuàng)業(yè)階段和成長階段的公司，給予咨詢與投資。過程中我也寫了一本關(guān)于產(chǎn)品的書INSPIRED，去年出了第二版，被翻譯成數(shù)十種語言，這也是我今天在這里的原因，為了新書出版。

接下來要分享的議題，都是做產(chǎn)品的常見問題，但他們彼此之間沒有先后順序，不過我敢說這是全世界都常見的問題。

2/ 突破敏捷的挫敗感？

Frustration with Lean and Agile

(影片秒數(shù):?16:44?)

其中一個很常見的問題，是最近對于「精益」 (Lean) 和「敏捷」 (Agile) 方法的挫敗感。這和先前的炒作宣傳有關(guān)，讓很多人不了解精益和敏捷的核心原則。為了避免這個情況，我們先來回顧精益和敏捷的核心原則。

The Core Principles of Agile and Lean

(影片秒數(shù):?18:23?)

敏捷的核心原則

當(dāng)我們來看看敏捷和精益，其實就是幾個核心原則。

就敏捷來說，去除所有外圍的東西，只剩兩個核心原則：

第一是「要頻繁的發(fā)布」，頻繁的意思是「至少每兩周發(fā)布一次」。如果你每月或每季才發(fā)布一次，就算你自稱敏捷，你其實沒有獲得任何敏捷的好處。好的產(chǎn)品團(tuán)隊甚至每天發(fā)布好幾次，就是所謂的「持續(xù)交付」 (Continuous Delivery)。也不是說大家都要做持續(xù)交付，但若你不是每兩周發(fā)布一次，這會是很大的問題。

第二是「團(tuán)隊要被賦權(quán)且被問責(zé)」，被賦權(quán)的意思是「交由團(tuán)隊來找解決問題的最佳方法」。舉例來說，不是由管理層告知團(tuán)隊「請串接日本當(dāng)?shù)豅N 公司的行動支付」，而是告訴團(tuán)隊「我們眼前看到的問題，是太少日本當(dāng)?shù)厝速徺I我們的產(chǎn)品，海外轉(zhuǎn)換率實在太低了，請你們解決這個問題」。如果串接了日本當(dāng)?shù)豅N 公司的行動支付，沒有解決這個問題，團(tuán)隊就要繼續(xù)探索其他方案。

很多團(tuán)隊被告知要更加敏捷，但其實管理層一直給團(tuán)隊「待完成的功能清單」（傳統(tǒng)意義上的產(chǎn)品路線圖Product Roadmap），每月或每季都跟團(tuán)隊說「請做這些功能」，這在任何意義上來說都不是敏捷。

這是敏捷遇到的很大問題，很多團(tuán)隊沒被問責(zé)或沒被賦權(quán)。

就精益來說，背后也是只有兩個核心原則：

第一是「我們要快速學(xué)習(xí)才能創(chuàng)新」，創(chuàng)新源自于我們能夠嘗試多少點(diǎn)子，因為我們知道大部分的點(diǎn)子都行不通。

第二是「我們得要消除浪費(fèi)」，所謂的浪費(fèi)就是花了4 個月才發(fā)現(xiàn)「這不是解決問題的好方法」，這就是浪費(fèi)。在創(chuàng)業(yè)階段我常看見的浪費(fèi)就是「我們正在做一個MVP 」(Minimum Viable Product 最小可行性產(chǎn)品)。然后我就會問「太好了，那可以讓我看看MVP 嗎？」結(jié)果他們就說「正在做了，還要4 個月」。坦白說，這根本不是MVP，只是個半成品、是不成熟的產(chǎn)品。真正的MVP 只需要4 小時或4 天，不是4 個月。

這些是精益和敏捷的核心原則，千萬不能放棄。那么，到底是什么原因，造成精益與敏捷的實施失敗呢？

補(bǔ)充：因為Marty Cagan 指的是原型(prototypes)，他認(rèn)為所有的MVP 都應(yīng)該改成prototypes，如此就只需要4 小時或4 天，后面會說明更多。

Conventional Lean and Agile

(影片秒數(shù):?22:20?)

為何「敏捷」還不足夠？

可能很多人看過這張圖，來自一個很有名的敏捷教練Henrik Kniberg，他長時間在Spotify 擔(dān)任教練。不過上次我跟他吃晚餐的時候，他說現(xiàn)在到Minecraft 當(dāng)工程師了，因為太想念當(dāng)工程師的感覺了！

他想傳達(dá)的是「瀑布式」和「敏捷」的差異，以做一臺車子來比喻。瀑布式流程會花好幾個月來確認(rèn)每一個汽車零件，但敏捷會先做一個「可被測試」的東西。如果這個東西不管用，那就再做一個，看看我們做出來的東西是不是越來越靠近一臺真正的車子。

但如果你是一個產(chǎn)品公司，這其實是一個真的很慢也很浪費(fèi)的過程。

Problem of Conventional Lean and Agile

(影片秒數(shù):?23:43?)

在一個產(chǎn)品公司里面，我們發(fā)現(xiàn)做產(chǎn)品有兩個非常不一樣的目標(biāo)與階段。任何一個科技產(chǎn)品公司，都會遇到這兩種挑戰(zhàn)。

第一，我們要搞清楚「探索該打造的產(chǎn)品」，我稱之為「產(chǎn)品探索」(Product Discovery)。這個意思是要找到一個產(chǎn)品方案，符合以下四個條件：

• 對用戶有價值(valuable)：就是顧客會買單

• 易于使用(usable)：意思就是顧客能自己搞懂如何使用

• 可被打造(feasible)：是我們知道如何打造

• 商業(yè)上可行(viable)：有市場可行性，包括這個產(chǎn)品，包含宣傳、銷售、客服，也有收益

第二，我們要「交付完整的產(chǎn)品」，也就是「產(chǎn)品交付」(Product Delivery)，是交付工程師有自信的產(chǎn)品，讓我們可以真正開始運(yùn)營這個產(chǎn)品。這個最終產(chǎn)品要符合的條件是：

• 穩(wěn)定(reliable)

• 可擴(kuò)展(scalable)

• 高效能(performant)

• 可維護(hù)(maintainable)

• 支援多國語言且本地化(internationalized and localized)

這些都是完整產(chǎn)品應(yīng)具備的特性。有些人會說第一個是“build the right product”，第二個是“build the product right”。

「探索」和「交付」是非常不一樣的目標(biāo)與挑戰(zhàn)，而令很多團(tuán)隊遇到問題的情況，就是公司「要同一群人，在同一時間，處理這兩個挑戰(zhàn)」。例如，有些公司會叫團(tuán)隊「交付產(chǎn)品時，也要確保這是正確的產(chǎn)品」，但這并不合理，會造成很多浪費(fèi)。

補(bǔ)充：就我的親身經(jīng)驗來說，叫團(tuán)隊「交付產(chǎn)品時，也要確保這是正確的產(chǎn)品」，可能造成兩種浪費(fèi)。第一種是團(tuán)隊小心謹(jǐn)慎的閉門工作了4 個月，發(fā)布產(chǎn)品后發(fā)現(xiàn)這是錯誤的產(chǎn)品。第二種是團(tuán)隊超級迅速的發(fā)布了好幾次產(chǎn)品，其中有些成功了，但也創(chuàng)造了極大的技術(shù)成本，打造了難以維護(hù)、難以擴(kuò)張、很低效能的產(chǎn)品，得再花4 個月重構(gòu)，令團(tuán)隊無法繼續(xù)迅速發(fā)布。

Discovery and Delivery

(影片秒數(shù):?25:50?)

「探索與交付」的循環(huán)迭代

所以，在產(chǎn)品開發(fā)團(tuán)隊中，我們會分離這兩種行為、這兩種風(fēng)險。

第一種，在探索階段，我們嘗試想出一個valuable, usable, feasible, viable 的產(chǎn)品。

第二種，在交付階段，我們現(xiàn)在知道要打造什么產(chǎn)品，我們有合理的信心去賣出這個產(chǎn)品、支持我們的市場行為，所以現(xiàn)在可以請工程團(tuán)隊用可靠的方式打造這個產(chǎn)品。

我想要特別說明，這只是一個簡單的描述，不是完整的流程。舉例來說，現(xiàn)在已有很多交付階段的工作流程，其中2個最有名的流程是Scrum 和Kanban，除了這2個最受歡迎，還有很多其他的交付流程。同樣的，現(xiàn)在也有很多探索階段的工作流程，例如有多達(dá)50 種探索階段的工作流程。

所以說，這只是個概念上的工作模式，想跟大家傳達(dá)的是：我們要去解決問題，而不只是打造路線圖上的功能，我們被賦予的是解決問題的目標(biāo)（而不是打造功能的目標(biāo)）。

你可能聽過OKR?(Objective and Key Results 目標(biāo)和關(guān)鍵成果) 的管理方法，這個管理方法正是發(fā)明于采用這種工作模式的公司，因為這種方法才能建立被授權(quán)的工作團(tuán)隊，被賦予達(dá)成目標(biāo)而不是打造功能。當(dāng)團(tuán)隊被賦予解決問題的目標(biāo)，團(tuán)隊才能找到解決問題的最佳路徑，然后再交付可靠的產(chǎn)品。而產(chǎn)品待辦事項清單(Product Backlog)，就是探索階段中產(chǎn)出的有信心的待辦事項，等待在交付階段中被實現(xiàn)。

正如先前描述這個工作模式的一些方法，有人說探索階段就是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。

這就是大體上的工作模式，不管他們怎么描述、不管有沒有精確的文字，我遇到的優(yōu)良團(tuán)隊都是這么做產(chǎn)品。他們確保在最開始就面對產(chǎn)品失敗的4 大風(fēng)險，在探索階段知道應(yīng)該打造什么產(chǎn)品，然后才去交付產(chǎn)品。

補(bǔ)充：Marty Cagan在INSPIRED書中，介紹了產(chǎn)品失敗的4大風(fēng)險，分別是

• 1/實行性風(fēng)險(Feasibility Risk)：團(tuán)隊明確需求，但手邊并沒有解決問題的技術(shù)，或技術(shù)尚未成熟，就是「我們知道要做什么產(chǎn)品，但是做不出來」的狀況

• 2/易用性風(fēng)險(Usability Risk)：顧客想用這個產(chǎn)品，但不知如何使用，或太少人克服使用門檻，就是「產(chǎn)品做出來了，但是好多顧客看不懂、不會用」的狀況

• 3/價值風(fēng)險(Value Risk)：這個產(chǎn)品并沒有解決顧客需求，為顧客帶來價值，就是「產(chǎn)品做出來了，某些顧客也會用了，但后來都不繼續(xù)用，因為沒有滿足需求」的狀況

• 4/商業(yè)可行性風(fēng)險(Business Viability Risk)：這個產(chǎn)品對公司沒有商業(yè)價值，或無法在市場競爭中存活，就是「產(chǎn)品做出來了，顧客也愛用，但是無法賺錢，或拿不到更多預(yù)算與資金，或無法贏過競爭者」的狀況。

在探索中用Prototypes，不是MVP！

在交付階段，工程師最重要的工作就是寫程序、打造真正的產(chǎn)品。在探索階段，我們只需要「原型」 (prototypes)，而不是「產(chǎn)品」 (products)。

Prototypes in Discovery, Products in Delivery

(影片秒數(shù):?29:23?)

在探索階段只需要原型(prototypes)，MVP 其實應(yīng)該要是原型才對。MVP 這個名稱造成很多誤會，因為MVP (Minimum Viable Product) 中的P，把應(yīng)該要是prototypes 的東西誤稱為products。所以，我總是在探索階段運(yùn)用prototypes，以免他人誤會。

(除了名稱上的誤會，) 如果你花4 個月打造一個MVP，這會是一個很大的問題。花4 個月才打造一個MVP，在探索階段來說實在是超級慢，但在交付階段可能又太快速了，所以沒有人會對此滿意。請記得，在探索階段打造prototypes，在交付階段打造products。

補(bǔ)充：關(guān)于Marty Cagan提到的產(chǎn)品探索技巧，可以參考INSPIRED的第4篇，第33到56章，里面介紹了產(chǎn)品探索的原則、產(chǎn)品探索的技術(shù)概觀、用于探索階段的4大類產(chǎn)品原型、以及測試4大風(fēng)險的主要技術(shù)。在本次演講的其他段落，將會多次提到產(chǎn)品原型(Prototypes)和MVP的混淆問題，并解說使用產(chǎn)品原型的重要性。

請記得，在探索階段打造prototypes，在交付階段打造products

3/ 你想要真正的Product Team？

當(dāng)我認(rèn)識一個產(chǎn)品團(tuán)隊的時候，我會觀察3件事，來判斷他們做產(chǎn)品的能力怎么樣。

第一件事，就是他們是否在進(jìn)入交付階段前，就著手避免讓產(chǎn)品失敗的4 大風(fēng)險，這時候通常不需要寫任何一行程式碼。

第二件事，就是他們實際上用什么方式解決問題。我期待他們結(jié)合了產(chǎn)品經(jīng)理、設(shè)計師、工程師，讓彼此交互切磋，然后產(chǎn)生一個最好的方法。他們是用共同協(xié)作的模式來解決問題，還是用依序接力的方式來解決問題？在過去瀑布式(Waterfall) 的模式下，產(chǎn)品經(jīng)理會定義產(chǎn)品需求規(guī)格，然后丟給設(shè)計師來負(fù)責(zé)把畫面弄好看，然后再把一整包爛攤子丟給工程師。若是在沖刺規(guī)劃會議(Sprint Planning) 上才第一次跟大家說「開始打造這一切」，雖然有Scrum 里面的沖刺規(guī)劃會議，且這些人說他們很敏捷(agile)，但這根本不是敏捷，這只是瀑布式，因為人們就是在彼此接手各種工作而已。

第三件事，就是他們被賦予的目標(biāo)。如果他們被賦予的是發(fā)布功能，那只是個「產(chǎn)出」 (output)。如果他們被賦予的是解決問題，那就是個「成果」 (outcome)。我期待看到的是專注在成果(outcome)，并以成果來衡量自己的團(tuán)隊。

如果有發(fā)生這三件事，其他的議題也就不太重要，為此我就能判斷這是一個良好的團(tuán)隊。

Feature Teams vs. Product Teams

(影片秒數(shù):?32:20?)

很多公司，也可以說是大多數(shù)我在世界各地遇到的公司，大體上都知道做產(chǎn)品的基本知識。他們知道不只需要工程師，還需要產(chǎn)品經(jīng)理、設(shè)計師，大多數(shù)都建立了跨專業(yè)跨領(lǐng)域的團(tuán)隊。有些公司稱這樣的編制為「產(chǎn)品團(tuán)隊」，這也是我常用的稱呼，而有些則喜歡用Spotify 的方式稱呼為Squad。這些都很好，但問題是要建立這樣的團(tuán)隊編制并不難，困難的是要能在前面那3 件事上面，落實的夠徹底、夠深遠(yuǎn)。很多公司仍然只是制定產(chǎn)品路線圖，賦予給團(tuán)隊的任務(wù)不是探索與交付，只是設(shè)計與開發(fā)。

有些公司甚至還聲稱有「探索階段」，但實質(zhì)上我知道他們并沒有這么做，因為我會用這個問題來探測：「你們在探索階段會測試多少原型？你們在交付階段又會打造多少？」如果他們說：「喔，上個月我們在探索階段測試了10 個項目，然后這個月我們打造了10 個項目。」這樣我就知道這不是探索，這只是設(shè)計，也許附帶一點(diǎn)點(diǎn)易用性測試，并不是真的在測試點(diǎn)子。如果他們很認(rèn)真實施探索階段，很認(rèn)真的測試4 大風(fēng)險，他們必然要拋棄非常多當(dāng)初的點(diǎn)子，至少要拋棄一半。附帶一提，真正優(yōu)良的產(chǎn)品公司甚至?xí)仐?0% 到90% 的原始點(diǎn)子。微軟最近在哈佛商業(yè)評論(Harvard Business Review) 上公開地說，他們大概只有10% 的點(diǎn)子真的可行。

如果他們沒有真正落實探索階段，盡管這些公司團(tuán)隊稱之為「產(chǎn)品團(tuán)隊」 (Product Team) 或Squad，他們實際上仍然只是個「功能團(tuán)隊」 (Feature Team)，而且世界上大多數(shù)的公司都是這個樣子。他們有產(chǎn)品經(jīng)理(Product Manager)、有設(shè)計師和工程師，但他們的產(chǎn)品經(jīng)理實際上只是個項目經(jīng)理(Project Manager)，這真的很常見。

我們回顧一下打造產(chǎn)品的4 大風(fēng)險：價值(Value)、易用性(Usability) 、實行性(Feasibility)、商業(yè)可行性(Viability)。你可能知道設(shè)計師要負(fù)責(zé)易用性，當(dāng)然他們大可以貢獻(xiàn)更多。你也知道工程師要負(fù)責(zé)開發(fā)，當(dāng)然他們也是大可以貢獻(xiàn)更多。

如果你只是一個被交付「路線圖」 (Roadmap) 的功能團(tuán)隊(Feature Team)，實際上有一個不那么明顯的狀況正在發(fā)生：若某個公司內(nèi)的高管(executives) 或利益相關(guān)人(stakeholders )，只要他們要求把某個項目加到產(chǎn)品路線圖中，這個人其實就負(fù)責(zé)了該項目的價值風(fēng)險(value risk)。舉例來說，如果某個人說「我們必須加上PayPal 這個支付方式」，不管是誰說的，這個人肯定是相信這件事有價值，他才這么說，否則他就不會這樣說。同時間，這人其實也負(fù)責(zé)了這個項目的「商業(yè)可行性」 (business viability)。這時候，產(chǎn)品經(jīng)理實際上要負(fù)責(zé)的只是項目管理。

如果這是一個被授權(quán)的產(chǎn)品團(tuán)隊(Empowered Product Team)，他們被交付的是問題與目標(biāo)，而不是產(chǎn)品路線圖。在真正的產(chǎn)品團(tuán)隊中，產(chǎn)品經(jīng)理則要負(fù)責(zé)的是這個解法能夠(為用戶) 帶來價值，在商業(yè)上也可行。所以說，當(dāng)我們要談?wù)摤F(xiàn)代的產(chǎn)品經(jīng)理，我們要在真正的產(chǎn)品團(tuán)隊中談?wù)?#xff0c;而不是在功能團(tuán)隊中談?wù)?#xff0c;這才是我們應(yīng)該談?wù)摰氖虑椤?/p>

我也必須要誠實的說，功能團(tuán)隊中產(chǎn)品經(jīng)理的工作，遠(yuǎn)遠(yuǎn)比產(chǎn)品團(tuán)隊中產(chǎn)品經(jīng)理的工作簡單許多。在產(chǎn)品團(tuán)隊中工作的產(chǎn)品經(jīng)理，要承受更大的壓力、需要具備更多的技能、每天可能要睡得更少。這不是說項目管理不重要，這很重要，但這不是產(chǎn)品經(jīng)理工作中的核心。

我也想跟你說，這個問題在很多地方都有出現(xiàn)。譬如說，有很多網(wǎng)絡(luò)時代前就存在的公司，他們常常說自己需要做互聯(lián)網(wǎng)轉(zhuǎn)型(Digital Transformation)，但他們就只是設(shè)置了一個功能團(tuán)隊，然后他們還沒搞清楚，為什么這沒有帶來什么改變。互聯(lián)網(wǎng)轉(zhuǎn)型需要的是產(chǎn)品團(tuán)隊，但他們還沒搞懂。為什么這么說呢？因為這些要做轉(zhuǎn)型的公司，其實就是想和Amazon 這種公司競爭，但產(chǎn)品團(tuán)隊正是Amazon 和Google 采用的模式。很不幸的是，就算功能團(tuán)隊看起來和產(chǎn)品團(tuán)隊很像，他們終究不是(因為沒有實質(zhì)內(nèi)涵)。

坦白說我不知道在臺灣的情況，就算是在舊金山、紐約、西雅圖，也只有10% 到20% 的公司有真正的產(chǎn)品團(tuán)隊，剩下的都是功能團(tuán)隊，這真的是全世界都很常見的問題。很多人常常以為這些卓越的產(chǎn)品團(tuán)隊都在舊金山，到了南韓或新加坡就很難看到這種團(tuán)隊，事實上不是這樣。首先，在舊金山，也有很多糟糕的團(tuán)隊，我看過很多。這對我來說當(dāng)然很驚訝，因為過個馬路就有另一個卓越的團(tuán)隊、來自卓越的公司。其次，在全世界各個角落都有卓越的產(chǎn)品團(tuán)隊，我遇過的一些頂尖團(tuán)隊其實在北京、班加洛、斯德哥爾摩、柏林，到處都有。

4/ 怎樣讓老板們信任Product Team？

Validating Ideas vs. Discovery Solutions

(影片秒數(shù):?40:15?)

好，來談下一個問題。雖然這些問題沒有按照順序，但如同我說的，這些是一旦你開始做產(chǎn)品，就開始體會的問題。

現(xiàn)在，其實很容易讓產(chǎn)品團(tuán)隊學(xué)到各種探索的技巧，快速測試的方法，然后判斷一個產(chǎn)品概念是否可行。今天如果一個高管說「我們需要串接PayPal 這個支付方法」，如果你學(xué)會了現(xiàn)代產(chǎn)品方法的探索技巧，只要幾天的時間，你就可以搞清楚它能否帶來效果，而且是在動工以前就搞清楚。

很多團(tuán)隊擅長這些探索與測試的技巧，但仍然發(fā)生很不幸的情況。當(dāng)高管或利益相關(guān)人說「我們需要做這個、做那個」，而產(chǎn)品團(tuán)隊幾天后回頭說「我們不打算做這些，因為測試后發(fā)現(xiàn)這些構(gòu)想不可行，原因如下…」。問題是，經(jīng)過幾次這樣的情況，高管們開始覺得很挫敗，因為他們只聽到「這些不可行」，他們肯定會納悶「那你們到底要做什么？」

我試著跟產(chǎn)品團(tuán)隊說，你們的工作不只是告訴大家「為何這些不可行」，你們的工作還必須告訴大家「這些構(gòu)想更能解決問題、更有機(jī)會成功」。如果今天的課題是「國際交易支付量過低」，產(chǎn)品團(tuán)隊除了告訴大家「串接PayPal 不是個好方法」，還必須告訴大家「PayPal 以外還有哪些方法」可以解決問題，這才是優(yōu)良產(chǎn)品團(tuán)隊和新手產(chǎn)品團(tuán)隊的差別。優(yōu)良的產(chǎn)品團(tuán)隊知道，自己還必須提出可行的方案，而且這些方案要更有機(jī)會成功。

我們可以在很多公司，見證這種做法的影響力。因為，只要產(chǎn)品團(tuán)隊開始展現(xiàn)這些能力，高管們開始認(rèn)定這些團(tuán)隊是「問題排除者」 (Problem Solver)，而不是「阻礙者」 (Blocker)。只會驗證點(diǎn)子(validating ideas) 的團(tuán)隊是阻礙者，你可以在很多公司看到這樣的癥狀。

5/ 要花多少時間在Prototyping？

Planning vs. Prototyping

(影片秒數(shù):?42:40?)

這是一個棘手的問題，讓我來告訴你為什么。

大家都知道，在開工前，花點(diǎn)時間想一想手上的問題，是個不錯的做事方法。但問題是這樣的，的確我們有很多思考問題、架構(gòu)問題、規(guī)劃工作的技巧，但你必須非常注意時間，因為從你接下問題的那一刻，有個碼表就被啟動了，公司的執(zhí)行長和高管們心里就開始算時間，他們心里會算「好，又過了一天…又過了一個月…」，就是這個碼表在計時。如果你花了大部分的時間做規(guī)劃，你就沒剩多少時間去提出一個可能成功的方案。然后，很快地你的老板們就失去耐性。

因此，我時常試著告訴團(tuán)隊，你必須控制你的步調(diào)，不能做一大堆分析而已。做產(chǎn)品最困難的部分不是規(guī)劃，最困難的是「提出可能成功的方案」。當(dāng)我說「可能成功的方案」，意思要能「促使顧客轉(zhuǎn)換」到你的產(chǎn)品，不管先前他們用誰的產(chǎn)品。這聽起來簡單，做起來非常難。

很多新手產(chǎn)品人會用「借鑒功能」 (Feature Parity) 的策略，以為只要具備「頭號競爭對手提供的所有功能或服務(wù)」，就可以擁有很多客戶，但經(jīng)驗上這幾乎不可能成功。事實上，前面提到的Ben Horowitz 曾這樣跟產(chǎn)品團(tuán)隊說：「借鑒功能」不會成功，因為要讓顧客愿意轉(zhuǎn)換到我們的新產(chǎn)品，顧客得相信新產(chǎn)品能提供比過去好上10 倍的成果，顧客才會愿意忍受所有轉(zhuǎn)換過程的痛苦與風(fēng)險。要量化「好上10 倍」，其實也很困難。好奇問一下，現(xiàn)場有多少人用Slack？噢！真驚人，幾乎是所有人。你的公司可能從HipChat 轉(zhuǎn)換到Slack，這個過程并不簡單。你們愿意轉(zhuǎn)換，因為你們團(tuán)隊認(rèn)為Slack 是企業(yè)通訊軟體最好的選項。

這就是為什么做產(chǎn)品很困難，你的產(chǎn)品必須被認(rèn)為「有非常明顯的優(yōu)勢」，而這不會從「產(chǎn)品規(guī)劃」 (Product Planning) 中達(dá)成。你可以做一堆規(guī)劃但產(chǎn)品也不怎么樣，因為這要從「制作原型」 (prototyping) 來達(dá)成。這就是產(chǎn)品探索(Product Discovery)，嘗試各種點(diǎn)子、驗證哪些概念可行，持續(xù)在探索中迭代，直到找到有可能成功的方案。

所以我想強(qiáng)調(diào)的是，如果你要解決一個困難的問題，你的確需要花一點(diǎn)時間做規(guī)劃、做分析，我們有很棒的方法，只要花你幾個小時，但你應(yīng)該要花大部分的時間來做探索(Discovery)、提出一個有可能成功的方案。如果你不這么做，你不會有更多時間。

有點(diǎn)抱歉的是，我接下來舉的例子會用到刻板印象。有很多產(chǎn)品經(jīng)理來自管理學(xué)院、MBAs，有很多因素讓MBA 畢業(yè)生們喜愛做規(guī)劃，他們很愛手上的各種表，他們就從中獲得很多樂趣。遇到這樣的人，恩，我會說「ok 很好，但這不是你的工作！」這也只是簡單的部分，困難的部分是當(dāng)你把手弄臟的時候，你必須坐下來、找設(shè)計師和工程師，一起提出可行的方案，任何世界上的規(guī)劃技巧都不會帶你找到可行的方案。

當(dāng)然我說的并不完全正確，開個玩笑，我認(rèn)識很多卓越的產(chǎn)品經(jīng)理來自MBAs。但因為MBAs 有這樣的思維習(xí)慣，每當(dāng)我雇用MBA 背景的產(chǎn)品經(jīng)理，我必須打破這樣的習(xí)慣。舉例來說，MBA 有些受歡迎的產(chǎn)品技巧，像是用途理論(Jobs To-Be-Done)。別誤會我，這是個不錯的技巧，但我很少推薦它，因為做完全套流程實在太花時間。如果你真的走完全部流程，你幾乎沒剩多少時間來提出可行的方案，時間成本昂貴到你無法負(fù)擔(dān)。如果你是三星要推出新手機(jī)，如果這是個長期的計劃，你可以負(fù)擔(dān)這樣昂貴的成本，也許合理。但對在座的所有人，這不合理，因為我們有更輕量、更快、更低成本的規(guī)劃技巧，只花幾個小時，然后立刻開始做探索等實際的工作。

我想更清楚的指出，如果你是產(chǎn)品經(jīng)理或產(chǎn)品設(shè)計師，你大部分的工作時間都應(yīng)該花在制作原型(prototyping)。當(dāng)然，是由產(chǎn)品設(shè)計師制作這些原型，然后由產(chǎn)品經(jīng)理來親自試用、測試、從中學(xué)習(xí)，但你們也是一起透過制作原型(prototyping) 來迭代(iterate)。產(chǎn)品經(jīng)理與設(shè)計師運(yùn)用原型，工程師運(yùn)用程序代碼，這就是我說的如何一起工作。基本上這就是你大部分的工作，你將展示原型給不同類型的用戶、顧客、利益關(guān)系人，你將會在團(tuán)隊中測試它們，這才是產(chǎn)品經(jīng)理與設(shè)計師的真正工作。這也是為什么我們需要真正的「產(chǎn)品設(shè)計師」(Product Designer)，今日設(shè)計師受訓(xùn)練的方式也正是透過制作原型(prototyping)，這對我們很關(guān)鍵。

再強(qiáng)調(diào)一次，所有的prototypes 都是MVP，但我更喜歡用prototypes 來稱呼，因為我想強(qiáng)調(diào)這不是真正的、完整的產(chǎn)品。除此之外，有4 種不同類型的prototypes，所有優(yōu)良的產(chǎn)品團(tuán)隊都要善用4 種prototypes，我們實際上也需要4 種prototypes 來面對不同的工作、處理不同的風(fēng)險。有些專門用來量化測試，有些則用來質(zhì)化測試，所以優(yōu)良團(tuán)隊都需要做這些。

以上，就是為什么我們要平衡planning 與prototyping。

補(bǔ)充：關(guān)于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

(影片秒數(shù):?50:40?)

這個問題，和前一個很相關(guān)，也是人類的天性，很常見。當(dāng)我們被賦予一個問題，例如要改善國際的購買比例，或要降低流失率，或要增加營收，或要找到新市場的第一個參考客戶，不管是什么目標(biāo)、要解決什么問題，我們很自然的會立刻獲得一些點(diǎn)子，不管是自己想的或他人提供的。然后，我們就決定嘗試這個點(diǎn)子，立刻開始制作原型。這很好，但問題是，如果這是我們唯一認(rèn)真考慮的點(diǎn)子，而且這個原型其實最后不成功，那然后呢？該怎么辦？

很多團(tuán)隊接著采取的行動，就是繼續(xù)制作原型(prototyping)、繼續(xù)20、30、50 次迭代，直到他們用完所有的時間，或直到放棄。其實，你真正想要理解的是「總是有很多種解決問題的方法」，所以當(dāng)你在做少量規(guī)劃的時候，你要確保自己記得「這里有5 種解決問題的方法」，至少要把這件事記在心上。我們認(rèn)為其中一個方法最好，所以從這里開始，但如果我們沒獲得成果，我們就要嘗試下一個。

舉例來說，有個Teresa Torres和我都呼吁的方法，叫做「機(jī)會與方案樹狀圖」 (Opportunity Solution Tree)。如果你沒聽過Teresa，她是個很棒的產(chǎn)品探索教練，是她讓這個方法流行起來。這是個快速、輕量的規(guī)劃技巧，讓我們架構(gòu)自己的工作。

7/ 道德上應(yīng)該推出產(chǎn)品嗎？

Not Thinking Enough About Ethical Risks

(影片秒數(shù):?52:57?)

這是一個完全不同的主題，但這在我們產(chǎn)業(yè)中也不是個秘密，就是說我們不夠用心思考道德上的風(fēng)險。

前面我提到產(chǎn)品失敗的4 大風(fēng)險：價值(Value)、易用性(Usability) 、實行性(Feasibility)、商業(yè)可行性(Viability)。除此之外，我常鼓勵團(tuán)隊多考慮第5 個風(fēng)險，也就是道德風(fēng)險(Ethical Risk)，就是問自己：我們應(yīng)該打造這個產(chǎn)品嗎？

換句話說，就算用戶喜歡我們的產(chǎn)品，這對用戶來說真的是件好事嗎？舉例來說，用戶是個14 歲的青少年，你成功的讓他一天花4 小時在手機(jī)上，這是件好事嗎？如果這是個教育類的科技產(chǎn)品，可能是件好事，但如果這是個游戲，也許不是件好事。這是我們要留意的事情，而且不只是對用戶，也要想這對社會是好的嗎？對我們事業(yè)是好的嗎？這合法嗎？有些公司正在嘗試的事情，可能在法律的邊緣上，這顯然不是件好事。

同時，你也要了解，公司在大多數(shù)時候都不刻意造成問題，大部分都是無意的。但我想強(qiáng)調(diào)的是，產(chǎn)品經(jīng)理通常是第一群看到潛在問題的人，因為他們就在第一線，觀察對顧客與用戶的影響。所以，如果你看到打造中的產(chǎn)品有什么問題，你真的會提出這個議題，向你的主管提出討論，甚至向你的CEO提出。當(dāng)然，這是個很敏感的問題，你需要委婉一些的提出，你要確保自己做足功課，真正了解事業(yè)如何運(yùn)作。總之，很顯然，我們這個產(chǎn)業(yè)，應(yīng)該在這方面做得更多。

8/ 只有無盡的產(chǎn)品優(yōu)化？

Confusing Optimization with Discovery

(影片秒數(shù):?55:09?)

這也是個完全不相關(guān)的問題，但也真的很常見。

今日，有非常多做產(chǎn)品優(yōu)化上很棒的工具，例如Optimizely、Google Optimize。說清楚一點(diǎn)，這里講的「產(chǎn)品優(yōu)化」 (optimization)，指的是低風(fēng)險、線上流量、即時資料的AB Testing。我們基本上是微調(diào)各模塊，看哪一個成效更好，最常見的就是做在轉(zhuǎn)換漏斗(funnel) 上。我強(qiáng)烈建議每個團(tuán)隊，只要你有正在線上的產(chǎn)品，你獲得了真實的流量，你就應(yīng)該執(zhí)行這些測試，沒有任何不這么做的理由。

但問題是，我看到很多公司，他們只在做這件事情。我可以告訴你，如果這是你唯一做的事情，你正在一個緩慢死亡的道路上，因為這只是「捕捉價值」 (value capture) 的行為，就像提高價格一樣。這是件好事，沒什么不對，但如果你只做這件事，你只是逐漸消耗價值而已。我們身為產(chǎn)品人的工作，是要創(chuàng)造更多價值，大余我們捕捉到的價值。產(chǎn)品探索(Product Discovery) 就為了「創(chuàng)造價值」 (value creation)，產(chǎn)品優(yōu)化(Product Optimization) 只為了放大價值。

所以，不要只做產(chǎn)品優(yōu)化，要確保你創(chuàng)造更多價值。

9/ 勢不兩立的量化與質(zhì)化？

Qualitative vs. Quantitative Learning

(影片秒數(shù):?56:47?)

再來一個問題，這個問題某種程度上碰觸到了公司文化。當(dāng)你剛認(rèn)識一間公司，很快的你可以稍微看出他們的文化。有些是極度偏重量化驅(qū)動的文化，他們的CEO非常相信量化驅(qū)動的決策，又有另一些公司的CEO極度相信她或他的直覺，這則是非常質(zhì)化導(dǎo)向的文化，這些都是很有公司文化的表現(xiàn)。

我總會試著跟兩類型的老板們解釋，每一個優(yōu)秀的產(chǎn)品公司，沒有例外，都必須擅長兩種方法，因為它們回答很不一樣的問題。

量化測試告訴我們「實際上發(fā)生哪些現(xiàn)象」，但它的限制和主要的問題，就是無法告訴我們?yōu)槭裁础Ａ炕治瞿芨嬖V我們「App 中3% 的用戶使用此功能」，但它沒辦法告訴我們「為何另外97% 的用戶不使用」，質(zhì)化測試就在此時派上用場。所以，好的公司都必須擅長兩種技巧。

就以Google 來說，這家以數(shù)據(jù)為典范的公司，擁有如此巨大流量的公司，其實長期以來都在做質(zhì)化測試。又以Apple 來說，這家以質(zhì)化洞見為典范的公司，他們的量化分析也做得一樣好。我會這么說：在Google 的標(biāo)準(zhǔn)測試要基于量化方法，但當(dāng)他們要獲得解釋時，就會運(yùn)用質(zhì)化方法；在Apple 每天都做質(zhì)化的測試，但當(dāng)他們要獲得數(shù)據(jù)時，就會運(yùn)用量化方法。他們兩種都用，因為只有單一一種都會造成偏差，很不一樣但都有用。

10/ 產(chǎn)品管理的核心能力？

Product Management Competence

(影片秒數(shù):?59:22?)

基本上，幾乎所有之前提到的議題，都有賴于具備核心能力的產(chǎn)品經(jīng)理。在今天的開頭，我提到我們產(chǎn)業(yè)的一個大問題，就是大部分的產(chǎn)品人— 不管職稱是產(chǎn)品負(fù)責(zé)人(Product Owner) 還是產(chǎn)品經(jīng)理(Product Manager) — 都欠缺足夠的訓(xùn)練，他們還沒真正學(xué)會如何做好自己的工作。也就是說，他們還不具備足夠的核心能力。

這里要清楚解釋一下，產(chǎn)品經(jīng)理(Product Manager) 是工作上的職稱，而產(chǎn)品負(fù)責(zé)人(Product Owner) 是這些人在敏捷團(tuán)隊中扮演的角色。正如同交付經(jīng)理(Deliver Manager) 是工作上的職稱，而敏捷專家(Scrum Master) 是這些人在敏捷團(tuán)隊中扮演的角色。如果你有一個產(chǎn)品負(fù)責(zé)人，其本身的工作職稱不是產(chǎn)品經(jīng)理，那是另一個問題，通常你要確保產(chǎn)品經(jīng)理就是產(chǎn)品負(fù)責(zé)人。

回到產(chǎn)品經(jīng)理的核心能力，到底是什么呢？

產(chǎn)品經(jīng)理的4 大核心能力

Product Manager Competence

(影片秒數(shù):?60:30?)

我認(rèn)為有4 個核心能力：

• 對用戶和顧客的深入研究

• 對用戶操作的深入研究

• 對商業(yè)的深入研究

• 對產(chǎn)業(yè)的深入研究

作為一個產(chǎn)品經(jīng)理，你的產(chǎn)品團(tuán)隊有賴你提供以上知識。不過我也要說，如果你是功能團(tuán)隊(Feature Team) 的產(chǎn)品經(jīng)理，那么你并不需要這些，你最需要的是足夠的項目管理能力。如果希望在被授權(quán)的產(chǎn)品團(tuán)隊擔(dān)任產(chǎn)品經(jīng)理，那這些也就是你給自己的約定。和你一起工作的設(shè)計師和工程師也都希望你為團(tuán)隊提供這些知識，因為要是你沒有，那每一個決策都要提報給CEO或某個高管(executive)，或者你要召集很多利益相關(guān)人會議(stakeholder meeting)時，在會議中要大家對每一個決定投票，這些就會是惡夢。

(1) 對用戶和顧客的深入研究

第一個，對用戶和顧客的深入研究，這通常要產(chǎn)品經(jīng)理花上3 到4 個月來養(yǎng)成。我時常收到產(chǎn)品經(jīng)理的抱怨，多到我無法告訴你有多頻繁，這些人會抱怨CEO 持續(xù)地推翻自己的決定。遇到這種狀況，我會問這些產(chǎn)品經(jīng)理：「好，那請告訴我，上次你遇到客戶是什么時候？」通常答案是上個月或上一季，然后我接著問：「好，那上次你的CEO遇到客戶是什么時候？」通常答案是「幾乎每一天」，因為CEO會頻繁地拜訪客戶、或客戶會自己找上門。如果是這樣，那我就會說：「聽著，如果我是你的CEO ，我也不會信任你的決定。為何世上會有CEO，讓不了解客戶的產(chǎn)品經(jīng)理(Product Manager) 做決定呢？」期待發(fā)生這種事，并不實際。

產(chǎn)品經(jīng)理最基本的知識，就是要真的非常了解用戶或客戶。我到現(xiàn)在都還記得，第一個輔導(dǎo)我擔(dān)任產(chǎn)品經(jīng)理的人告訴我的事情，那是我剛從工程師轉(zhuǎn)任產(chǎn)品經(jīng)理的時候。這里補(bǔ)充一下，在我當(dāng)產(chǎn)品經(jīng)理的生涯中，除了在eBay，我都負(fù)責(zé)為工程師制作產(chǎn)品，我很愛打造開發(fā)者工具與產(chǎn)品，這很好玩。我自己當(dāng)過工程師，要為工程師打造產(chǎn)品，我心想「我沒問題的，我很了解顧客，他們就和我一樣！」那個輔導(dǎo)我的人，他的名字是Mike Bako，他知道我其實根本不了解我們的客戶。他跟我說：「聽者，在你被允許做任何決定以前，你必須先去拜訪30 個客戶。」這里指的是HP 的客戶，所以他給銷售團(tuán)隊打了幾通電話，然后跟我說：「你要開始一個3 周的出差，然后拜訪15 個美國公司，以及15 個歐洲公司，等你拜訪完我們再來聊。」

這在HP 是很常見很正常的出差，但在這3 周的旅行之后，我成為了一個完全不同的人。首先，我發(fā)現(xiàn)有上百種「顧客跟我們不一樣」的方式，特別是很多HP 客戶公司內(nèi)的工程師，跟我們非常不一樣。這些客戶可能是銀行、保險公司，他們的工程師所受的訓(xùn)練和我們很不一樣，有些人甚至不把自己稱作工程師，可能只叫自己是分析師或程序員。

當(dāng)然，Mike 早就知道我和顧客不一樣，所以我必須去見見這些人。對我來說，這3周好比上了個了解顧客的速成班，讓我真正理解顧客需要什么、遇到什么困難，我們當(dāng)然有很多產(chǎn)品可以滿足他們，但這些需求就是跟我們內(nèi)部的需求很不一樣。除此之外，我也和很多顧客建立的關(guān)系，直到今天我們會在LinkedIn 上聯(lián)系，甚至我到法國時也會碰面。同時，我也和銷售團(tuán)隊建立了關(guān)系，所以我有了一整個網(wǎng)絡(luò)，幫助我了解顧客、了解我們銷售和行銷產(chǎn)品的過程，這里有太多我不知道的事情。

這就是產(chǎn)品經(jīng)理要具備的第一個能力，你必須被認(rèn)為是最了解用戶或顧客的一位專家。對大部分2C產(chǎn)品來說這可能不會太難，但對企業(yè)2B軟體來說這需要很多工作，因為B2B產(chǎn)品可以很復(fù)雜，要各種不同的用戶，包含負(fù)責(zé)評估采購、負(fù)責(zé)批審預(yù)算的人，產(chǎn)品經(jīng)理要了解這里面的動態(tài)關(guān)系。

(2) 對用戶操作的深入研究

第二個，要對顧客使用產(chǎn)品所產(chǎn)生的實際操作，有深入的研究。這是今天對比我當(dāng)年初次做產(chǎn)品時的最大差異，那時候是互聯(lián)網(wǎng)之前的時代，我們不像今天有這么多的數(shù)據(jù)。今天的產(chǎn)品經(jīng)理，每天早上剛開始時，應(yīng)該要花1 到1.5 小時在數(shù)據(jù)工具上。至少有3 種看數(shù)據(jù)的角度與工具，第一種是看用戶如何在各種設(shè)備上使用產(chǎn)品，第二種是看長期的數(shù)據(jù)變化，第三種是看銷售數(shù)據(jù)和銷售營銷活動的表現(xiàn)。

團(tuán)隊有賴產(chǎn)品經(jīng)理具備這些知識，所以當(dāng)我們每周做即時數(shù)據(jù)測試的時候，團(tuán)隊希望知道我們的產(chǎn)品表現(xiàn)如何。這是另一種了解用戶的方式，產(chǎn)品經(jīng)理必須帶給團(tuán)隊。

(3) 對商業(yè)的深入研究

第三個，必須非常了解你所在的商業(yè)。我必須誠實的說，很多產(chǎn)品經(jīng)理最不喜歡的工作就是第三個，但這也是4 個核心能力中第二重要的部分，最重要的是了解用戶。如果你聽過這句話「在被授權(quán)的產(chǎn)品團(tuán)隊，一位厲害的產(chǎn)品經(jīng)理就如同這個產(chǎn)品的CEO 」，這就是在講第三個核心能力，因為另一個必須如此了解商業(yè)的工作，就是擔(dān)任CEO 。

所謂的了解商業(yè)，就是說你要很了解「哪些營收支付了這個產(chǎn)品的開發(fā)與營運(yùn)？經(jīng)費(fèi)從哪來？成本結(jié)構(gòu)是如何？」你還必須了解產(chǎn)品如何被營銷、如何被銷售、如何進(jìn)入市場、如何到達(dá)顧客面前，你還必須了解過程中的各種限制，例如政府法規(guī)、隱私、商業(yè)合約等所有的限制，甚至還有我們?nèi)绾巫鍪酆蠓?wù)、如何跨商業(yè)合作。你必須了解這個商業(yè)的各種情況，因為你必須確保團(tuán)隊打造的產(chǎn)品能夠成功達(dá)到顧客面前、為公司創(chuàng)造營收、支付相關(guān)的成本，這就是第三個核心能力。

(4) 對大環(huán)境的深入研究

第四個，對大環(huán)境很深的認(rèn)識，譬如說，目前的競爭格局、重大趨勢。機(jī)器學(xué)習(xí)對我們的產(chǎn)品重要嗎？你必須有個看法。做產(chǎn)品很大的挑戰(zhàn)是要一直往未來思考，冰上曲棍球的俚語說「注意冰球即將前往的地方，而不是它走過的地方」，意思就是要看向未來的趨勢，而不是今天的情況。

所以，這些就是產(chǎn)品經(jīng)理被期待的標(biāo)準(zhǔn)，這就是合格的產(chǎn)品經(jīng)理的標(biāo)準(zhǔn)。如果你是產(chǎn)品經(jīng)理，你主管的職責(zé)就是確保達(dá)到標(biāo)準(zhǔn)，否則你不能為團(tuán)隊做任何決定。

11/ 輔導(dǎo)產(chǎn)品經(jīng)理

Coaching Product Managers

(影片秒數(shù):?70:16?)

我可以跟你保證，如果產(chǎn)品經(jīng)理的主管們真的落實這件事，今天將是很不一樣的世界。很可惜的是他們沒有做到，因為他們多數(shù)人也不知道這是怎么一回事、他們自己從沒做過、他們從沒看其他人做好過、或他們從沒待過這樣運(yùn)作的公司，所以對他們來說這也很困難。但總之，就我的底線來說，每當(dāng)我遇到不夠格的產(chǎn)品經(jīng)理，通常都是他們沒被好好的訓(xùn)練、沒被好好的輔導(dǎo)，所以我的挫折感不是針對這位產(chǎn)品經(jīng)理，是針對他們的主管，因為我們要對主管問責(zé)，確保他們帶好產(chǎn)品經(jīng)理。

我時常跟主管們說，你頂多就和你最弱的那個產(chǎn)品經(jīng)理一樣強(qiáng)，所以你真的要好好花時間輔導(dǎo)和提升產(chǎn)品經(jīng)理們，這是產(chǎn)品領(lǐng)導(dǎo)者最重要的職責(zé)，這真的要說的很清楚。當(dāng)然，還有其他很重要的職責(zé)，例如產(chǎn)品策略、愿景、目標(biāo)，但所有事情都有賴于具備夠強(qiáng)的產(chǎn)品經(jīng)理。產(chǎn)品團(tuán)隊也就只能跟他們的產(chǎn)品經(jīng)理一樣強(qiáng)，如果產(chǎn)品經(jīng)理不夠格，那么你就是浪費(fèi)優(yōu)秀的工程師、設(shè)計師，而這些人都需要公司負(fù)擔(dān)很大筆的支出。

12/ 贏得信任的被授權(quán)團(tuán)隊

Empowered Product Teams

(影片秒數(shù):?71:58?)

最后一個問題，講完這個就可以進(jìn)Q&A 時間。關(guān)于「被授權(quán)的產(chǎn)品團(tuán)隊」 (Empowered Product Team)，如果你不確定自己的團(tuán)隊是「被授權(quán)的產(chǎn)品團(tuán)隊」或「功能團(tuán)隊」 (Feature Team) ？首先呢，如果你有這個困惑，你們很可能就是個功能團(tuán)隊，但我當(dāng)然很希望你能對此感到肯定。

其實有一組簡單的3 個測驗，通過了表示這是一家有「被授權(quán)的產(chǎn)品團(tuán)隊」的良好公司。

第一個，你們有真正的跨專業(yè)跨領(lǐng)域團(tuán)隊嗎？這個意思是說，對你們的產(chǎn)品來說，要做好這個產(chǎn)品，需要哪些專業(yè)技能？通常來說，是需要產(chǎn)品經(jīng)理和產(chǎn)品設(shè)計師。當(dāng)我說產(chǎn)品設(shè)計師，我指的是一位精通服務(wù)設(shè)計(Service Design)、交互設(shè)計(Interaction Design)、視覺設(shè)計(Visual Design)、甚至通常是受過用戶研究(User Research) 訓(xùn)練的人，這是一個典型的「產(chǎn)品與用戶體驗設(shè)計師」 (Product / UX Designer) 的技能組合。更直白的說，我們真正仰賴的技能是交互設(shè)計(Interaction Design)，這比視覺設(shè)計(Visual Design) 的要求還更多，當(dāng)然視覺設(shè)計很重要，特別對消費(fèi)性產(chǎn)品來說，只不過這是很普遍的技能。

第二個，真的被授權(quán)嗎？具體來說，他們有被賦予要解決的問題嗎，而不是被賦予要交付的功能？要被解決的問題，可能是商業(yè)的問題、用戶的問題，總之就是一個待解決的問題，而不是要交付的功能，或要完成的項目。而且，團(tuán)隊被允許使用最佳的方式來解決問題嗎？這些是備授權(quán)的團(tuán)隊的主要概念。

第三個，他們被問責(zé)和被衡量的方式，是基于解決問題的嗎？換句話說，是衡量他們的成果(outcome)，而不是他們的產(chǎn)出(output)？

事實上，大部分的產(chǎn)品團(tuán)隊和產(chǎn)品公司，并不常討論「上市時間」 (Time to Market)。但請不要誤會我，期限在產(chǎn)品公司是很重要，但問題是要滿足期限其實并不困難。如果你已經(jīng)持續(xù)做科技產(chǎn)品一段時間了，你總會找到方法滿足任何被要求的期限。我總會砍功能、降低品質(zhì)，直到我們找到方法在期限前完成，但這就變成一個空洞的勝利。

對產(chǎn)品公司來說，真正重要的不是「上市時間」 (Time to Market)，而是「變現(xiàn)時間」 (Time to Money)。我說變現(xiàn)時間并不每次都指金錢，變現(xiàn)時間的重點(diǎn)是「真正解決問題的時刻」 (time to actually solving the problem)。如果問題是流失率是毫無永續(xù)性的12%，我們知道我們的商業(yè)模式將會崩解，除非我們把流失率降低到6%，那我們就是要把問題搞定，再降到6% 之前都不能慶祝。這就是我們說的變現(xiàn)時間，就是那么降到6% 的時刻，這可能表示需要100 種不同的功能或重新改版，或任何該做的事情。

「團(tuán)隊要被賦權(quán)且被問責(zé)」，被賦權(quán)的意思是「交由團(tuán)隊來找解決問題的最佳方法」

總之，這就是我們尋找的三件事。如果你的團(tuán)隊有這三件事，我們認(rèn)為這就是你們想要的境界，所有我認(rèn)識的世上最好的團(tuán)隊，都很真實的落實這三件事。你會發(fā)現(xiàn)，這里面沒什么神奇的魔法，你沒有什么做不到這三件事的理由。你沒有這么做的主要理由通常主要原因是CEO 還不信任這個產(chǎn)品團(tuán)隊。現(xiàn)在，為了獲得這樣的信任，我們要回到有能力展現(xiàn)核心能力的產(chǎn)品經(jīng)理身上，就是先前我談的那些能力，就是這些讓我們贏得執(zhí)行長CEO的信任。

END

內(nèi)容回顧

• 1/前言（10%）

• 2/突破敏捷的挫敗感？（20%）

• 3/你想要真正的Product Team？（45%）

• 4/怎樣讓老板們信任Product Team？（55%）

• 5/要花多少時間在Prototyping？（60%）

• 6/滿腦子只有單一方案？（65%）

• 7/道德上該推出產(chǎn)品嗎？（68%）

• 8/只有無盡的產(chǎn)品優(yōu)化？（70%）

• 9/勢不兩立的量化與質(zhì)化？（72%）

• 10/產(chǎn)品管理的核心能力？（75%）

• 11/輔導(dǎo)產(chǎn)品經(jīng)理（85%）

• 12/贏得信任的被授權(quán)團(tuán)隊（88%）

如果你已經(jīng)看到了這里，那我真的很佩服你，想必你也一定有了一些收獲，消耗一下變成自己的思考，然后一起討論下吧？

內(nèi)容編輯/翻譯：Adam

視頻來源：Youtube ?

https://www.youtube.com/watch?v=99go9sKp70I&feature=youtu.be&t=389

內(nèi)容來源：3PM LAB

點(diǎn)個“在看”吧

總結(jié)

以上是生活随笔為你收集整理的超干货 | 硅谷产品大师 Marty Cagan 70 分钟演讲2万字中译的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。