中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

導語：本文來自 Marty Cagan 2019年11月在臺灣的演講視頻，視頻來源 Youtube 視頻，已被逐字翻譯成了繁體。但仍存在差別，針對一些難以理解的語句，本文作者再次進行了翻譯，原文由 3PM LAB 出品。因為演講內(nèi)容與本文作者產(chǎn)品的引路人對做產(chǎn)品的理念十分相似，所以細心整理分享給大家，希望對大家也有幫助！

Marty Cagan是享譽全球的產(chǎn)品大師，【INSPIRED:產(chǎ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擔任產(chǎn)品與設計副總(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)品心得，社群伙伴們張羅了當天錄影錄音的支援設備，并釋出影片。

為了加速內(nèi)容的傳播與擴散，我重看了錄影，將演講內(nèi)容翻譯成中文，并自行編修為每一段加上標題、刪除了部分的聊天內(nèi)容、加上段落補充說明，希望能幫助大家吸收演講內(nèi)容。

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

Marty Cagan 長達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. 輔導產(chǎn)品經(jīng)理（85%）
12. 贏得信任的被授權(quán)團隊88（88%）

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

估計本文閱讀時間44分鐘，而原本的英文演講錄影長達70分鐘。如果你有70分鐘的話，去看影片還是非常值得的喔！好，讓我們開始吧。

一、前言

PRODUCT IS HARD — An Open Discussion on Product Management

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

如果你已經(jīng)做產(chǎn)品一段時間，就會遇到很多困難與挑戰(zhàn)；如果沒遇到什么困難，那表示你還做得不夠久。所以說，做產(chǎn)品遇到困難是很正常的事情，這也讓我想跟大家談談這些困難。

這些跟我一直以來的寫作內(nèi)容有關(guān)，跟我每一個合作的團隊也都有關(guān)，都是很真實很生動的主題，也令我發(fā)現(xiàn)「把這些問題攤開來」大家一起聊，會很有幫助。

但我也要說，如果你是做產(chǎn)品的新手，這個分享會聽起來很有難度，因為我們會談論比較深的主題。我反而擔心你聽完以后，你可能會被嚇跑而不想做產(chǎn)品了！

About Marty Cagan

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

我對「產(chǎn)品團隊」(Product Team) 總是非常感興趣，因為每一個偉大的產(chǎn)品總有一個偉大的團隊，沒有厲害的各種角色組合在一起，就沒有偉大的產(chǎn)品。

但我花特別多時間跟大家談談產(chǎn)品管理、產(chǎn)品經(jīng)理，因為已經(jīng)有很多人在談論設計、技術(shù)，但幾乎沒什么人談產(chǎn)品，我覺得這是一個很大的空缺。

我也不諱言地說，我們產(chǎn)業(yè)最大的問題就是「有足夠的設計和工程，但常常沒有足夠的產(chǎn)品經(jīng)理」。也不是說誰比較聰明，就是沒有人好好地訓練這些人，沒人教他們?nèi)绾巫霎a(chǎn)品。

我非常幸運，可從很多厲害的人身上學習產(chǎn)品，這些人知道怎么學習做產(chǎn)品。這些主管們真的知道自己在談論什么，也會花心思引導你。

我生涯的第一個10 年在HP 擔任工程師，在這10 年的職涯中，至少都有一個人明確告訴我如何做得更好，讓我以為大家都這么幸運。但真實世界并不是這樣，特別對產(chǎn)品經(jīng)理來說，沒什么人告訴他們?nèi)绾巫龅酶谩?/p>

這對「敏捷開發(fā)」 (Agile Movement) 來說也是很不幸的事情，特別在我們的同行中，當幾乎每個人都在呼吁要變得更敏捷的時候。

有些人參加完Certified Scrum Product Owner (CSPO) 訓練課程，就覺得自己是產(chǎn)品經(jīng)理了，但其實這課程并不能教你如何當好產(chǎn)品經(jīng)理，所以上完課的人還不足以勝任。

「產(chǎn)品負責人」 (Product Owner) 的職責只占了「產(chǎn)品經(jīng)理」 (Product Manager) 約5% 的工作內(nèi)容。所以說，雖然CSPO 是重要的訓練，但這不會教你如何當好PM，這是整個產(chǎn)業(yè)的重要問題。

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

稍微介紹我自己，我在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，當然Microsoft 現(xiàn)在追上網(wǎng)絡時代了。

Netscape 是第一個要考慮網(wǎng)絡使用環(huán)境來做產(chǎn)品的公司，所以Microsoft Style 做產(chǎn)品的方式對網(wǎng)絡公司并不管用。

