作者總結了產品經理的三大禁忌，與大家分享。期望能幫助各位產品小伙伴們解決你們遇到的類似問題，或者避免類似問題的發(fā)生。

昨天，有一個入行不久的產品小伙伴，咨詢了這樣我一個問題：

自己在思考問題和提煉需求的時候，總是會自詡站在用戶的角度去看問題，最終通過多次思考、梳理，提出自認為有效的針對性解決、實現方案，或者靈機一動想出一些點子覺得可以討好用戶，就非常高興的排期實現了。

結果上線一段時間后，使用率很低，甚至有用戶覺得是產品經理在自嗨。這讓我覺得很沮喪，但是又無法反駁——因為即便是大公司，在做出來用戶認為是自嗨的功能時，也會招致用戶的吐槽，例如【支付寶在六一兒童節(jié)把用戶的昵稱后加上了“寶寶”還不允許修改】。

可是，我又不忍心把這些大家辛辛苦苦做出來的功能下線，因為沒有足夠的用戶數用數據來證明或者證偽這些功能的價值，讓我沒辦法做最終決定。

而且，我還總想著說不定是在推廣時策略存在問題、導致沒有打中用戶內心的訴求點，導致用戶認知產生偏差，所以還總想著再優(yōu)化一次試試看?？扇绻罱K還是沒有起色，那等于又一次浪費了我們的投入成本。

我現在該怎么辦？怎樣才能解決這個問題？以后又該如何避免這種情況呢？

這位小伙伴提出的問題，我覺得是各位產品小伙伴們在從業(yè)期間的任何階段都可能會發(fā)生的問題，而且無論是資深產品還是新手產品都一樣。所以，有必要認真思考一下，并將我的反思結果分享出來。期望能幫助各位產品小伙伴們解決你們遇到的類似問題，或者避免類似問題的發(fā)生。

一. 由該問題反映出的【產品三大忌】

針對這個問題，我從中總結出了三個關鍵詞：瞎猜、自嗨、傲慢。

瞎猜：“瞎猜”是“需求挖掘與收集”中的一種不負責行為。

需求挖掘與收集，是指產品經理從個人已有經驗、慣性認知的角度出發(fā)，盡力去解讀用戶提出的需求、用戶反饋的信息、產品的使用數據，通過綜合分析和理解，最終明確地定義出【受眾人群的特征】、【需要解決的問題】、【用戶的使用場景】。

而瞎猜，則是指在需求挖掘與收集的過程中，產品經理只憑借主觀判斷來定義需求，忽略了結合【用戶調研回訪】、【數據采樣分析】、【另請他人校驗】等方式，來確保需求定義的合理性。

自嗨：“自嗨”是“方案構思與設計”中的一種不健康行為。

方案構思與設計，是指產品經理在明確定義了需求之后，從自己對于用戶和產品的理解出發(fā)，找出并確定用于滿足該需求的最佳實現方案。

而自嗨，則是指在方案構思與設計過程中，產品經理過分解讀、延伸需求，或在過程中過分關注某些需求細節(jié)和操作方式、忽略甚至違背了需求的核心關注點。

傲慢：“傲慢”是“產品迭代尤其是后期復盤”時的一種非理性行為。

在產品迭代尤其是后期復盤時，產品經理需要根據實際運行數據，來驗證自己的需求實現方案是否被用戶認可或者接受，以及自己的初期猜想是否正確。

但如果在這個階段，產品經理過分對自己的判斷迷之自信，不能聽取來自用戶、市場、運營、技術同學的意見建議，并結合現狀進行分析和判斷，那就是犯了“傲慢”的毛病。

這三個產品經理在產品迭代時出現的錯誤，其實是非常常見的錯誤。

這種錯誤，多發(fā)于產品迭代進入瓶頸期的階段，或者產品處于迭代節(jié)奏非常緊張的時期，或者產品經理需要干的事情太多、嚴重占用自己的產品思考時間的情況下。

我自己也曾經在不同的從業(yè)階段，都多多少少犯過類似的錯誤，而且也對自己和產品的發(fā)展造成了一些負面影響。

二.【瞎猜】的成因、結果和應對方法

1. “瞎猜”的成因

前面已經說過：瞎猜，是指在需求挖掘與收集的過程中，產品經理只憑主觀判斷來猜測和定義需求，忽略了結合【用戶調研回訪】、【數據采樣分析】、【另請他人校驗】等方式，來確保需求的合理性。

由此可知，瞎猜的最初成因，其實是“產品經理在需求挖掘、收集時，使用了猜測需求的辦法”。而“猜測需求后未進行任何校驗”，則是導致“猜測”成為“瞎猜”的原因。

2. “瞎猜”的結果

如果產品經理長期不負責任的“瞎猜”，這對于產品、公司、用戶和自己的負面影響，都是很大的。

