摘自人人都是產品經理
http://www.woshipm.com/pmd/1285764.html
1.成了純粹的傳話筒
接到需求以后，應該去分析功能本身背后涉及的業務、邏輯、什么角色使用、使用場景等等；
2.重功能輕邏輯
由於對公司核心業務缺乏認識和了解，在接受到需求時，往往側重需求本身對外的表現形式，比如：視覺、交互這些，但往往忽略了最為核心的需求本身---用來解決什么樣的問題
3.有評審無跟進
評審后就完事了，后續的更細致的跟進、優化忽略
4.上線后就撒手不管了
產品經理怎么做才能輸出更好的產品？
1.接到需求后，搞清楚來龍去脈
當產品經理接到需求以后，請列出以下幾個問題點，並找提出需求的同時進行溝通確認，確認無誤后再進行內部溝通。
1.此需求基於怎樣的背景提的---核心問題點是什么
2.原來的解決方案是怎樣的，原來的解決方案存在什么樣的問題
3.新的解決方案是怎么樣的，新的解決方案是否能夠解決上述的問題；如果不能，是否有其他的解決方案；如果沒有其他好的解決方案，不建議操作
4.如果確認可行，那么此功能是基於原有系統哪個流程的，這個流程是誰操作的，操作人對此的使用感受是怎樣的
5.除此之外，還關聯哪些流程，所關聯的流程是否涉及到其他同事操作，如果是那么他們對此的使用感受是怎樣的
6.找每一個關聯人確認---每一個具體需求的細項，如果涉及到資料、那么要確認都需要哪些資料、資料哪兒來哪兒去，並站在整個系統的角度上來考慮此功能如何更好額實現功能
7.同時，這里離也有可能涉及公司之外的需求，就更需要確認在傳達過程中的精准性
2. 確認需求后，畫一個清晰的流程圖
需求確認后，針對需求做一個清晰的流程圖，有幾個核心：
- 基礎的全局流程圖；
- 所變更的需求具體都在流程中的哪一些節點上會有體現，具體體現的內容都有哪些；
- 站在操作人的視角上再做一個基於操作人的流程圖，比如我是風控，那么我的流程就是-收到審批的單-審批，然后流轉到下一個流程；
- 流程中存在哪些潛在的異常情況，這些異常的情況出現的話要如何處理。
3. 評審並全程跟進
在需求評審后，還需要重點做到以下幾點：
- 產品經理與研發人員在評審之外，進行一對一的更為細節的溝通，包括每一個正常或異常的流程，以及所涉及的每一個更細微的細節，並從中確認需求及實現方案；
- 在研發周期內，每一天都需要進行一對一的溝通和確認，了解當前研發過程中存在的問題並溝通解決；
- 提測試后，產品經理在每一個測試周期均需第一時間進入體驗，每個周期至少要測試3次以上；
- 上線后，第一時間在正式環境進行操作和體驗，確保線下也無誤；
- 提交至需求方進行體驗，並收集體驗過程中存在的問題；
- 在對接群里，收集所有使用者所反饋的問題，以周為單位進行輸出至研發側；
- 研發同事以周為單位對所反饋的問題進行內部的梳理，並提出后續過程中好的解決方案；
- 依次循環。
4. 以周為單位收集並溝通存在的問題
在上述的基礎上，進行定期的問題溝通和討論，形成良好的正向解決途徑：
- 產品經理以周為單位收集所負責的問題，所有的問題，並匯總輸出至研發團隊；
- 研發團隊在收到匯總后，內部先進行溝通和討論，確認后續的優化措施；
- 產品+研發團隊集中進行問題的溝通，確保后續產品質量的提升。
所述一切，均為產品經理最為基礎的素養。很多人可能不屑一顧，不過正如我《瞧不起的基本功，築不起的摩天樓》里所寫的：
咱不過是個普通人罷了，還是做好手頭上的事情。
最好，如何做好呢？
無非是—數量上：日復一日的極度無聊的重復；思維上：日復一日的極度無聊的思考。
最后以《失控》第三章有心智的機器第三小節眾愚成智中的一段話結束：
先做簡單的事，學會准確無誤地做簡單的事。在簡單任務的成果之上添加新的活動層次，不要改變簡單事物，讓新層次像簡單層次那樣准確無誤地工作。重復以上步驟，無限類推。
#專欄作家#
楊俊，公眾號：最污運營（ID：zuiwuyunying ），人人都是產品經理專欄作家。原騰訊、新浪產品經理，近10年互聯網產品運營經驗。擅長用戶運營和用戶研究