所以Netscape是第一個遇到這些問題的公司，因此在Netscape的人開始尋找做現(xiàn)代網(wǎng)絡產(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 人才換工作的過程，而擴散到其他公司，包含Google、Amazon、Facebook、LinkedIn、Twitter等等。

因為Netscape在瀏覽器的戰(zhàn)爭中輸給了Microsoft，所以很多人才離開并加入了其他公司，而我就加入了eBay擔任Head of Product and Design，這是一段很棒的經(jīng)歷。再后來我很希望多跟新創(chuàng)業(yè)公司一起工作，所以當時就和5個人一起，針對創(chuàng)業(yè)階段和成長階段的公司，給予咨詢與投資。

過程中我也寫了一本關(guān)于產(chǎn)品的書INSPIRED，去年出了第二版，被翻譯成數(shù)十種語言，這也是我今天在這里的原因，為了新書出版。接下來要分享的議題，都是做產(chǎn)品的常見問題，但他們彼此之間沒有先后順序，不過我敢說這是全世界都常見的問題。

二、突破敏捷的挫敗感？

Frustration with Lean and Agile

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

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

The Core Principles of Agile and Lean

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

1. 敏捷的核心原則

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

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

1）「要頻繁的發(fā)布」

頻繁的意思是「至少每兩周發(fā)布一次」。

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

2）「團隊要被賦權(quán)且被問責」

被賦權(quán)的意思是「交由團隊來找解決問題的最佳方法」。

舉例來說：不是由管理層告知團隊「請串接日本當?shù)豅N 公司的行動支付」，而是告訴團隊「我們眼前看到的問題，是太少日本當?shù)厝速徺I我們的產(chǎn)品，海外轉(zhuǎn)換率實在太低了，請你們解決這個問題」。如果串接了日本當?shù)豅N 公司的行動支付，沒有解決這個問題，團隊就要繼續(xù)探索其他方案。

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

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

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

1）「我們要快速學習才能創(chuàng)新」

創(chuàng)新源自于我們能夠嘗試多少點子，因為我們知道大部分的點子都行不通。

2）「我們得要消除浪費」

所謂的浪費就是花了4 個月才發(fā)現(xiàn)「這不是解決問題的好方法」，這就是浪費。在創(chuàng)業(yè)階段我常看見的浪費就是「我們正在做一個MVP 」(Minimum Viable Product 最小可行性產(chǎn)品)。

然后我就會問「太好了，那可以讓我看看MVP 嗎？」結(jié)果他們就說「正在做了，還要4 個月」。坦白說，這根本不是MVP，只是個半成品、是不成熟的產(chǎn)品。真正的MVP 只需要4 小時或4 天，不是4 個月。

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

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

Conventional Lean and Agile

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

2. 為何「敏捷」還不足夠？

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

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

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

Problem of Conventional Lean and Agile

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

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

1）我們要搞清楚「探索該打造的產(chǎn)品」，我稱之為「產(chǎn)品探索」(Product Discovery)

這個意思是要找到一個產(chǎn)品方案，符合以下四個條件：

1. 對用戶有價值(valuable)：就是顧客會買單；
2. 易于使用(usable)：意思就是顧客能自己搞懂如何使用；
3. 可被打造(feasible)：是我們知道如何打造；
4. 商業(yè)上可行(viable)：有市場可行性，包括這個產(chǎn)品，包含宣傳、銷售、客服，也有收益。

2）我們要「交付完整的產(chǎn)品」，也就是「產(chǎn)品交付」(Product Delivery)，是交付工程師有自信的產(chǎn)品，讓我們可以真正開始運營這個產(chǎn)品

這個最終產(chǎn)品要符合的條件是：

1. 穩(wěn)定(reliable)
2. 可擴展(scalable)
3. 高效能(performant)
4. 可維護(maintainable)
5. 支援多國語言且本地化(internationalized and localized)

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

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

補充：就我的親身經(jīng)驗來說，叫團隊「交付產(chǎn)品時，也要確保這是正確的產(chǎn)品」，可能造成兩種浪費。

第一種是團隊小心謹慎的閉門工作了4 個月，發(fā)布產(chǎn)品后發(fā)現(xiàn)這是錯誤的產(chǎn)品；第二種是團隊超級迅速的發(fā)布了好幾次產(chǎn)品，其中有些成功了，但也創(chuàng)造了極大的技術(shù)成本，打造了難以維護、難以擴張、很低效能的產(chǎn)品，得再花4 個月重構(gòu)，令團隊無法繼續(xù)迅速發(fā)布。

Discovery and Delivery

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

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

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

1. 第一種：在探索階段，我們嘗試想出一個valuable, usable, feasible, viable 的產(chǎn)品。
2. 第二種：在交付階段，我們現(xiàn)在知道要打造什么產(chǎn)品，我們有合理的信心去賣出這個產(chǎn)品、支持我們的市場行為，所以現(xiàn)在可以請工程團隊用可靠的方式打造這個產(chǎn)品。

我想要特別說明，這只是一個簡單的描述，不是完整的流程。

舉例來說：現(xiàn)在已有很多交付階段的工作流程，其中2個最有名的流程是Scrum 和Kanban，除了這2個最受歡迎，還有很多其他的交付流程。同樣的，現(xiàn)在也有很多探索階段的工作流程，例如有多達50 種探索階段的工作流程。

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

