產品經理常犯的十大頂級錯誤

產品經理需要創造產品。上帝也是個產品經理，他創造了人這個產品。

做一個成功的產品非常難，除了有資源、時機等問題以外，更大因素在產品經理自己。好的產品經理能協調資源，能把握時機。但產品經理自己也經常犯錯誤。

最近翻看了之前的記錄，發現有個很資深的產品專家Marty Cagan 提過類似的觀點。Marty Cagan曾經擔任過網景的副總裁，負責eBay 產品的資深副總裁，有過非常豐富的產品設計和產品管理經驗。無招也參加過Marty Cagan 產品培訓，於是我和無招，以Marty Cagan的總結為基礎，加上我們對產品設計的理解，整理出了這篇文章，分享給大家。

將使用者需求混淆為產品需求

大部分產品經理的工作流程是：收集完使用者需求，開始編寫產品需求文件，然後交給技術人員開發，接下來跟蹤專案進度，協調資源，驗收成果，最後釋出產品。

整個流程沒有錯，容易產生錯誤的地方在於，產品需求如何確定。在淘寶內部的產品經理也是如此，經常把運營同學的需求直接翻譯成文件，交給技術人員開發。最後的結果是產品的功能點越來越多，產品越來越複雜，成為一個大雜燴。

一定要從產品設計的角度思考需求，把使用者的需求轉化成為產品需求。在火車沒有出現的時候，你問使用者最想要什麼?使用者會說，我想要一匹跑得更快的馬。使用者的需求看上去是要一匹好馬，但實際上轉化成產品需求就是，需要更快的交通速度。

使用者需求是提出的一個問題，產品需求是解決這個問題的可行方案。所以當使用者需求被表達為一種解決方案時，要探尋其背後的隱蔽問題。比較好的解決問題的辦法是：加強可行性分析和需求評審。

將老闆的需求混淆為產品需求

這可能是很多產品經理內心的痛，對於大多數淘寶的PD都應該遇到過大小老闆過來提需求，就算明顯不靠譜的需求，也不好反駁，只能安排開發。

老闆有老闆的視野，有他獨享的資訊和經驗，還有他的權利。老闆的需求肯定要聽的，老闆也是使用者之一，他的需求也是使用者需求，只是不要聽過來直接當成產品需求。

針對老闆的需求，更要強化需求追溯。從老闆這裡深入地理解他的需求來自哪裡，是基於什麼樣的場景和什麼樣的使用者，有沒有具體的例項。

老闆的需求大部分都是合理的，只是優先順序沒有那麼高。我們可以採用拖延戰術來應對：

老闆啊，你這個需求很合理，而且相當到位，我計劃在下一個版本好好規劃一下，這個版本的功能點已經比較多了，開發人員實在太少，啊，老闆，能否幫我爭取多來兩個開發工程師……

等到下一個版本的時候，老闆經常忘記了他的需求了。如果他還記得，就幫他實現一部分功能好了，面子還是要給的。

將發明(invention)混淆為創造(innovation)

這個對於搞創新的產品經理們來說，是常常遇到的問題。尤其是經驗尚淺，有強烈使命感的產品經歷常常會將一個idea，一個使命直接當做創新來執行。

發明是實驗室裡的，創造是產業裡應用的。實驗室的東東是新東西，但是限定了前提條件，而且在商業性驗證，市場推廣，規模化等方面都不會事先想得太清楚。

創造則是產業級的一個改變，能商業化，能養活團隊，能規模化，能真正抵達使用者並讓使用者接受。

最不可接受的是，對於一個新產品，前景非常好，做了很長時間的規劃設計，投入了不少工程師開發，過了半年才出來一個有很多缺陷的產品，也無法推向市場;而且這時候市場已經產生了一些變化，還要接著改產品需求，同時又要完善之前的產品。這種產品最後必死無疑。

應該專注最小核心問題，解決最核心的問題，完成小而美的功能，然後快速迭代，使用者第一。要能養活團隊，讓團隊成員過上好日子。否則就算公司不停專案，團隊也會人心渙散。

以自己的需求取代使用者的需求

大多數產品經理，溝通能力比較強，也比較強勢。當產品經理急於求成的時候，或者找不到目標使用者，過分超前的時候，容易YY出一些產品需求。他們不找到目標使用者驗證核心問題及解決方案，以理所當然的想法來描述產品故事(使用者場景和使用者問題)。

