起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品工作中需要避開的四大坑
產品經理在日常工作中會遇到很多坑，剛入行的產品經理尤其如此。只有掌握有效的方法來快速避開這些坑，才能讓產品工作更加得心應手。本文根據自己的產品工作經歷，總結了產品工作中需要避開的四大坑，希望能對大家有所用處。
1、誤把客戶需求等同產品需求
雖然常說產品經理需要去發現、洞察用戶需求，但是往往更多的是在對接需求。這些需求可能來自公司內部，比如運營的需求、市場的需求，當然還包括老板的需求；也可能來自公司外部，比如像在齒輪易創這樣提供技術解決方案的公司，產品經理所接的需求大多是來自客戶的需求。
那么問題來了？產品經理應該以怎樣的姿勢來對接需求呢？這里面就有我今天要說的產品第一坑：
誤把客戶需求等同產品需求。
無論是客戶也好，運營、市場也罷，他們所做的工作都是實現整個產品的第一步——提出需求。
但這個需求往往不是產品真實需求，產品經理常常被人詬病的一個原因就是被認為產品經理的工作很簡單——接到需求后畫畫原型寫寫文檔然后就是盯設計盯開發盯測試，好像沒有太多技術含量。
這種觀點對出現很值得我們思考：為什么產品經理們會給外界留下這樣的印象？我想可能和很多產品經理在需求階段就沒有深入地去判斷和區分客戶需求和產品需求有關。
“更快的馬車”的例子在互聯網界已耳熟能詳，但懂得道理并不代表能夠實際運用到工作中去。正確判斷客戶需求和產品需求需要多問自己兩個問題：
- 客戶需求的本質是什么？
- 這個客戶需求的目的是什么？
舉個例子，假如客戶A想要做一款健身類APP，其核心就是通過領取任務—完成任務—領取獎品的方式來吸引用戶健身、提升產品的用戶活躍度和用戶黏性。并且客戶還提出完成任務就會給用戶發放特定的獎品并寄送給用戶。
面對這樣的客戶需求，產品經理當然可以順著客戶的需求去做，但希望能夠掌控產品的各位是不是也要從自己的判斷出發，梳理發現這樣的要求下真正的產品需求。
我們可以發現獎品實質上是一個激勵因素，而發放獎品的目的就是為了激勵用戶使用自己的產品，提升產品的各項數據指標。在了解需求本質的基礎上我們再來從產品角度思考這一需求：是不是一定要發放實物獎品呢？有沒有更好的實現方式能夠滿足這一目的？那么也許我們可以用現金紅包、手機話費、流量券等多種方式實現這一產品需求，而同時又大大節省了實物獎品所耗費的人員和物流成本。
當然以上討論并不一定是這一產品的最好實現方式，但卻是一個產品經理應有的思考。如果只是機械地接需求、實現需求，而不去深入思考需求本身，就無法發揮產品經理的真正價值。
2、被頁面主導而忽視流程
產品經理最”炫酷”的技能可能要屬畫原型了，這也是0-1歲產品經理會很熱衷于畫原型的原因之一。畫原型是產品經理的基本功，是將需求通過可視化的形式表現出來，將功能和其中包含的邏輯以簡單明了的方式呈現出來以方便確認需求和溝通。
但很多產品經理都會有這樣的感受，原型圖畫了一遍又一遍，跟其他PM過功能，發現很多問題，改；跟開發進行需求評審，發現邏輯漏洞，改；跟老板或者客戶匯報，不滿意，改。結果就是原型改了很多遍才能最終定稿。誠然其中會有一些修改是因為需求本身發生了變更或由于其他不可控因素而發生的，但是仍有很多修改問題來源于產品經理本身——忽視流程而被頁面主導往往是這類問題的根源。
畫原型最忌諱的就是一上來就直接畫圖，而沒有提前對功能的流程及其邏輯進行深入思考，這也正是初階產品經理常跳的一個坑。
這類問題往往出現在邏輯相對復雜的功能板塊，如果直接上手畫原型圖思維就會被頁面帶著走，頁面畫到哪想到哪，想到什么就畫什么。不能很好地從整個功能板塊的業務流程角度去思考問題，一方面會給自己埋下邏輯漏洞，另一方面修改起來也比較麻煩，更容易影響整個產品流程。
因此在畫原型圖之前可以花很少的時間先把流程圖給畫出來。流程圖，顧名思義就是用來表達流程的圖，可以使用各種工具，甚至可以手畫；表現形式也可以是多種多樣，只要能夠幫助你理清業務邏輯、想清楚完整流程即可。比如下圖是微信給好友發紅包的一個簡單流程圖：
這個流程圖看起來很簡單，畫出來甚至花不了一分鐘的時間，但是有了這樣一個流程圖之后我們就可以很方便地進行按圖索驥了。我們可以將原來一個完整的比較復雜的發紅包功能分成一個個連貫的小部分，從而逐一進行單點突破：
- 聊天界面需要有一個發紅包的按鈕，作為產品經理需要思考的就是這個按鈕怎么放，這個功能的使用的優先級如何？
- 需要輸入紅包的金額，那么金額有沒有限制呢？
- 需要輸入留言，留言是必填的嗎，要是用戶不想填有沒有默認留言？
- 要輸入支付密碼，密碼輸入完畢后要不要用戶再點擊確認？
解決完這些問題一個完整的發紅包功能就出爐了，在這個基礎上畫原型圖的話不僅會很快，后期也不需要頻繁修改。
重視流程、利用好流程圖這個工具，不僅能夠幫助產品經理們大大提升效率，減少返工，還會給別人留下一種靠譜的印象，避免成為別人眼中的”改圖”經理。
3、只會做加法不會做減法
0-1歲的產品經理們還在進行從用戶向產品經理的轉變，在設計產品時腦子想的更多的不是我這個產品或者我這個功能怎么樣最好，而是回想以前用過的類似的產品或功能都有什么東西可以套用。雖然模仿和參考本身不是壞事，但是作為一個產品經理需要去判斷什么樣的功能是當前產品更適合的。最難的永遠不是加功能，而是如何去減功能，而產品新人往往陷入加功能中無法自拔，反而會拖累產品的發展。
加功能之所以不難在于你永遠能夠找出理由來支持你加這個功能，而在眾多功能中要決定砍掉哪個卻很考驗產品人的能力。當我們談論減功能時，首先要明白我們為什么要減功能，我認為主要有以下三大原因：
（1）首先是產品定位的問題
要弄清楚自己這個產品的定位是什么，對于不符合產品定位的功能就應該果斷砍掉。
（2）其次是產品迭代的問題
互聯網產品與傳統行業在產品更新換代上有著顯著差異，傳統行業往往會幾年時間調研、設計、生產一款新產品，而互聯網行業遵循的則是快速迭代的精益創業理念，同類產品間競爭的往往不是誰更好，而是誰更快一步，只有快速迭代、快速試錯才能緊跟市場的變化。因此，面對如此快速的迭代過程，產品經理必須下狠心對功能動刀子。
（3）最后是資源的問題
因為資源永遠是不足的，即使在BAT這樣的大公司中資源也是短缺的。比起你想做的，你能做的往往會大打折扣。這里的資源涵蓋時間、人力、金錢等產品研發中所需要的各類資源，面對資源短缺的現實，產品經理只能將現有資源效益最大化，先做優先級最高的功能先把”孩子”生下來。
騰訊去年11月推出的輕聊版QQ——TIM就是一個減功能的好例子，因為TIM就是在手機QQ的基礎上增加功能和減少功能而成的。拿TIM舉個最簡單的例子，TIM1.0.1版本中雖然上線了在線協作文檔功能，但是只能進行最基本的文字編輯，之后在1.1.5版本中才加入了上傳圖片的功能。在移動端支持上傳圖片本身并不存在技術難度，那為什么在第一版本沒有做呢？
因為在線文檔編輯的實際使用場景在PC端，移動端只是PC端的一個補償，移動端文檔的主要使用場景是不在電腦身邊又需要及時查看文檔，而不是編輯文檔。所以在第一版本中TIM的產品經理們將上傳圖片的功能砍掉了。但這并不表示移動端上傳圖片就是個偽需求，相反它是一個可以提升用戶體驗的點，在產品迭代優化的過程中這個功能是值得做的。
要記住，砍掉一個功能并不代表這個功能不重要，只是因為同時有更重要的功能。對于一個產品新人來說，學會砍功能比學會加功能更加重要。
4、不會給PRD“減負”
撰寫PRD文檔也是產品經理的基本功，但是要把文檔寫好卻并不是一件簡單事。產品新人初寫文檔時往往不得要領會犯很多錯誤，而PRD里面的坑也確實不少，今天主要想給大家分享如何給PRD“減負”。
給PRD“減負”聽上去似乎很奇怪，難道PRD還會超負荷嗎？
當然，當你的PRD文檔有著大量重復內容或者需要用非常繁瑣的文字說明去解釋某一功能的時候，就說明你的PRD文檔需要減負了。因為撰寫PRD文檔是為了能更好地溝通清楚需求，如果盲目撰寫文檔、不給文檔減負以增強可讀性，不僅達不到提升溝通效率的目的，反而會讓看文檔的人深受其累。
那么如何去給PRD文檔減負呢？
我認為有兩個方法可以提供參考：
（1）用模塊化的思維來撰寫文檔
在一個產品中往往有在很多頁面中反復出現的板塊，比如一款音樂APP中的音樂播放板塊、歌曲列表、分享板塊等。產品經理在撰寫文檔時沒有必要每次遇到同樣的或類似的板塊都重復再說明一遍。
有同學可能會問，如果只是將那個板塊的說明復制粘貼過來，既不增加工作量，又可以使文檔更加滴水不漏，豈不更好？
答案是否定的，因為在撰寫文檔時我們仍然要緊繃用戶體驗這根弦。雖然這樣做對撰寫文檔本身沒有增加太多工作量，但是對于閱讀文檔的人來說，為了確保不遺漏信息卻要認真看每一句話，這樣無疑增加了文檔閱讀者的工作量。更重要的是當他們發現大段都是重復內容的時候內心一定是一萬頭草泥馬在奔騰。
因此對于這樣的內容，我們可以采用兩種方式來進行優化：在音樂APP的例子中，對于音樂播放這樣的板塊應該拿出來作為一個單獨板塊進行統一闡述，而對于歌曲列表這樣反復出現但本身又不復雜的板塊則只需要在第一次出現歌曲列表的時候盡可能詳細地說明清楚，此后再遇到同類型歌曲列表只需一語帶過。通過這樣給PRD文檔”瘦身”既能提升我們自己的工作效率，更能大大提升文檔的可讀性。
（2）善用流程圖
在一款產品中，往往會有一些比較復雜的功能，要么是功能流程長，要么是背后有著非常復雜的判斷邏輯。這種時候要想把這個功能表述清楚往往就需要花費很大的篇幅。而大篇幅的文字說明對開發來說往往不是最好的理解方式。且不說更有甚者，即使花了很大的篇幅也無法把問題表述清楚。而這種時候流程圖這種圖形語言就能夠提供很大的幫助。
拿最簡單的登錄驗證來舉例子，用戶輸入手機號和密碼后需要依次經過如下圖所示的五個判定，缺一不可。
如果用文字來表達這個流程：
流程圖是一種圖形化語言，相對文字而言不僅更加直觀，還更符合工程師思考問題的方式。通過將PRD中繁瑣的語言替換成流程圖我們不僅能給PRD瘦身，更有利于工程師理解和確認需求，降低溝通成本。
結尾
產品工作中的坑當然遠遠不止這些。在避開上述的四大坑的基礎上，初階產品經理還需要在工作中不斷總結自己所踩過的那些坑，只有這樣才能保持和提升自己的產品能力，打造出真正牛逼的產品。
-The End-
作者：張世健，初階產品dog。微信公眾號：齒輪易創（chilunyichuang）
本文由 @張世健 原創發布于人人都是產品經理。未經許可，禁止轉載。
而對于歌曲列表這樣反復出現但本身又不復雜的板塊則只需要在第一次出現歌曲列表的時候盡可能詳細地說明清楚，此后再遇到同類型歌曲列表只需一語帶過。———-這里的一語帶過要怎么帶呢
受教，寫得很好。