你可能聽過OKR (Objective and Key Results 目標和關(guān)鍵成果) 的管理方法，這個管理方法正是發(fā)明于采用這種工作模式的公司，因為這種方法才能建立被授權(quá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)良團隊都是這么做產(chǎn)品。他們確保在最開始就面對產(chǎn)品失敗的4 大風險，在探索階段知道應該打造什么產(chǎn)品，然后才去交付產(chǎn)品。

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

1. 實行性風險(Feasibility Risk)：團隊明確需求，但手邊并沒有解決問題的技術(shù)，或技術(shù)尚未成熟，就是「我們知道要做什么產(chǎn)品，但是做不出來」的狀況；
2. 易用性風險(Usability Risk)：顧客想用這個產(chǎn)品，但不知如何使用，或太少人克服使用門檻，就是「產(chǎn)品做出來了，但是好多顧客看不懂、不會用」的狀況；
3. 價值風險(Value Risk)：這個產(chǎn)品并沒有解決顧客需求，為顧客帶來價值，就是「產(chǎn)品做出來了，某些顧客也會用了，但后來都不繼續(xù)用，因為沒有滿足需求」的狀況；
4. 商業(yè)可行性風險(Business Viability Risk)：這個產(chǎn)品對公司沒有商業(yè)價值，或無法在市場競爭中存活，就是「產(chǎn)品做出來了，顧客也愛用，但是無法賺錢，或拿不到更多預算與資金，或無法贏過競爭者」的狀況。

4. 在探索中用Prototypes，不是MVP！

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

Prototypes in Discovery, Products in Delivery

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

在探索階段只需要原型(prototypes)，MVP 其實應該要是原型才對。

MVP 這個名稱造成很多誤會，因為MVP (Minimum Viable Product) 中的P，把應該要是prototypes 的東西誤稱為products。所以，我總是在探索階段運用prototypes，以免他人誤會。

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

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

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

三、你想要真正的Product Team？

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

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

第二件事，就是他們實際上用什么方式解決問題。我期待他們結(jié)合了產(chǎn)品經(jīng)理、設計師、工程師，讓彼此交互切磋，然后產(chǎn)生一個最好的方法。他們是用共同協(xié)作的模式來解決問題，還是用依序接力的方式來解決問題？

在過去瀑布式(Waterfall) 的模式下，產(chǎn)品經(jīng)理會定義產(chǎn)品需求規(guī)格，然后丟給設計師來負責把畫面弄好看，然后再把一整包爛攤子丟給工程師。

若是在沖刺規(guī)劃會議(Sprint Planning) 上才第一次跟大家說「開始打造這一切」，雖然有Scrum 里面的沖刺規(guī)劃會議，且這些人說他們很敏捷(agile)，但這根本不是敏捷，這只是瀑布式，因為人們就是在彼此接手各種工作而已。

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

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

Feature Teams vs. Product Teams

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

很多公司，也可以說是大多數(shù)我在世界各地遇到的公司，大體上都知道做產(chǎn)品的基本知識。

他們知道不只需要工程師，還需要產(chǎn)品經(jīng)理、設計師，大多數(shù)都建立了跨專業(yè)跨領(lǐng)域的團隊。有些公司稱這樣的編制為「產(chǎn)品團隊」，這也是我常用的稱呼，而有些則喜歡用Spotify 的方式稱呼為Squad。

這些都很好，但問題是要建立這樣的團隊編制并不難，困難的是要能在前面那3 件事上面，落實的夠徹底、夠深遠。很多公司仍然只是制定產(chǎn)品路線圖，賦予給團隊的任務不是探索與交付，只是設計與開發(fā)。

有些公司甚至還聲稱有「探索階段」，但實質(zhì)上我知道他們并沒有這么做，因為我會用這個問題來探測：「你們在探索階段會測試多少原型？你們在交付階段又會打造多少？」如果他們說：「喔，上個月我們在探索階段測試了10 個項目，然后這個月我們打造了10 個項目。」這樣我就知道這不是探索，這只是設計，也許附帶一點點易用性測試，并不是真的在測試點子。

如果他們很認真實施探索階段，很認真的測試4 大風險，他們必然要拋棄非常多當初的點子，至少要拋棄一半。

附帶一提，真正優(yōu)良的產(chǎn)品公司甚至會拋棄80% 到90% 的原始點子。微軟最近在哈佛商業(yè)評論(Harvard Business Review) 上公開地說，他們大概只有10% 的點子真的可行。

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

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

如果你只是一個被交付「路線圖」 (Roadmap) 的功能團隊(Feature Team)，實際上有一個不那么明顯的狀況正在發(fā)生：若某個公司內(nèi)的高管(executives) 或利益相關(guān)人(stakeholders )，只要他們要求把某個項目加到產(chǎn)品路線圖中，這個人其實就負責了該項目的價值風險(value risk)。