現狀很多人強調要重視資料，也容易讓產品經理忽略客戶，因為自己天天看資料，就把自己取代了客戶。我在負責搜尋產品的時候，經常跟搜尋的產品經理講，要把使用者當人看，不要當成資料看。資料很重要，但資料容易掩蓋使用者人性化的需求。

產品經理應該學會傾聽不同觀點，多和那些敢於批評自己觀點的人溝通。無論是小使用者量的產品還是大使用者量的產品，一定要抽時間瞭解真正使用者的需求和感受，哪怕是跟他們閒聊，一定能發現一些之前想法不一樣的結論。

將“建立正確產品”當作“正確地創造產品”

這就跟“正確的做事和做正確的事”是一個道理。很多人習慣於被安排，然後按照流程去做事，並不想這件事情到底為什麼要做，是否真的要做。

產品經理也容易如此，到了一個崗位，接到任務要完成一個功能，然後就按照流程去做，最後這個產品是很完美的做完了，但基本上沒有人用。在大公司、嚴謹的公司裡更容易出這種問題。尤其是細分工作，平臺化流水化運作的環境之中，產品經理容易成為一個規則下的執行人。

舉個例子，如果產品經理接到任務是要設計一個網站來宣傳公司的技術品牌。產品經理最常見的做法就是設計網站的各個模組，內容，甚至還設計了一個論壇，形成文件，然後交與開發。事情做完了，這個網站是做好了，但發現沒有任何流量，完全起不到宣傳公司技術品牌的作用。這個例子正確的做法應該是怎麼樣的?大家可以自己思考。

我們應該鼓勵產品經理去實現自己的夢想，也可以考慮把團隊垂直化，一方面可以提高效率，另一方面可以避免很多錯誤。

將“新增功能”當作“產品提高”

任何產品都需要不斷的新增新功能，一方面要滿足更多使用者需求，另一方面需要適應環境的變化。產品經理經常把新增功能當成了產品提高，這種現象在一個在既有成熟產品的團隊裡會比較明顯，已有的思路和評估指標常常造成的就是不斷地同質化，不斷地新增nice to have的功能。

但新增功能，不一定是產品提高。如何確定是否是”產品提高”?確定一個合理的產品的衡量指標非常重要。

一個不合理的產品衡量指標，很容易對產品帶來負面效果。在淘寶就有不少這種例子，不停的推出掃貨產品，以成交轉換率和帶來整體成交額來衡量新功能是否成功。新浪微博也有類似的功能，換背景圖片和模版，送禮物和賽禮物，推薦活動關注等，內部應該都是以有多少使用者參與為衡量指標。

如果淘寶搜尋把搜尋轉化率作為衡量指標，最終的結果就很容易造成低價和爆款盛行;新浪微博把使用者參與度作為衡量指標，就會出現到處都是推薦關注的功能模組，讓使用者容易反感;去年噹噹網就做了一件事情，鼓勵使用者去發書評，內部應該是衡量多少人參與了評價，最後導致的結果是，大量的垃圾評論產生，讓原本特別好的書評也被淹沒掉了。

如果希望解決解決這個問題，需要真正從使用者的角度思考問題，制定合理的衡量指標。有些衡量指標是相互制約的，例如淘寶搜尋的衡量指標中就有一個基尼係數，用來保證流量分佈不能過於集中。如何制定合理的衡量指標，不同的業務會很不一樣，需要綜合性思考。

無法分清“激動人心”和“有也不錯”的功能。

這個錯誤和第六點錯誤有些類似。

無線網際網路的發展，讓使用者對產品越來越挑剔，如果沒有一些“激動人心”的功能，很容易讓使用者忘記這個產品。但產品經理經常花了太多精力在打造一些“有也不錯”的功能。

如果一個產品的使用者達到幾十萬，任何一個功能，都能滿足一部分使用者的需求，也都有部分使用者在使用。類似的功能需求會永遠做不完，持續下去，一定會讓產品越來越複雜。微信在這方面做了一個很好的榜樣。微信最大的功能在於溝通，雖然微信可以做很多事情，包括媒體，朋友圈等，但微信產品的主線還是在溝通上，把溝通的功能做到非常方便，對講功能的設計就是一個激動人心的功能。微信也做了一些有也不錯的功能，例如：語音提醒。看上去不錯，實際上用的人並不多。