• 對用戶：長期上線一些不符合用戶期待的功能，而用戶真正想要的功能卻遲遲沒有出來，導致用戶對產品失去興趣，認為產品不尊重他們的真實需求，進而放棄產品。
• 對產品：為產品增加了很多用戶并不需要的東西，影響產品的原有口碑形象，并且增加了產品的復雜和功冗余程度，無形中提升了產品使用和后期迭代門檻。
• 對公司：造成人力和資源的持續(xù)浪費，影響公司的正向發(fā)展。
• 對自己：養(yǎng)成了不負責任、隨意遐想的產品習慣，并且在持續(xù)做出無效功能和產品的同時，影響了自己的信譽度和口碑。

3. 猜測需求的好處

既然如此，那肯定會有人問，既然知道“猜測需求”可能導致“瞎猜”，并且造成這么多負面影響，那為什么還要去猜測需求、而不是咨詢用戶呢？難道沒有聽過“需求應該來源于用戶”嗎？

任何解決辦法都是利弊共存的。想弄清楚這個問題，我們要搞清楚的，其實是這個問題——相較于直接與用戶溝通，猜測需求有哪些好處，讓大家愿意承受可能變成“瞎猜”的風險。

（1）“猜測需求”是合理的做法，不合理的是沒有依據和支持的揣測。

因為，“需求來源于用戶”講的是一個需求來源的問題。而猜測用戶需求，則跟咨詢用戶一樣，本身是一種獲取需求的方式。

只要猜測需求能夠有合理數據和用戶反饋作為支撐，那需求的本質來源還是用戶，二者并不存在沖突。但是如果在猜測需求時沒有合理依據作為支持，這種猜測就會淪為“不負責任的主觀、片面的遐想甚至瞎想”，變成了“需求來源于產品揣測出來的用戶”，這就違背了“需求來源于用戶”的本質。

（2）直接與用戶溝通，其對于“需求挖掘、收集”的價值未必如你所期待。

這個話題，有很多例子，想必大家都已經耳熟能詳了：福特汽車誕生前的初期用戶調研時，用戶說自己想要的是跑得更快的馬；用戶說想要黃色的PSP，卻在訪談結束后，不約而同的拿走了黑色的獎品······

這些例子，都是為了說明一個事實：用戶嘴上說的想要的，未必是他真正內心需要的；用戶隨口一提的實現方案，未必是真的能夠滿足他的最好方案。

因此，直接與用戶溝通，其對于“需求挖掘、收集”的價值量，是需要打一個問號的。其間，還需要產品經理的深度思考和反復確認，才能夠產生出真正合理的用戶需求。

（3）相較于直接與用戶溝通，“猜測需求”是一個涉及方更少、更可控、實操行更好的辦法。

首先，大部分產品經理在很多時候并不能直接接觸到用戶，而是通過運營、支持、客服、銷售人員的反饋，來間接的了解到用戶的反饋和需求。在用戶和這些人員的溝通中，無論這些人是否專業(yè)、是否足夠了解產品和用戶，需求和反饋在“一次傳遞”過程中，就已經可能產生理解偏差、遺漏、主觀判斷；而在這些人和產品之間額“二次傳遞”的過程中，信息又會出現“再次失真”的情況。期間到底發(fā)生了什么變異，你是不知道并且很難確定的。

當然，這其實反而說明了“直接跟用戶溝通、收集反饋”的必要性。但同時也說明了“多方參與的需求協(xié)同傳遞”的風險。

其次，直接跟用戶溝通或者做用戶調研，都是需要時間和計劃安排的，在產品持續(xù)迭代的階段，產品經理可能并沒有足夠的時間來做用戶溝通和調研。尤其是在創(chuàng)業(yè)公司，產品經理要做的事情非常多，就更加沒有時間分配到用戶調研上去了。

然后，無論是用戶調研還是用戶溝通，需要持續(xù)的進行一段時間或者與多個用戶溝通，才能得到足夠的數據和足以覆蓋各種用戶的反饋，來作為需求合理性的支撐。

這個過程，涉及方比較多（產品、運營、市場、用戶），而且進度和時長都存在不可控因素。如果是在創(chuàng)業(yè)公司，產品經理可能并沒有這種“讓多部門愿意配合協(xié)同、為產品需求收集提供幫助”的團隊資源。

最后，如果是產品持續(xù)迭代的階段，產品經理可能需要在很多時間內就明確產品接下來要做什么、做成什么樣，因此并沒有足夠的時間等待用戶調研和用戶溝通的結果出來，才決定下一步要做什么。

以上，是產品經理在【挖掘、收集需求】的過程，更愿意采用“猜測用戶需求”的原因。

4. 猜測需求的弊端

但與此同時，“猜測需求”也是有弊端的。例如，讓產品經理逐漸遠離用戶、習慣閉門造車······而其中最大的弊端，是可能會導致片面、非客觀的需求判斷，甚至導致“瞎猜”的可能。

因為，任何人都是以自己的身份、等級和視角來感知世界、觀察他人的。即便是產品經理，也無法擺脫這一“個人身份和視角”的局限。

產品經理猜測的需求，首先代表的是“自己所設設想出來的那么一群人”，其次代表的是“自己對于這批設想出來的人的需求猜想”。這期間，有太多誤判、誤解的可能。

5.如何合理“猜測需求”并且避免瞎猜