舉例來說：如果某個人說「我們必須加上PayPal 這個支付方式」，不管是誰說的，這個人肯定是相信這件事有價值，他才這么說，否則他就不會這樣說。同時間，這人其實也負責了這個項目的「商業(yè)可行性」 (business viability)。這時候，產(chǎn)品經(jīng)理實際上要負責的只是項目管理。

如果這是一個被授權(quán)的產(chǎn)品團隊(Empowered Product Team)，他們被交付的是問題與目標，而不是產(chǎn)品路線圖。

在真正的產(chǎn)品團隊中，產(chǎn)品經(jīng)理則要負責的是這個解法能夠(為用戶) 帶來價值，在商業(yè)上也可行。所以說，當我們要談論現(xiàn)代的產(chǎn)品經(jīng)理，我們要在真正的產(chǎn)品團隊中談論，而不是在功能團隊中談論，這才是我們應該談論的事情。

我也必須要誠實的說，功能團隊中產(chǎn)品經(jīng)理的工作，遠遠比產(chǎn)品團隊中產(chǎn)品經(jīng)理的工作簡單許多。在產(chǎn)品團隊中工作的產(chǎn)品經(jīng)理，要承受更大的壓力、需要具備更多的技能、每天可能要睡得更少。

這不是說項目管理不重要，這很重要，但這不是產(chǎn)品經(jīng)理工作中的核心。

我也想跟你說，這個問題在很多地方都有出現(xiàn)。譬如說，有很多網(wǎng)絡時代前就存在的公司，他們常常說自己需要做互聯(lián)網(wǎng)轉(zhuǎn)型(Digital Transformation)，但他們就只是設置了一個功能團隊，然后他們還沒搞清楚，為什么這沒有帶來什么改變。

互聯(lián)網(wǎng)轉(zhuǎn)型需要的是產(chǎn)品團隊，但他們還沒搞懂。為什么這么說呢？因為這些要做轉(zhuǎn)型的公司，其實就是想和Amazon 這種公司競爭，但產(chǎn)品團隊正是Amazon 和Google 采用的模式。很不幸的是，就算功能團隊看起來和產(chǎn)品團隊很像，他們終究不是(因為沒有實質(zhì)內(nèi)涵)。

坦白說我不知道在臺灣的情況，就算是在舊金山、紐約、西雅圖，也只有10% 到20% 的公司有真正的產(chǎn)品團隊，剩下的都是功能團隊，這真的是全世界都很常見的問題。很多人常常以為這些卓越的產(chǎn)品團隊都在舊金山，到了南韓或新加坡就很難看到這種團隊，事實上不是這樣。

首先，在舊金山，也有很多糟糕的團隊，我看過很多。這對我來說當然很驚訝，因為過個馬路就有另一個卓越的團隊、來自卓越的公司；其次，在全世界各個角落都有卓越的產(chǎn)品團隊，我遇過的一些頂尖團隊其實在北京、班加洛、斯德哥爾摩、柏林，到處都有。

四、怎樣讓老板們信任Product Team？

Validating Ideas vs. Discovery Solutions

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

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

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

很多團隊擅長這些探索與測試的技巧，但仍然發(fā)生很不幸的情況。

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

我試著跟產(chǎn)品團隊說，你們的工作不只是告訴大家「為何這些不可行」，你們的工作還必須告訴大家「這些構(gòu)想更能解決問題、更有機會成功」。

如果今天的課題是「國際交易支付量過低」，產(chǎn)品團隊除了告訴大家「串接PayPal 不是個好方法」，還必須告訴大家「PayPal 以外還有哪些方法」可以解決問題，這才是優(yōu)良產(chǎn)品團隊和新手產(chǎn)品團隊的差別。優(yōu)良的產(chǎn)品團隊知道，自己還必須提出可行的方案，而且這些方案要更有機會成功。

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

五、要花多少時間在Prototyping？

Planning vs. Prototyping

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

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

大家都知道，在開工前，花點時間想一想手上的問題，是個不錯的做事方法。

但問題是這樣的，的確我們有很多思考問題、架構(gòu)問題、規(guī)劃工作的技巧，但你必須非常注意時間，因為從你接下問題的那一刻，有個碼表就被啟動了，公司的執(zhí)行長和高管們心里就開始算時間，他們心里會算「好，又過了一天…又過了一個月…」，就是這個碼表在計時。

如果你花了大部分的時間做規(guī)劃，你就沒剩多少時間去提出一個可能成功的方案。然后，很快地你的老板們就失去耐性。

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

很多新手產(chǎn)品人會用「借鑒功能」 (Feature Parity) 的策略，以為只要具備「頭號競爭對手提供的所有功能或服務」，就可以擁有很多客戶，但經(jīng)驗上這幾乎不可能成功。

事實上，前面提到的Ben Horowitz 曾這樣跟產(chǎn)品團隊說：「借鑒功能」不會成功，因為要讓顧客愿意轉(zhuǎn)換到我們的新產(chǎn)品，顧客得相信新產(chǎn)品能提供比過去好上10 倍的成果，顧客才會愿意忍受所有轉(zhuǎn)換過程的痛苦與風險。要量化「好上10 倍」，其實也很困難。