資源總是有限的，產品經理應該把精力放在主路徑上，不斷地問問自己是產品的典型使用者，使用者是否真的喜歡真的急切需要這個功能嗎?設計出一個激動人心的功能，遠遠比提供10個有也不錯的功能更重要。

追求印象深刻的需求文件，而不是追求感人的產品

寫出一份好的PRD(產品需求文件)，確實重要，因為可以幫產品經理理清思路，同時又讓技術人員知道產品的設計細節。但我以前一直是在做技術，對PRD看得不會太仔細，不清楚的地方才會去細看，就像我們們平時對待電器說明書一樣。另外，PRD再深刻，目標使用者也無法真正感知產品的設計。

因此對撰寫PRD，應該是夠用就好。最好的方式是和技術、設計人員一起有效溝通，正式啟動產品實現之前，以全動態高保真原型來獲取使用者的認可，感知使用者的心聲。純演算法型產品或者資料探勘類產品可能在這點上有難度，可以用真實的資料分析來表達這類產品設計。

將產品釋出當作了成功

這個錯誤不只是產品經理容易犯，很多公司的老闆也容易犯這個錯誤。在一些大公司，釋出了一個小產品，甚至釋出了一個小功能，都會有洋洋灑灑上千字的喜報郵件。這種郵件很鼓舞士氣，只是不能把產品釋出當成產品成功。

一個看似很簡單的道理，但做起來不那麼容易。很多產品經理急於釋出自己的產品，導致產品體驗非常不好，就算後續快速改進，也很難挽回使用者的流失和口碑。現在有很多產品都開始實行邀請測試的模式。例如微信的5.0測試版，微信公眾賬號的選單功能;微博的媒體賬號測試;微淘的邀請測試參與;淘寶搜尋上線很多功能，也是用5%的流量先做測試。這些做法都是為了避免冒然釋出產品或功能。

產品釋出，意味著使用者才真正開始使用，成功與否不是看產品是否釋出，而是看使用者是否真正喜歡。要做到使用者真正喜歡，產品釋出才是剛剛開始。

進入“餵養野獸”的模式

什麼叫野獸餵養?野獸永遠吃不飽，需要拿東西不停的餵養。一個產品經理，有時沒有想好到底應該做哪些功能，但需要給其相應的技術團隊有足夠的工作量，於是不得不找一堆小功能，讓他們去開發。

很多公司都有類似情況，經常會聽到技術人員或者設計人員說：你這裡工作少，你這裡的工作沒有新鮮的可學的東西，我沒有成就感，我的晉升會受影響，我要去做大專案…….這時候產品經理如果需要爭取到這些資源，必須提供足夠多、足夠大的需求，讓相應的團隊來開發，不停地給出需求把開發和設計的肚子餵飽。需求是什麼已經不重要，重要的是支援這個產品的資源不會被別的產品搶走。

這麼做的壞處顯而易見，不只是浪費公司的資源，更重要的是，會讓整個產品沒有邏輯，功能臃腫，最後要麼成為一個平庸的產品，要麼需要做大的減法手術。但一個產品做加法容易，做減法非常困難。任何減法都會損害一部分使用者的使用習慣。

這個錯誤的產生，有時候是不自覺的，甚至發生了我們自己還沒有意識到。要避免這個錯誤，一方面需要從公司組織上給與合理的時間培育產品，也給予產品經理足夠信任，產品經理也應該有足夠的自我反思;另一方面考慮團隊的垂直化，讓技術人員和產品人員都在一起，要麼一起精彩，要麼一起落寞。

以上10條頂級錯誤，是Marty Cagan根據他十幾年的產品管理經驗總結出來的，對網際網路產品的開發很值得參考。特別是一些中大型的網際網路公司，有多條產品線，技術分工越來越細，類似的錯誤就越來越多。Marty Cagan 原文寫的是產品設計的十大頂級錯誤，本文這裡改成了產品經理，會適合國情一些。

當然，不同的人總結出來的十大頂級錯誤可能不一樣，如果讓我來總結，可能還有其他的一些錯誤。本文中提到的這些錯誤不是適用所有的公司，如果你對產品設計感興趣，或者你本來就是一名產品經理，你可以把這篇文章收藏起來，每過一段時間拿出來看看，對照一下自己是否犯了同樣的錯誤。