最近做了一些需求，做需求的過程中遇到了一些問題，而最主要的問題在於產品邏輯，於是乎被老大安排推薦一本書《簡單邏輯學》，目前有時間就會抽空看一些內容，今天只是想總結一下最近的一些內容，產品經理最重要的核心競爭力其實是產品的思維邏輯，而思維邏輯的培養在於深度思考，比如接到一個需求應該怎麼分析，分析哪些內容等等，這些都需要思考，深度思考的能力對於每個人而言都是十分重要的，無論你的工作崗位是什麼。
最初接觸需求的時候，我往往會忽略思考或者分析，作爲執行者，拿到需求就做，不考慮任何因素，慢慢地我感覺自己變成了一個執行的機器人，沒有思想和靈魂，一段時間後，我發現這種狀態毫無意思，沒有什麼意義，而且最關鍵的是在需求評審過程中，因爲自己沒有深度思考或者說事前剖析很多場景，很多方面壓根沒考慮清楚，在開會過程中，被技術瘋狂DISS，最終導致整個需求進度延後。
後來我進行復盤總結，分析導致這種結果的根本原因-缺乏深度思考的主動性，
當我們手頭上有好幾個功能，需要判斷優先級時，我們首先要做的第一件事就是思考：
該功能給用戶帶來了哪些價值？
功能的背後要解決的真實問題是什麼？
用戶期望是怎樣的？符合產品的戰略目標嗎？
有沒有其他緊急重要的問題亟待解決？
只有符合用戶期望和產品目標的需求才是值得做的，纔是當前需要做的。
當我們確定好了某個功能時，我們其次要做的就是事前剖析，分析思考很多種可能性：
這個功能成功後的場景是什麼？出錯的場景有哪些？有沒有對應出錯情景的解決辦法？
有沒有其他風險？是否會影響其他功能？
當影響其他功能時能否迅速響應立即處理？
有哪些人會用到這個功能？是否要區分不同用戶屬性顯示不同內容？
是否要專門設置後臺進行管理？等等儘可能延申一些場景進行分析，並且在寫好需求文檔之後進行邏輯梳理，自己要完全在腦海裏演練一遍實際場景，儘可能站在用戶角度模擬場景，必要的時候，可以通過思維導圖和流程圖輔助梳理整體邏輯，以便及時發現不足之處從而改進。
當我們確定好最終內容之後（需要仔細檢查自身文檔有無邏輯問題或者描述不夠精簡）纔開始召開需求評審會:
在會議上向技術人員介紹時，我們首先應該闡述此次需求目的以及解決的問題或者說想要帶來的價值，其次纔是我們的文檔內容，我們在做每個功能時，必須要明確功能的價值，在開會過程中，儘可能表達流暢，思維嚴謹，爭取第一次開完需求會之後就可以讓技術人員給開發週期，保證功能儘快落地。
當我們將某功能上線之後，我們需要對某功能進行結果驗證:
通過用戶反饋或者埋點的相關數據去分析此功能帶來的價值，若該功能未能到達預期，則需要針對性分析出問題的是哪個環節，從而進一步優化迭代。
無法量化的工作是無意義的，憑感覺行事是不長久的。優秀的產品經理對於自己要做的功能，有着明確的結果預期。做產品的過程就是不斷的驗證自身想法的過程，而對結果的預估就是很重要的能力。
今日覆盤結束，我們下期再會，嘻嘻，歡迎大家在下方留言提建議~~~