好奇問一下，現(xiàn)場有多少人用Slack？噢！真驚人，幾乎是所有人。你的公司可能從HipChat 轉(zhuǎn)換到Slack，這個過程并不簡單。你們愿意轉(zhuǎn)換，因為你們團隊認為Slack 是企業(yè)通訊軟體最好的選項。

這就是為什么做產(chǎn)品很困難，你的產(chǎn)品必須被認為「有非常明顯的優(yōu)勢」，而這不會從「產(chǎn)品規(guī)劃」 (Product Planning) 中達成。

你可以做一堆規(guī)劃但產(chǎn)品也不怎么樣，因為這要從「制作原型」 (prototyping) 來達成。這就是產(chǎn)品探索(Product Discovery)，嘗試各種點子、驗證哪些概念可行，持續(xù)在探索中迭代，直到找到有可能成功的方案。

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

有點抱歉的是，我接下來舉的例子會用到刻板印象。有很多產(chǎn)品經(jīng)理來自管理學院、MBAs，有很多因素讓MBA 畢業(yè)生們喜愛做規(guī)劃，他們很愛手上的各種表，他們就從中獲得很多樂趣。

遇到這樣的人，恩，我會說「ok 很好，但這不是你的工作！」這也只是簡單的部分，困難的部分是當你把手弄臟的時候，你必須坐下來、找設計師和工程師，一起提出可行的方案，任何世界上的規(guī)劃技巧都不會帶你找到可行的方案。

當然我說的并不完全正確，開個玩笑，我認識很多卓越的產(chǎn)品經(jīng)理來自MBAs。但因為MBAs 有這樣的思維習慣，每當我雇用MBA 背景的產(chǎn)品經(jīng)理，我必須打破這樣的習慣。

舉例來說：MBA 有些受歡迎的產(chǎn)品技巧，像是用途理論(Jobs To-Be-Done)。別誤會我，這是個不錯的技巧，但我很少推薦它，因為做完全套流程實在太花時間。

如果你真的走完全部流程，你幾乎沒剩多少時間來提出可行的方案，時間成本昂貴到你無法負擔。如果你是三星要推出新手機，如果這是個長期的計劃，你可以負擔這樣昂貴的成本，也許合理。

但對在座的所有人，這不合理，因為我們有更輕量、更快、更低成本的規(guī)劃技巧，只花幾個小時，然后立刻開始做探索等實際的工作。

我想更清楚的指出，如果你是產(chǎn)品經(jīng)理或產(chǎn)品設計師，你大部分的工作時間都應該花在制作原型(prototyping)。當然，是由產(chǎn)品設計師制作這些原型，然后由產(chǎn)品經(jīng)理來親自試用、測試、從中學習，但你們也是一起透過制作原型(prototyping) 來迭代(iterate)。

產(chǎn)品經(jīng)理與設計師運用原型，工程師運用程序代碼，這就是我說的如何一起工作。基本上這就是你大部分的工作，你將展示原型給不同類型的用戶、顧客、利益關(guān)系人，你將會在團隊中測試它們，這才是產(chǎn)品經(jīng)理與設計師的真正工作。

這也是為什么我們需要真正的「產(chǎn)品設計師」(Product Designer)，今日設計師受訓練的方式也正是透過制作原型(prototyping)，這對我們很關(guān)鍵。

再強調(diào)一次，所有的prototypes 都是MVP，但我更喜歡用prototypes 來稱呼，因為我想強調(diào)這不是真正的、完整的產(chǎn)品。

除此之外，有4 種不同類型的prototypes，所有優(yōu)良的產(chǎn)品團隊都要善用4 種prototypes，我們實際上也需要4 種prototypes 來面對不同的工作、處理不同的風險。有些專門用來量化測試，有些則用來質(zhì)化測試，所以優(yōu)良團隊都需要做這些。

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

補充：關(guān)于Marty Cagan提到的4種原型，在INSPIRED的第45到49章，分別介紹了原型的原則，以及4種原型：

1. 實行性原型(Feasibility Prototypes)
2. 用戶原型(User Prototypes, Low-Fidelity or High-Fidelity)
3. 即時資料原型(Live-Data Prototypes)
4. 混合原型(Hybrids) 也可在這篇文章，找到簡短介紹。

六、滿腦子只有單一方案？

Not Considering Alternative Solutions or Approaches

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

這個問題，和前一個很相關(guān)，也是人類的天性，很常見。

當我們被賦予一個問題，例如要改善國際的購買比例，或要降低流失率，或要增加營收，或要找到新市場的第一個參考客戶，不管是什么目標、要解決什么問題，我們很自然的會立刻獲得一些點子，不管是自己想的或他人提供的。

然后，我們就決定嘗試這個點子，立刻開始制作原型。這很好，但問題是，如果這是我們唯一認真考慮的點子，而且這個原型其實最后不成功，那然后呢？該怎么辦？