在知曉“猜測需求”的好處和可能導致的負面影響后，我們就要客觀、合理的使用“猜測需求”的手段。

（1）時刻保持頭腦清醒，提醒自己“猜測需求”是利弊共存的

作為產品經理，無論做什么產品、什么功能，都一定要有清晰的認知——我通過“猜測需求”發(fā)現的需求、找到的痛點、構思的方案，很可能只是滿足我自己或者我所假定的用戶人群和需求場景的。

有這樣清楚的認知后，你在最終確認需求時，也會更加的清醒和警惕。

（2）“猜測需求”和“用戶溝通、調研”結合使用，做好預研、數據分析和復盤

在“猜測需求”的同時，結合做一些小范圍的“用戶溝通、調研”。這樣既能有效控制精力和時間投入，同時也能通過“與用戶溝通、了解情況”，對自己猜測出來的需求進行從用戶角度的“需求合理性”的初步校驗。

其次，在確認需求、最終落地時，一定要做好預研、數據收集、數據分析、后期復盤。通過這樣多驗證幾次，你就會知道：哪些猜測需求是用戶真的認可的，哪些真的是用戶的需求，哪些是自己的瞎猜……

慢慢的，你就會積累出一種判斷經驗，很多瞎猜、強行構建需求的方案或功能，你稍微想深一點，就會覺得不靠譜兒。

這種經驗，是真的要通過不斷經歷“前期預研、中期小范圍試錯、采集分析數據、后期復盤”的完整驗證過程，才能逐漸獲得的，沒有一個牛逼的產品經理，不是這樣逐步走過來的。

所以，如果是偶爾的“有數據或用戶反饋支撐、卻最終被用戶使用行為和數據證偽的需求”，放寬心就好，不要過分苛責或者計較。但必要的承擔責任和復盤總結，也絕對不能少，并且要從中總結原因、吸取教訓，盡量避免做一些臆想的需求。

支付寶“寶寶”事件的一些個人想法

最后，關于【支付寶在六一兒童節(jié)在用戶昵稱后加上了“寶寶”還不允許修改】，下面是我的看法：

支付寶的“強加寶寶并且無法修改招致用戶憤而開噴”，其創(chuàng)意本身是沒錯的，錯的是實現方式。

創(chuàng)意：

在六一兒童節(jié)，通過給用戶貼上“寶寶”標簽，來迎合節(jié)日氣氛。這個創(chuàng)意，雖然并沒有什么新意，但是確實能起到迎合節(jié)日氛圍的效果，而且很貼合“人們在六一總會不由懷念童年歡樂時光”的節(jié)日感性觸發(fā)點。

實現方式：

強行改用戶昵稱，并且不允許用戶修改回來。想出這種實現方式的人，不管是產品、運營還是市場童鞋，都絕對沒把這個當回事兒，更沒有帶腦子。

要知道，昵稱這種個性用戶信息的編輯權限，在可感知范圍內，必須是用戶自己的。就算產品經理明知道這只是一個后臺數據庫中無關痛癢、隨時可操作的字段，也不能表現出自己可以隨時調整，更不能真的隨意去修改。而且，只有在出現問題或者客服為用戶提供支持時，并且是用戶主動提出或者表示接受的場景下，才能幫助用戶調整。作為一個互聯網人，這一點，應該是基本常識吧。

更何況，支付寶的用戶主流認知，就是一個電子錢包，一種互聯網支付工具。你敢在用戶的錢包里隨意改用戶的簽名，還不給用戶改回來的權限，用戶當然會覺得：臥槽，你今天能隨便亂改我的昵稱，明天是不是就敢把我錢包里的錢轉到別人的賬號里了？你通過改昵稱這件事，變相的讓用戶認為你能隨意動他的賬號，那用戶還能不把你往壞處想？不噴你噴誰？

你哪怕是在六一當天，用戶首次打開支付寶時，推動一個“今天，我們都是寶寶”的h5頁面，然后給用戶隨機推送一些寶寶勛章，比如“乖寶寶”、“好寶寶”、“萌寶寶”，勛章會展示在昵稱旁邊，再配合一些“當天購買玩具產品享受某類優(yōu)惠”的營銷活動，這樣是不是也行??？

所以說，支付寶的“寶寶事件”，就是一個功能實現過程中沒有人帶腦子的節(jié)日運營活動。并不算是瞎猜、自嗨，更不是靈機一動……腦子都沒帶，哪來的靈機？

以上是個人的一些想法，不喜勿噴。

寫在最后：

原計劃是在一篇文章中把“三大忌”一次性分析清楚的，在分析完【瞎猜】之后，卻發(fā)現不知不覺已經寫了這么多了······看來我的廢話確實不少啊~尷尬

由于時間所限，我計劃把它拆成2篇文章，在下一篇文章中再繼續(xù)詳細分析【自嗨】和【傲慢】。如果有未到之處，還請大家諒解。

大家對于【產品經理在產品迭代過程中的瞎猜、自嗨和傲慢】，有什么新的見解或想法呢？歡迎對此感興趣的童鞋，或者想要一起交流探討的朋友，評論交流。

本文由 @Aaron暖塵 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。