在工作中，挖坑也成了產品經理所具備的基本素養之一，所謂“不挖坑，不產品”！畢竟，這是每個產品經理都會存在的，但具體的都會有哪些坑，以及如何更好的規避呢？
產品經理工作中常見問題
1
成了純粹的傳話筒
可能是源於對產品經理這一工作神聖不可侵犯的誤解，在剛接觸產品經理工作之初，急於有實際的需求來執行。當接受到其他部門的需求後，內心深處想著終於要幹一出天翻地覆的大事來了。
於是乎，火急火燎完全不經過大腦的來直接執行，壓根不去分析功能本身背後涉及的業務、邏輯、什麼角色在使用等等。
最終，成了一個純粹的毫無主張的會話筒。
2
重功能輕邏輯
由於對公司核心業務缺乏認識和了解，在接受到需求時，往往側重於需求本身對外的表現形式，比如：視覺、交互這些，但往往忽略了最為核心的需求本身-用來解決怎樣的問題。
在這此情況下，往往把頁面做得天花亂墜且內心對自己佩服的五體投地，但上線後卻發現用戶壓根不買賬。
3
有評審無跟進
產品經理都知道會有需求評審，拉上一大幫人開會開會開會。但貌似需求評審以後，所有的事情就已經結束了。後續的更細緻的跟進呀優化呀之類的，和自己完全沒關係一樣，最終導致研發過程中存在大量的問題。
4
上線後就撒手不管了
終於上線了，終於上線了，終於上線了。感覺上線了就解脫了一樣，再也不願回頭正眼看一下自己做的東西，有BUG也不管直接拋給研發人員，真是應了一句老話：“分手了就別再找我”。
產品經理應該如何做，才能輸出更好的產品
1
接到需求後，搞清楚來龍去脈
當產品經理接到需求後，請列出以下幾個問題點，並找提需求的同事進行溝通確認，確認無誤後再內部進行溝通確認：
此需求是基於怎樣的背景提的-核心的問題點是什麼；
原來的解決方案是怎樣的，原來的解決方案存在什麼樣的問題；
新的解決方案是怎樣的，新的解決方案是否能夠解決上述的問題；如果不能，是否有其他的解決方案；如果沒有好的解決方案，不建議操作；
如果確認可行，那麼此功能是基於原有系統哪個流程的，這個流程是誰操作的，操作人對此的使用感受是怎樣的；
除此之外，還關聯哪些流程，所關聯的流程是否涉及到其他同事操作，如果是那麼他們對此的使用感受是怎樣的；
找每一個關聯人確認-每一個具體的細項，如果涉及到資料、那麼要確認都需要哪些資料、資料哪兒來到哪兒去，並站在整個系統的角度上來考慮此功能如何更好的實現功能；
同時，這裡也有可能涉及公司之外的需求，就更需要確認需求在傳達過程中的精準性。
2
確認需求後，畫一個清晰的流程圖
需求確認後，針對需求做一個清晰的流程圖，有幾個核心：
基礎的全局流程圖；
所變更的需求具體都在流程中的哪一些節點上會有體現，具體體現的內容都有哪些；
站在操作人的視角上再做一個基於操作人的流程圖，比如我是風控，那麼我的流程就是-收到審批的單-審批，然後流轉到下一個流程；
流程中存在哪些潛在的異常情況，這些異常的情況出現的話要如何處理。
3
評審並全程跟進
在需求評審後，還需要重點做到以下幾點：
產品經理與研發人員在評審之外，進行一對一的更為細節的溝通，包括每一個正常或異常的流程，以及所涉及的每一個更細微的細節，並從中確認需求及實現方案；
在研發週期內，每一天都需要進行一對一的溝通和確認，瞭解當前研發過程中存在的問題並溝通解決；
提測試後，產品經理在每一個測試周期均需第一時間進入體驗，每個週期至少要測試3次以上；
上線後，第一時間在正式環境進行操作和體驗，確保線下也無誤；
提交至需求方進行體驗，並收集體驗過程中存在的問題；
在對接群裡，收集所有使用者所反饋的問題，以周為單位進行輸出至研發側；
研發同事以周為單位對所反饋的問題進行內部的梳理，並提出後續過程中好的解決方案；
依次循環。
4
以周為單位收集並溝通存在的問題
在上述的基礎上，進行定期的問題溝通和討論，形成良好的正向解決途徑：
產品經理以周為單位收集所負責的問題，所有的問題，並彙總輸出至研發團隊；
研發團隊在收到彙總後，內部先進行溝通和討論，確認後續的優化措施；
產品+研發團隊集中進行問題的溝通，確保後續產品質量的提升。
所述一切，均為產品經理最為基礎的素養。很多人可能不屑一顧，不過正如我《瞧不起的基本功，築不起的摩天樓》裡所寫的：
咱不過是個普通人罷了，還是做好手頭上的事情。
最好，如何做好呢？
無非是—數量上：日復一日的極度無聊的重複；思維上：日復一日的極度無聊的思考。
最後以《失控》第三章有心智的機器第三小節眾愚成智中的一段話結束：
先做簡單的事，學會準確無誤地做簡單的事。在簡單任務的成果之上添加新的活動層次，不要改變簡單事物，讓新層次像簡單層次那樣準確無誤地工作。重複以上步驟，無限類推。
閱讀更多 產品會 的文章