很多團隊接著采取的行動，就是繼續(xù)制作原型(prototyping)、繼續(xù)20、30、50 次迭代，直到他們用完所有的時間，或直到放棄。

其實，你真正想要理解的是「總是有很多種解決問題的方法」，所以當你在做少量規(guī)劃的時候，你要確保自己記得「這里有5 種解決問題的方法」，至少要把這件事記在心上。我們認為其中一個方法最好，所以從這里開始，但如果我們沒獲得成果，我們就要嘗試下一個。

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

七、道德上應該推出產(chǎn)品嗎？

Not Thinking Enough About Ethical Risks

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

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

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

換句話說，就算用戶喜歡我們的產(chǎn)品，這對用戶來說真的是件好事嗎？

舉例來說：用戶是個14 歲的青少年，你成功的讓他一天花4 小時在手機上，這是件好事嗎？如果這是個教育類的科技產(chǎn)品，可能是件好事，但如果這是個游戲，也許不是件好事。

這是我們要留意的事情，而且不只是對用戶，也要想這對社會是好的嗎？對我們事業(yè)是好的嗎？這合法嗎？有些公司正在嘗試的事情，可能在法律的邊緣上，這顯然不是件好事。

同時，你也要了解，公司在大多數(shù)時候都不刻意造成問題，大部分都是無意的。但我想強調(diào)的是，產(chǎn)品經(jīng)理通常是第一群看到潛在問題的人，因為他們就在第一線，觀察對顧客與用戶的影響。

所以，如果你看到打造中的產(chǎn)品有什么問題，你真的會提出這個議題，向你的主管提出討論，甚至向你的CEO提出。當然，這是個很敏感的問題，你需要委婉一些的提出，你要確保自己做足功課，真正了解事業(yè)如何運作。

總之，很顯然，我們這個產(chǎn)業(yè)，應該在這方面做得更多。

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

Confusing Optimization with Discovery

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

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

今日，有非常多做產(chǎn)品優(yōu)化上很棒的工具，例如Optimizely、Google Optimize。說清楚一點，這里講的「產(chǎn)品優(yōu)化」 (optimization)，指的是低風險、線上流量、即時資料的AB Testing。

我們基本上是微調(diào)各模塊，看哪一個成效更好，最常見的就是做在轉(zhuǎn)換漏斗(funnel) 上。我強烈建議每個團隊，只要你有正在線上的產(chǎn)品，你獲得了真實的流量，你就應該執(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)造更多價值。

九、勢不兩立的量化與質(zhì)化？

Qualitative vs. Quantitative Learning

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

再來一個問題，這個問題某種程度上碰觸到了公司文化。

當你剛認識一間公司，很快的你可以稍微看出他們的文化。有些是極度偏重量化驅(qū)動的文化，他們的CEO非常相信量化驅(qū)動的決策，又有另一些公司的CEO極度相信她或他的直覺，這則是非常質(zhì)化導向的文化，這些都是很有公司文化的表現(xiàn)。

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

量化測試告訴我們「實際上發(fā)生哪些現(xiàn)象」，但它的限制和主要的問題，就是無法告訴我們?yōu)槭裁础?/p>

量化分析能告訴我們「App 中3% 的用戶使用此功能」，但它沒辦法告訴我們「為何另外97% 的用戶不使用」，質(zhì)化測試就在此時派上用場。所以，好的公司都必須擅長兩種技巧。

就以Google 來說，這家以數(shù)據(jù)為典范的公司，擁有如此巨大流量的公司，其實長期以來都在做質(zhì)化測試。又以Apple 來說，這家以質(zhì)化洞見為典范的公司，他們的量化分析也做得一樣好。

我會這么說：在Google 的標準測試要基于量化方法，但當他們要獲得解釋時，就會運用質(zhì)化方法；在Apple 每天都做質(zhì)化的測試，但當他們要獲得數(shù)據(jù)時，就會運用量化方法。他們兩種都用，因為只有單一一種都會造成偏差，很不一樣但都有用。

十、產(chǎn)品管理的核心能力？

Product Management Competence

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

基本上，幾乎所有之前提到的議題，都有賴于具備核心能力的產(chǎn)品經(jīng)理。

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

這里要清楚解釋一下，產(chǎn)品經(jīng)理(Product Manager) 是工作上的職稱，而產(chǎn)品負責人(Product Owner) 是這些人在敏捷團隊中扮演的角色。正如同交付經(jīng)理(Deliver Manager) 是工作上的職稱，而敏捷專家(Scrum Master) 是這些人在敏捷團隊中扮演的角色。

如果你有一個產(chǎn)品負責人，其本身的工作職稱不是產(chǎn)品經(jīng)理，那是另一個問題，通常你要確保產(chǎn)品經(jīng)理就是產(chǎn)品負責人。

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

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

Product Manager Competence

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

我認為有4 個核心能力：

1. 對用戶和顧客的深入研究
2. 對用戶操作的深入研究
3. 對商業(yè)的深入研究
4. 對產(chǎn)業(yè)的深入研究

