產品經理作為互聯網行業蓬勃發展時應運而生出現的一個崗位，吸引了越來越多人加入。由于缺少產品經理相關專業課程，因此大多數產品經理是在摸索中成長，在這個過程中會犯一些錯誤，對未來的發展造成一定影響。文章對產品經理容易犯的錯誤進行了梳理總結，快來看看你是否犯過？

文中提到的錯誤，并非PRD寫的不清楚、各部門溝通協調不及時或者產品設計流程有誤等操作層面的，而是認知上的。筆者認為，具體操作上的錯誤，自實踐中多注意觀察，多向他人學習，是可以逐漸改正的。而認知上的錯誤，如果想要改正的話，就要看何時能夠發現了。

下面來說說這幾個錯誤。

一、盲目模仿

1. 模仿的利弊

越來越多的產品在設計上形成了定式，即一種固定的樣式，不考慮顏色和logo很難將他們區分開（如下圖）。這對于產品經理來說，既有好處也有壞處。

好處是這些產品設計是經過市場和用戶驗證的，直接拿來使用既可以減少了培養用戶使用習慣的周期，又減輕了產品經理在設計時的思考負擔。讓產品經理更聚焦于業務邏輯、用戶調研等，而非交互設計。

而壞處也恰恰是因為直接拿來使用時，大多數人都不會思考設計背后的邏輯。不同種類產品面向的用戶群體不同，在產品發展的不同時期面向的用戶數量級也不同，產品的每一個設計都是經過推敲打磨才最終成型的。如果不了解設計的原因，一味選擇模仿，會犯一些令人啼笑皆非的錯誤。

2. 一個模仿失敗的例子

近期買了臺可以通過手機APP控制的冰箱，體驗了一回這個APP。誰知不用不知道，用后發現槽點好多，正好可以當做反面教材。在這里僅用注冊登錄功能來舉例。

注冊登錄功能雖然是個常見功能，但是想把它設計好并非易事。根據漏斗分析模型，注冊步驟的每一次增加都會伴隨著用戶流失，如何通過更少的步驟收集到更多所需的用戶信息，又不會讓用戶失去耐心是一個值得思考的問題。

先簡單描述下這款APP的注冊流程（如下圖）：

1. 在登錄頁面可以通過輸入已經注冊成功的賬號或者社交賬號登錄，也可以注冊新賬號；
2. 選擇社交賬號登錄，跳轉到第三方登錄頁面，選擇是否要注冊賬號或者綁定已有賬號；
3. 選擇快速注冊后進入賬號注冊頁面，需要填寫手機號、圖片驗證碼、短信驗證碼、密碼才能注冊成功；

就整個流程而言，有不少地方對用戶不夠友好，讓人想要吐槽甚至中止流程，比如：

（1）為什么第三方登錄后還需要綁定手機號？

這個問題的答案有很多，比如為了收集用戶信息，為了產品運營生態的搭建，為了風險控制（避免第三方不給提供登錄接口），避免出現賬號合并的困境，數據好看等等。

這些答案沒有對錯之分，只要結合自身的業務特點，就一定會有不同的考慮問題的出發點和側重點。甚至一款產品的不同階段，對第三方登錄也會有不同的登錄設計。究其根源，是用戶體驗和用戶價值的一次博弈。是選擇讓用戶感覺很”爽“的體驗，還是盡可能多的收集用戶信息、讓產品數據好看的價值。

而對于家電控制這類APP，在筆者看來只有風險控制（避免第三方不給提供登錄接口）這個理由能站得住腳，雖然這對于這類APP而言是多大的風險。但如果是處于其他收集信息的原因，那值得吐槽的地方就太多了。

首先，買冰箱時已經填寫了姓名、電話、地址、身份證號等信息，為什么還需要再填一次？其次，運營對于剛需且購買頻率低的商品起到的作用到底有多大？再次，這類打開頻率很低的APP，消息推送的意義又在哪里呢？還有，冰箱這種產品，數據好看是通過APP注冊用戶數體現的嗎？總之，這是讓人難以理解的一步。

（2）同時需要圖片驗證碼、短信驗證碼和密碼的意義是什么？

圖片驗證碼一般用于PC端，其目的在于注冊時防止機器批量注冊，登錄時防止用暴力破解的方式不斷嘗試登錄。而在手機上已經逐漸棄用（近幾年沒見過），因為輸入不方便，對用戶不夠友好。

短信驗證碼是近年來APP注冊登錄的主流，既簡化了注冊登錄的步驟，同時免去了設置和記憶密碼的煩惱，也是對登錄人員的設備進行了驗證。

密碼是前幾年主流的加密方案，近年來由于短信驗證碼盛行，所以使用的場景變少了。但是很多PC端、網頁端的登錄，還是需要輸入密碼的。

