點擊查看第一篇：產品經理5點工作經驗總結

做產品掉過很多坑，但重要的是一個坑不能掉兩次。

思考問題的全面性

如果要對一個功能進行改動，一定要把功能前后的流程想清楚，要留意這些改動會不會影響到別的部門或團隊（利益）。比如有個功能叫「意見反饋」，基本每個 App 都會有這個功能，如果把這個功能入口放的層級淺一點，那么用戶反饋量會增加，增大了處理這些反饋的同事的工作量；如果把入口放的層級深一點，那么用戶反饋量會減少，降低了處理這些反饋的同事的工作量。與之對應的，如果把意見反饋功能的體驗優(yōu)化得很好，則降低了用戶反饋問題的門檻，反饋量將增加；如果體驗不做優(yōu)化，用戶提交問題的門檻較高，反饋量減少。

說的再簡單一點，一個功能的改進也許我們覺得對用戶的體驗會非常好，但是可能會遭到其他部門的反對。所以思考問題一定要全面：用戶輸入的信息最后會輸出到哪里？輸出完后誰去對這些信息進行處理？他們是怎么處理這些信息的？這些都要考慮清楚。

產出物的一致性

版本迭代，首先產品經理產出 PRD，接著交互設計師產出交互稿，然后視覺設計師產出視覺稿、標注、切圖。PRD里要寫清楚每個功能點，包括文案、標點符號等細節(jié)，然后要保證交互稿的內容是和功能點保持一致的，視覺稿的內容要和交互稿保持一致。我們都知道一個很古老的游戲叫「COPY 不走樣」，要求一個一個人往下傳的時候盡量不要出現「走樣」，這個游戲規(guī)則比較難，看了一兩遍就不能回頭繼續(xù)讓對方做動作了，但是產品不是，產出物就在那邊，沉下心來去比對、去思考。

產出物的不一致，出現的問題就是在技術評審完開始進行開發(fā)時，工程師不知道該以哪個為標準，然后又要返工。當然出現的問題不僅僅是這一個方面，還有很多其他問題，不多展開。產品經理要對整個流程負責，交互稿的問題，視覺稿的問題，都是產品經理的問題，是產品經理的工作沒做到位。產出物是否一致是衡量一個產品經理有沒有入門或者說基本功是否扎實的重要因素之一。

需求PK的邏輯性

需求評審會上，經常會出現各種PK，一個人認為這樣好，另一個人認為那樣好，然后互不退讓，爭得面紅耳赤，這其實是不明智的。評審這個功能到底行不行，把你的道理擺出來，把你的方案拿出來，別人憑嘴撕逼，我們憑行動。

回答一個功能需求到底如何，只要思考以下三個問題：做什么？為什么做？怎么做？三個問題分別對應著產品方向，用戶場景，解決方案。把這三個問題想透徹了，PK時可以多自信一點了。

需求評審會中需要保持獨立思考，不被帶到溝里去。因為難免會碰到一類人他們喜好使用強盜邏輯去說服別人，這個時候要能快速分辨出來，然后進行制止。比如二分式思維，認為不是A就是B；使用了什么類型的論據，是否有來源；有沒有在句子中使用帶有觀點傾向性的形容詞……這些都要千萬注意。

本文由@沈曉馬?原創(chuàng)獨家授權發(fā)布，本文禁止在本人未允許的情況下，任何形式的全文轉載和部分轉載。若您喜歡本文，請分享本文的鏈接到您喜歡的平臺。