作為一個產(chǎn)品經(jīng)理，你的產(chǎn)品團隊有賴你提供以上知識。不過我也要說，如果你是功能團隊(Feature Team) 的產(chǎn)品經(jīng)理，那么你并不需要這些，你最需要的是足夠的項目管理能力。

如果希望在被授權(quán)的產(chǎn)品團隊擔任產(chǎn)品經(jīng)理，那這些也就是你給自己的約定。和你一起工作的設計師和工程師也都希望你為團隊提供這些知識，因為要是你沒有，那每一個決策都要提報給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)在都還記得，第一個輔導我擔任產(chǎn)品經(jīng)理的人告訴我的事情，那是我剛從工程師轉(zhuǎn)任產(chǎn)品經(jīng)理的時候。

這里補充一下，在我當產(chǎn)品經(jīng)理的生涯中，除了在eBay，我都負責為工程師制作產(chǎn)品，我很愛打造開發(fā)者工具與產(chǎn)品，這很好玩。我自己當過工程師，要為工程師打造產(chǎn)品，我心想「我沒問題的，我很了解顧客，他們就和我一樣！」那個輔導我的人，他的名字是Mike Bako，他知道我其實根本不了解我們的客戶。

他跟我說：「聽者，在你被允許做任何決定以前，你必須先去拜訪30 個客戶?！惯@里指的是HP 的客戶，所以他給銷售團隊打了幾通電話，然后跟我說：「你要開始一個3 周的出差，然后拜訪15 個美國公司，以及15 個歐洲公司，等你拜訪完我們再來聊。」

這在HP 是很常見很正常的出差，但在這3 周的旅行之后，我成為了一個完全不同的人。

首先，我發(fā)現(xiàn)有上百種「顧客跟我們不一樣」的方式，特別是很多HP 客戶公司內(nèi)的工程師，跟我們非常不一樣。這些客戶可能是銀行、保險公司，他們的工程師所受的訓練和我們很不一樣，有些人甚至不把自己稱作工程師，可能只叫自己是分析師或程序員。

當然，Mike 早就知道我和顧客不一樣，所以我必須去見見這些人。對我來說，這3周好比上了個了解顧客的速成班，讓我真正理解顧客需要什么、遇到什么困難，我們當然有很多產(chǎn)品可以滿足他們，但這些需求就是跟我們內(nèi)部的需求很不一樣。

除此之外，我也和很多顧客建立的關(guān)系，直到今天我們會在LinkedIn 上聯(lián)系，甚至我到法國時也會碰面。同時，我也和銷售團隊建立了關(guān)系，所以我有了一整個網(wǎng)絡，幫助我了解顧客、了解我們銷售和行銷產(chǎn)品的過程，這里有太多我不知道的事情。

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

2. 對用戶操作的深入研究

第二個：要對顧客使用產(chǎn)品所產(chǎn)生的實際操作，有深入的研究。

這是今天對比我當年初次做產(chǎn)品時的最大差異，那時候是互聯(lián)網(wǎng)之前的時代，我們不像今天有這么多的數(shù)據(jù)。今天的產(chǎn)品經(jīng)理，每天早上剛開始時，應該要花1 到1.5 小時在數(shù)據(jù)工具上。

至少有3 種看數(shù)據(jù)的角度與工具，第一種是看用戶如何在各種設備上使用產(chǎn)品，第二種是看長期的數(shù)據(jù)變化，第三種是看銷售數(shù)據(jù)和銷售營銷活動的表現(xiàn)。

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

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

第三個：必須非常了解你所在的商業(yè)。我必須誠實的說，很多產(chǎn)品經(jīng)理最不喜歡的工作就是第三個，但這也是4 個核心能力中第二重要的部分，最重要的是了解用戶。

如果你聽過這句話「在被授權(quán)的產(chǎn)品團隊，一位厲害的產(chǎn)品經(jīng)理就如同這個產(chǎn)品的CEO 」，這就是在講第三個核心能力，因為另一個必須如此了解商業(yè)的工作，就是擔任CEO 。

所謂的了解商業(yè)，就是說你要很了解「哪些營收支付了這個產(chǎn)品的開發(fā)與營運？經(jīng)費從哪來？成本結(jié)構(gòu)是如何？」你還必須了解產(chǎn)品如何被營銷、如何被銷售、如何進入市場、如何到達顧客面前，你還必須了解過程中的各種限制，例如政府法規(guī)、隱私、商業(yè)合約等所有的限制，甚至還有我們?nèi)绾巫鍪酆蠓铡⑷绾慰缟虡I(yè)合作。

你必須了解這個商業(yè)的各種情況，因為你必須確保團隊打造的產(chǎn)品能夠成功達到顧客面前、為公司創(chuàng)造營收、支付相關(guān)的成本，這就是第三個核心能力。

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

第四個，對大環(huán)境很深的認識，譬如說，目前的競爭格局、重大趨勢。機器學習對我們的產(chǎn)品重要嗎？你必須有個看法。