一個控制家電的APP，考慮到其使用頻率和對安全性的要求，真的需要這三項驗證齊上嗎？讓人不禁懷疑產品設計者的初衷。

3. 總結

類似的問題還有很多，比如注冊成功后的快速登錄流程（其實一點也不快）、賬號和頭像的展示等，由于篇幅有限就一一展開說明。舉這個案例是想說明，未搞清產品設計時遵循的原理、未結合自己產品的實際情況和業務特征，盲目進行模仿做出來的產品，有時會犯一些讓人啼笑皆非的錯誤。

二、忽略試錯的必要性

1. 與盲目模仿的區別

這個問題乍看和上面的盲目模仿有些相似，但仔細推敲卻有所不同。

盲目模仿是在行為上模仿競爭對手的產品，不關心產品設計所遵循的邏輯，也不關心功能與產品自身和業務特征是否匹配，直接拿來照抄。大多數時候是在不知道如何設計產品，或是不知道產品路線的發展方向時，采取的一種措施。

而忽略試錯的必要性更多是出于心理上的，認為別人的產品沒有什么了不起，自己照著做就能成功?；蚴钦J為從頭開始做用戶調研、需要分析、產品設計等工作太麻煩，這些工作沒有什么了不起的，如果有捷徑可走（照抄），就沒必要一次次的犯錯碰壁。

2. 案例與說明

記得看雷軍的傳記時，曾經看到過這樣一個案例。

98年時雷軍和張小龍溝通，希望能用15萬元買下FoxMail，起初進展順利。后來雷軍由于工作原因走不開，請研發部同事去和張小龍談，結果沒談成。原因是研發部同事認為，他們一兩個月也能做出FoxMail。

后來，博大互聯網絡公司以1200萬元收購FoxMail，張小龍加盟博大任首席技術官。再往后張小龍的經歷就廣為人知了。

假如雷軍能和張小龍合作，他們會做出怎么樣的產品，又會對行業產生怎樣的影響，這些永遠也不得而知了。但合作失敗的原因，想想卻讓人遺憾。乍看上去是一種大公司特有的傲慢造成的，而實際上是因為忽略了一個好的產品的由來所必然要經歷的步驟——試錯。

模仿一款產品的外形和交互很容易，但是理解它內在的邏輯很難。頁面的樣式、交互的設計、功能的邏輯，這些都是經過調研、回訪、分析等過程，一步一步的進行優化，最后打磨成一個用戶使用舒服，能為用戶解決切身需要的產品。

沒有那無數次的犯錯被用戶吐槽，沒有那一次次用自己的思維和用戶碰撞擦出靈感的火花，沒有那一次次的對業務邏輯進行推敲完善，是不可能做出好的產品的。其中有太多的細節問題需要處理，有太多的坑只有結結實實踩進去了才會明白。這些經歷不是照葫蘆畫瓢就能擁有的。

筆者一直認為，能從0到1做一款產品的產品經理，是幸運的也是幸福的。只有踩過無數的坑，犯過無數的錯，才能積累到寶貴的經驗，才能鍛煉自己的能力，形成一套自己做產品時思考和行為的模式。

遺憾的是近年來接觸過不少產品經理，很多人喜歡問有沒有現成的文檔，或者是能不能給個已有系統的頁面截圖。有時候只是很簡單的一個需求，不會對業務產生多大影響，試錯練手非常不錯。但這些人卻忽視了讓自己進步的機會，選擇了走捷徑，這樣是不利于產品經理成長的。

3. 總結

作為一名產品經理，到底什么才是最重要的，或者說什么才是核心競爭力呢？難道只是為了寫一份文檔，或者做一個頁面嗎？肯定不是這樣的?？倳行鹿δ鼙婚_發出來，有新產品讓我們眼前一亮，有未經開拓的領域等待我們去探索。那時候又模仿誰呢？恐怕也只能不斷試錯，摸著石頭過河了。

筆者認為對于一名產品經理來說，發現問題、思考問題、解決問題的思維方式，才是最重要的。

進入一個新的行業，遇到一個新的項目，應該如何進行調研、分析，迅速收集信息并形成自己的判斷。遇到新的問題應該如何解析，如何著手處理。這些都是一個產品經理在工作中，逐漸形成的自己特有的思維方式，或者稱之為產品方法論。這些是產品經理應該鍛煉的能力，也是產品經理最寶貴的財富。

所以，真心希望每一名產品經理不要忽略每一個試錯的機會，不要去走那看上去的捷徑。你能走的捷徑其他人一樣能走，能輕松獲得的技能從來都是廉價的，是不具備競爭力的。愿每一名產品經理能做出屬于自己的產品，成為一名真正的產品經理。

三、需求≠功能

提到產品經理的工作職責，很多人會說用戶調研、需求分析、產品設計、推動上線等等。因此，很多人認為產品經理的工作是做一個網站、APP或是功能，甚至很多剛入行的產品經理也是這么認為的。但是這樣的答案并不準確。

