瀉藥。主要表現在

1.沒有競品調研就開始閉門造車

2.拋開商業模式只談功能

3.需求分析表面化，不考慮複雜業務邏輯

4.完成需求就萬事大吉，不做專案進度跟蹤

一、不肯接受他人意見，為自尊而堅持。

二、腦袋一拍想需求，改來改去強詞奪理。

三、過分糾結於原型，在顏色和動效上浪費大把時間。

四、溝通能力差，不及時更新和完善需求文件。

五、缺少對專案過程的控制，來回扯皮導致專案卡殼。

六、盲目接受老闆的需求，不提出合理的拒絕。

七、堅信自己是使用者的爸爸，不做調研只想當然。

引言

產品經理受大多數人詬病的原罪就是需求變更。當設計師或開發人員加班加點做的差不多時，產品經理要改需求，那大家肯定都會罵他不夠專業。然而事實上，改需求未必是不靠譜的表現，因為可能是市場機會變了，或者外部暴露了問題，勇於提出是好事。那麼，產品經理什麼樣的行為才是真不靠譜的？有如下的這幾個表現。

面對業務方提的需求，缺乏獨立和深度的思考，稍作抵抗就放棄挑戰對方，並很快進入了方案產出階段。特別在面對老闆的需求時，只想著如何快速響應和滿足需求，急於把方案出好，產品經理成了方案設計師。等到專案評審，開發們問為什麼要做，那必然是沒法有理有據地說服別人。最後不得已，拿業務方/老闆來當擋箭牌，或者直接打感情牌，那在開發們的心裡是絕不會服的。即便專案有了推進，產品經理的信譽也早已破產，後面的合作就難了。

當需求的價值與合理性需要輪到開發來質疑時，那產品經理就是需求傳話筒而已。

經常過度關注細節設計，強調主觀使用者體驗。在產品的互動和視覺設計方面，提過多個人意見，指手畫腳，干擾設計師的工作，甚至提的需求直接到了畫素級別。不信任設計師的專業能力，也提供不了有效的資料支撐，只憑自己的感受要求設計稿返工修改。最後好說歹說，產出了大家勉強都滿意的版本，然而實際效果卻沒有本質差別。

產品經理不去思考業務邏輯、使用者場景和發展規劃，只沉浸在設計細節的最佳化上，那便成了設計經理，還是不專業的那種。

提交的產品文件漏洞百出，缺乏很多必要功能點的描述。一些細節沒有想到，當開發問到後支支吾吾，或者現場想了個不完善的方案，事後問題重重。一些想清楚的功能細節，卻嫌麻煩，寫的不夠明確，多了很多重複的溝通與解釋。自以為專案評審時說的清清楚楚，結果隔一天開發就跑過來再問一遍。專案程序中，開發、設計有問題，不能及時的響應，有時候甚至找不到人。最後產出的結果，要麼不是自己想要的，要麼只能打回去改正。

產品經理文件梳理不清，過程跟進溝通不給力，那就是挖坑不斷，毀專案不倦。

不看產品資料和反饋，新的需求全憑主觀臆想。也沒有深刻地去了解使用者現狀，只想著怎麼樣改善現有功能，盲目追求更新變化，脫離了使用者基礎。把自己的喜好當成使用者的喜好，總覺得新上的功能使用者一定喜歡。

產品demo上，愛加技術細節，太偏實現性，認為這樣對開發更友好。出方案時，容易想實現起來要怎麼做，會不會做不了，限制了思維。甚至經常幫技術想實現方案、評估工作量，多此一舉反而適得其反，引起開發們的反感。

對於團隊同學，專案的資訊沒有做好共享。前期的產品目標沒有講透，大家沒有很好的共識，資訊不透明，容易導致產品的不健康發展。產品上線後的資料和反饋，產品經理敝帚自珍，不和團隊分享，大家都感受不到產品的價值感和成就感，降低了積極性，就容易造成打工心態，團隊信任感和歸屬感缺失。還有的產品經理，產品有喜報時知無不言言無不盡，但是碰到處境不好就沉默是金。這在某種程度上是保護團隊，讓大家安心做事，實際上卻沒有真正地把團隊綁到一條船上，風雨同路。如果大家從別人口中聽到產品的消極訊息，那結果反而更差。

遇到問題，優柔寡斷，不敢決斷和擔責。作為專案的虛擬領導者，在產品需要作出選擇時，猶猶豫豫，想到天荒地老，沒有拍板的勇氣，最後蹦出一句：兩種方案都可以吧，你們看成本和風險來定。有時候因為被技術挑戰了需求，矯枉過正，後面的需求都不敢再提，只怕多生麻煩。沒有抱著產品負責人的心態來做事，擔心出了問題背鍋，所以總希望運營能夠擔保，技術能夠承諾，這樣就把壓力順勢化解了，責任不會找到自己。但真出了問題，大家通常第一個罵的，還是產品經理，這種做法只是自我安慰而已。

以上種種詮釋了專業的產品經理行為，與經驗無關，大家切記避免。最後，都說評價一個人靠不靠譜，就看是不是“凡事有交代，件件有著落，事事有迴音”，其實產品經理也是一樣。