做產(chǎn)品很大的挑戰(zhàn)是要一直往未來思考，冰上曲棍球的俚語說「注意冰球即將前往的地方，而不是它走過的地方」，意思就是要看向未來的趨勢，而不是今天的情況。

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

十一、輔導產(chǎn)品經(jīng)理

Coaching Product Managers

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

我可以跟你保證，如果產(chǎn)品經(jīng)理的主管們真的落實這件事，今天將是很不一樣的世界。很可惜的是他們沒有做到，因為他們多數(shù)人也不知道這是怎么一回事、他們自己從沒做過、他們從沒看其他人做好過、或他們從沒待過這樣運作的公司，所以對他們來說這也很困難。

但總之，就我的底線來說，每當我遇到不夠格的產(chǎn)品經(jīng)理，通常都是他們沒被好好的訓練、沒被好好的輔導，所以我的挫折感不是針對這位產(chǎn)品經(jīng)理，是針對他們的主管，因為我們要對主管問責，確保他們帶好產(chǎn)品經(jīng)理。

我時常跟主管們說，你頂多就和你最弱的那個產(chǎn)品經(jīng)理一樣強，所以你真的要好好花時間輔導和提升產(chǎn)品經(jīng)理們，這是產(chǎn)品領(lǐng)導者最重要的職責，這真的要說的很清楚。

當然，還有其他很重要的職責，例如產(chǎn)品策略、愿景、目標，但所有事情都有賴于具備夠強的產(chǎn)品經(jīng)理。產(chǎn)品團隊也就只能跟他們的產(chǎn)品經(jīng)理一樣強，如果產(chǎn)品經(jīng)理不夠格，那么你就是浪費優(yōu)秀的工程師、設計師，而這些人都需要公司負擔很大筆的支出。

十二、贏得信任的被授權(quán)團隊

Empowered Product Teams

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

最后一個問題，講完這個就可以進Q&A 時間。

關(guān)于「被授權(quán)的產(chǎn)品團隊」 (Empowered Product Team)，如果你不確定自己的團隊是「被授權(quán)的產(chǎn)品團隊」或「功能團隊」 (Feature Team) ？首先呢，如果你有這個困惑，你們很可能就是個功能團隊，但我當然很希望你能對此感到肯定。

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

1. 你們有真正的跨專業(yè)跨領(lǐng)域團隊嗎？

這個意思是說，對你們的產(chǎn)品來說，要做好這個產(chǎn)品，需要哪些專業(yè)技能？通常來說，是需要產(chǎn)品經(jīng)理和產(chǎn)品設計師。

當我說產(chǎn)品設計師，我指的是一位精通服務設計(Service Design)、交互設計(Interaction Design)、視覺設計(Visual Design)、甚至通常是受過用戶研究(User Research) 訓練的人，這是一個典型的「產(chǎn)品與用戶體驗設計師」 (Product / UX Designer) 的技能組合。

更直白的說，我們真正仰賴的技能是交互設計(Interaction Design)，這比視覺設計(Visual Design) 的要求還更多，當然視覺設計很重要，特別對消費性產(chǎn)品來說，只不過這是很普遍的技能。

2. 真的被授權(quán)嗎？

具體來說，他們有被賦予要解決的問題嗎，而不是被賦予要交付的功能？

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

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

事實上，大部分的產(chǎ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)時間的重點是「真正解決問題的時刻」 (time to actually solving the problem)。

如果問題是流失率是毫無永續(xù)性的12%，我們知道我們的商業(yè)模式將會崩解，除非我們把流失率降低到6%，那我們就是要把問題搞定，再降到6% 之前都不能慶祝。這就是我們說的變現(xiàn)時間，就是那么降到6% 的時刻，這可能表示需要100 種不同的功能或重新改版，或任何該做的事情。

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

總之，這就是我們尋找的三件事。如果你的團隊有這三件事，我們認為這就是你們想要的境界，所有我認識的世上最好的團隊，都很真實的落實這三件事。你會發(fā)現(xiàn)，這里面沒什么神奇的魔法，你沒有什么做不到這三件事的理由。

你沒有這么做的主要理由通常主要原因是CEO 還不信任這個產(chǎn)品團隊?，F(xiàn)在，為了獲得這樣的信任，我們要回到有能力展現(xiàn)核心能力的產(chǎn)品經(jīng)理身上，就是先前我談的那些能力，就是這些讓我們贏得執(zhí)行長CEO的信任。

內(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. 輔導產(chǎn)品經(jīng)理（85%）
12. 贏得信任的被授權(quán)團隊88（88%）

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

內(nèi)容編輯/翻譯：Adam，微信公眾號：一知十，內(nèi)容來源：3PM LAB，視頻來源：Youtube

視頻鏈接：https://www.youtube.com/watch?v=99go9sKp70I&feature=youtu.be&t=389

原文鏈接：https://mp.weixin.qq.com/s/tyBmZAmNl3QfBsLiVTorvA

本文由 @Adam 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議