實際上，產品經理的工作不僅僅是為了推動功能的上線或是APP的更新，而是為了解決問題（需求）。很多人之所以得出上述結論，是因為混淆了需求與功能的區別。

1. 不開發新功能也可以解決需求

做一個網站、APP或者上線一個功能模塊，這些都是顯性的，而產品經理要做的，是透過表面顯性的現象，看到背后隱性的本質，也就是需求產生的真正原因。

產品經理工作的本質是解決用戶需求。不論是通過系統，還是通過功能模塊，亦或是一個excel、一條sql語句，甚至是一句話。只要能解決用戶的痛點，就算完成了自己的工作。

以筆者曾經接到的一個需求為例，需求提出方是財務部門，要求在系統中增加報表，報表要求展示交易訂單數據，并能進行篩選查詢和下載。

通過對需求的了解并對其真偽、業務價值、可行性等做出評估，筆者認為該需求雖然開發難度較低，但是并不具備開發價值（使用頻率低、使用范圍?。?。

最后的解決方法是找大數據部寫了個sql，確定使用周期后通過郵件發送。當然，如果公司有數據平臺可以提取數據，也可以評估是否給需求方開放權限自行提取。

也許有人會說，不就是加一張報表嗎，做這個能廢多大勁兒。其實，每一位產品經理都會對自己負責的系統做出定位（系統存在的核心價值是什么），會對系統的產品路線進行規劃，并非所有的需求都適合做到系統中。貿然往系統中增加功能模塊會使系統冗余和混亂。

2. 多運用已有的工具

當前網上各類工具應有盡有，且功能較為實用，通常會比自己重新做要好的多。如果能直接拿來用，既節省了開發成本、開發時間，同時還能快速驗證自己的運營模式是否可行，從而進行調整。沒有必要什么系統都要自己開發。

去年有朋友問筆者如何做一個直播平臺，原因是公司想要進行視頻直播。筆者當時很詫異，因為他所在的公司是一家互金公司。他告訴筆者公司想要通過視頻直播，給用戶普及金融知識，順便讓用戶對公司更有信心。

筆者當時問了幾個問題：

（1）用戶數量、用戶活躍度、年齡段分布、地域分布、投資金額分布等數據各是什么？

答曰：目前這些數據都不知道，只知道計劃面向大額用戶直播。

（2）直播計劃什么時候進行，直播周期是多久，直播的主講人和直播內容是否有準備？

答曰：直播隨時可以進行，直播一到兩周一次，主講人和直播內容一周之內能準備好。

（3）計劃通過直播達到什么可以量化的成績？

答曰：沒有，先直播看看。

聽完這種一問三不知的回答，筆者告訴他這些基本問題都沒想清楚的話，就先不要做，原因如下：

1. 沒有用戶畫像和用戶行為數據，就沒法確定用戶人群的特征，也不能確定網絡直播的形式是否會被接受。說極端點兒，如果用戶是老年人，或者是不太關注直播的人群，這個直播給誰看呢。
2. 金融投資用戶，尤其是大額用戶，對于平臺的選擇會以安全性為主，利率為輔，更關注平臺的背景、牌照、合規性等因素，不太會被直播內容所動搖。當然，線下開宣講會效果還是有的。
3. 既然主講人和內容都有了，那就盡快開始，驗證直播的效果。如果等到系統開發完，誰知道那時候的市場環境如何。
4. 沒有可量化的績效指標，如何判斷直播效果。費半天勁兒做出來一個沒法驗證效果的產品，意義有多大呢？如何確認產品上線后下一步的迭代方向呢？

筆者的建議是：

現在直播平臺那么多，斗魚、B站、微信直播等，產品成熟，技術穩定，注冊個賬號就能開始直播。而且很多用戶本身就有賬號，直接打開就能看，省去下載和注冊的步驟，降低觸達用戶的成本。

分析用戶的行為，做出用戶畫像，確定直播可以量化的成績，然后找個平臺試播兩到三次，收集效果和用戶反饋。也許到那時候，就覺得不需要做新的直播平臺了。

他聽了后若有所思，想了想說準備再仔細考慮下，然后和提出這個需求的領導聊聊，看看能不能換個方式去做。祝他好運吧。

其實上面說了這么多，歸根結底只有一句話：不要局限于解決問題的方式，能解決問題的產品經理才是好的產品經理。

受篇幅所限，還有一些錯誤會在今后的文章中指出。希望這篇文章能對讀者有啟發，也歡迎讀者在下面的留言區告訴我，還有哪些認知上的錯誤是產品經理容易犯的，讓我們大家一起學習，一起進步。

作者：打醬油的熊，公眾號：打醬油的白熊

本文由 @打醬油的熊 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議