成功的產品和失敗的產品最大的區別是能否很好的滿足需求
廣義上的需求：渴了要喝水，餓了要吃飯狹義的需求：則是經過篩選后留下的對特定產品服務特定場景／用戶有正面影響的訴求和建議
需求的來源（即特定場景／用戶）
需求評審會：請整個公司各個部分的同事來一起收集需求，描述需求，這種方式的優點是不必事必躬親地去體驗，適合多人協作場景中使用，但是缺點是會需要占用一部分時間來互相溝通需求，這種溝通的過程，就是需求評審會。
需求的獲取渠道
1）老板提出的需求；
2）用戶直接反饋的需求；
3）公司內部同事反饋的需求；
4）通過數據分析／問卷調查得到的需求；
5）自我驅動產生的需求。
6. ? “老板提出的需求其實是基于老板對產品的理解，往往很難拒絕，但是如果對于實現產品價值有很大的影響，必須盡自己所能說服老板。” ? 突然想到行秀面試的時候，那個老板也是這樣問我的，然后好的回答是：1）用數據分析來說話，盡量勸服，查各種資料去看 ?2）引入第三方 ?3）還是要堅持，那就是要準備收拾殘局，把傷害值降到最低，想好一切補救方法，后面其他的事情再說
7.需求管理方法：
單項需求卡片：規范化地收集需求，避免很大一部分僅僅是“拍腦門”想出來的需求
建立／維護需求池：需求池中的需求，其實是經過pm閱讀需求卡片后，“翻譯”成可以被開發人員直接理解的需求，這個必須由pm親自把控，以免造成誤讀
需求更近：
1）需求池中的需求如果在需求評審會上被拒絕或暫緩，需要在備注中說明情況，
2）也必須通過郵件的方式告知提出需求的人（我認為這是一種尊重，這樣才會有人愿意不斷配合你提需求），切忌石沉大海一般毫無反饋；
3）如果需求已經進入開發隊列，產品經理則需要不斷跟進需求的狀態直到開發完成，通過需求卡片中規定的驗收標準驗收產品，這里也同樣切忌只管頭不管尾
4）產品上線后要持續對新的改動進行觀察，隨時做好版本回退的準備。
8. ?在需求池中有這么兩個可以幫助產品做需求決策的參數：一個是優先級，一個是性價比。
優先級來自于需求卡片的描述，經過對需求細致了解后作出的感性判斷（這里的感性只是相對性價比而言）；
性價比則比較量化，可以通過價值／開發量進行計算，性價比越高，理論上越值得做。
開發量可以通過開發時間來預估，價值則需要參照產品現階段的OKR（Objectives and Key Results即目標與關鍵成果法）來進行評估，比如說某功能需求可以完成現有OKR的50%，那么該需求的價值可以定為50，開發量為10個story，則性價比為50/10=5。
作業：遵義那家VR體驗店
