1、正經需求的**有兩個：使用者和資料。其中資料也是使用者使用產品產生的，所以歸根結底一條結論：需求**於使用者。
2、上述結論對天才無效。比如賈伯斯，人家是先把產品做出來，然後告訴使用者：你有這個需求！然後使用者竟然還普遍認同...
3、有人會說，競品也是需求的重要**。好吧，既然你這麼大言不慚的把抄競品擺在桌面上，我就告訴你，這類需求來自競品的使用者。
4、不正經需求都是拍出來的，比如老闆一拍大腿、自家產品經理一拍腦門、競品產品經理瞎拍腦門等等…
5、定義需求的兩要素，其一是使用者，這裡的使用者是廣義的使用者，不止包括線上產品的使用者，還包括公司內部的市場、運營、客服等等…
比如給客服開發個工單系統、給運營開發個活動管理系統，這裡的客服、運營就是對應的使用者。
6、定義需求的第二要素是場景，不同使用者在同一場景下需求是不同的。比如——；同一使用者在不同場景下需求也是不同的，比如——
使用者+場景才能定義乙個完整的需求。
7、產品經理把自己當成使用者yy出來的需求，大多是偽需求。因為：在年齡、閱歷、興趣、收入、受教育水平等等多個方面，產品經理和使用者都是有差異的，即使處在相同場景下，產品經理也很難成為真正的使用者。
8、yy需求這事兒，c端產品經理常幹！b端產品經理想幹，但yy不出來...
9、調研需求時有乙個常見的誤區：如實記錄使用者想要的產品功能。
人們總是會下意識的說：我想要一匹更快的馬。這其實是乙個建立在使用者自身知識和經驗基礎上的解決方案（產品功能）。
產品經理要做的是挖掘背後的原始需求：想要更快的從a地到b地，然後你才能給使用者做出他心愛的小摩托。
10、不要聽銷售/客服轉述的使用者需求，轉述一定失真！一定直接從真實使用者處獲取。
11、需求有真偽之分，偽需求肯定不會做；真需求，也不一定會做，還要看需求覆蓋使用者量、使用者使用頻次、迫切程度、付費意願等等…
說白了，優先順序p1、一路綠燈、火速上線的需求，要麼能帶動產品增長，要麼能提高產品營收。
12、帶有政治任務的需求無視上條規則，優先順序p0！
13、如果乙個產品上線了乙個很奇怪的功能，跟使用者需求毫無關聯，這背後一定有老闆的死命令和產品經理的罵娘聲。
14、眾所周知，「已經記入需求池了」是不做的意思。先錄入需求池，優先順序頂多p2，而每次迭代時，p1級的需求都排不開。
真正緊急的需求，有往需求池裡記錄那個時間，業務流程圖都畫好了。
15、需求管理的第一課：學會拒絕需求。大多數產品的需求管理是混亂的，本質原因是多數產品經理沒什麼話語權。
16、產品經理最痛苦的事兒莫過於在開發過程中改需求，比這還要痛苦的是在測試過程中改需求。
需求變更的原因很多：原始需求有誤、不清晰、不完善；業務變化、環境變化導致需求變化；想出更好的解決方案等；
在改需求這件事兒上，其實產品經理的牴觸情緒比開發更強烈，但我們往往是先說服自己再去跪求開發。
就這點來說，產品經理簡直太偉大了！快，給自己點個大大的贊！
也，順便給本文來個一鍵三連吧
— end —
◆◆ ◆
推薦閱讀
產品經理才能看懂的14個瞬間
用產品經理思維寫簡歷2.0
2020產品經理薪資大起底
從蓋棺到詐屍，公尺聊只用了8天
為什麼被噴的總是產品經理
人生需求的七個層次（馬斯洛）
生理需要 安全需要 歸屬與愛的需要 尊重的需要 求知需要 審美需要 自我實現的需要。假如乙個人同時缺乏食物 安全 愛和尊重，通常對食物的需求量是最強烈的，其它需要則顯得不那麼重要。此時人的意識幾乎全被飢餓所佔據，所有能量都被用來獲取食物。在這種極端情況下，人生的全部意義就是吃，其它什麼都不重要。只有...
馬斯洛模型看待網路的發展
最近一直在思考怎麼將計算機網路整個內容串起來，為什麼網路的發展歷程是這樣的？自己也一直認為學習網路知識最好的方法是基於網路發展歷程角度來學習，網路發展的每乙個階段都會遇到乙個問題，相應地會有對應的解決方案來解決這個問題，但同時也會引入新的問題，如此反覆，螺旋式上公升，每乙個問題的解決方案也就成為了乙...
校車幼童慘劇 馬斯洛需求層次理論和移動應用
8 月1日，西安兩歲半的幼童涵涵在上學時候被幼兒園校長和老師遺忘在接送的汽車上，在炎熱天氣下經過7 個多小時密閉車廂內的 炙烤 又乙個幼小的生命告別了她尚未熟悉的世界。這已經是近兩月來的第四起校車內幼童窒息死亡事件。含苞待放的花蕾過早凋謝讓人扼腕嘆息，幼兒園工作人員的懺悔並不能減輕痛失愛子這濃重的悲...