產品經理需求來源包括哪些？
產品需求來源分析
一般情況 下：
- 各種渠道來源的用戶反饋
- 客服電話反饋
- App端戶的用戶評價、意見與建議
- 微信公眾號、微博等各種渠道的反饋
- 各種業務渠道的需求
- 領導建議
- 業務建議
- 運營建議
- 技術建議
- 。。。
- 主動調研得來的需求
- 用戶調研
- 用戶問卷
- 通過自主分析得到的：
- 競品分析：
- 本品分析：
- 業務分析
- 市場分析
- 公司戰略目標所得來的需求
基本是能想到的就這麼多。
主要有這些來源：
- 老闆的要求；
- 公司高管的要求（CEO，VP和各部門的總監）；
- 甲方的要求；
- 用戶反饋的意見；
- 產品經理自己的意見（發現了產品的問題，或者按計劃升級增加功能等等）；
- 產品經理揣摩出來的用戶的意見（不用調查，產品經理自己推測出來的）；
- 競品的壓力（別人都有這個功能，我們也要有）；
- 產品經理工作績效的壓力（做點事情，也算是幹活了）。
主要就這幾個吧。
其實，大部分的需求，都是來自於別人，而並非產品經理自己。
所以，產品經理提出來的需求，程序員一般都要做。因為，這不是產品經理的意見，而是公司里某些大人物的意見。
其實這個問題要看你是做哪一方面的產品經理。
為什麼這麼提？有些產品是面向內部運營的，有些是面向C端用戶的，有些是負責財務的，有些是做小程序的，不同緯度的產品經理存在著一些差異性。
幾個共性的來源，這些我理解無論是做啥的產品都會遇到。
1、業務方，根據自己的理解或者觀察覺得應該要怎麼做，這個叫做「業務需求」
2、上級領導，老闆們根據自己的信息源和對市場的判斷或者自身管理的需要，要求要怎麼做，這個叫做「老闆需求」。比如做報表系統
3 、產品經理，通過體驗產品，數據觀察，場景觀察等方式找到不足之處，制定迭代計劃，這個叫做「產品需求」
幾個特性的來源，有些產品會遇不到
4、 用戶留言或者意見反饋，用戶會通過公開的微博發帖，系統自帶的社區或留言模塊，或者通過電話或文字客服表達不滿，這叫做「用戶需求」
5、法律或者行政策要求，有些行業處於政策監管之下，需要根據政策調整變更需求，叫做「法律政策需求」。比如平台電商需要披露賣家資質，財務需要合規不能搞「二清」等
6、系統方的政策、性能或者其他變化，比如IOS新款手機屏幕變大了需要做適配，比如小程序總包上限調整到了12M，產品經理需要根據這些做對應的產品方案調整，這些叫做「系統需求」
7 、競爭對手的臨時變化，比如競爭對手領先推出一款功能，市場反饋很好，那麼可能需要及時跟進，這個叫做「競對需求」
其實產品經理的需求池像是哆啦A夢的口袋，可以把你接收到的所有需求放進去，以便需要的時候隨時找出來用，以免發生轉身就忘的烏龍。甚至需求池有時候就是產品經理的擋箭牌，當需求過多沒有時間處理時可以通過合理規劃對緊張工作進行緩衝，所以管理好需求池是產品經理的入門功課了。
01
需求基本屬性
當你接收到一個需求，首先要對需求的信息進行一個簡單的梳理
需求來源
需求來源一般分為外部臨時需求，常規需求和運營需求
外部臨時需求：用戶反饋需求、老闆/甲方爸爸業務需求
常規需求：業務實際需求（如通過競品分析或用戶挖掘出的需求），第三方合作需求，項目版本需求，產品自身優化需求
運營需求：運營活動需求，運營推廣拉新需求等
根據需求提出方判斷需求來源的類型，可以寫的盡量直接簡單
需求描述
用戶在什麼樣的場景需要解決什麼樣的問題就是需求的描述，是需求評審的重要依據，不需要太詳細，說清楚要解決的問題，以及為什麼會有這樣的問題
02
需求評估信息
梳理完以上需求的基本信息，就可以對需求進行簡單評估了，主要包括以下幾方面:
需求類型
需求類型分為：新增功能，優化體驗，bug修復，內部需求等
需求優先順序
需求類型分為：新增功能，優化體驗，bug修復，內部需求等
優先順序可以按照緊急重要的四象限法則或者kano模型來區分，將緊急重要或用戶期望度高列為高優先順序，優先順序從p1-p8(我參考職級,hiahia)排序
緊急重要四象限法則是時間管理的工具，按照重要和緊急程度分為四個象限：
緊急又重要：包括一些突發性的但必須解決的事件，比如客戶投訴，危機事件，例如重大系統漏洞等等
重要不緊急：比如關於運營的活動規劃，提高用戶體驗的一些需求
緊急不重要：計劃之外的工作，如老闆要求必須滿足的奇思妙想等等
不緊急不重要：就是一些對用戶來說無關痛癢的需求，或者做了對目前版本沒有實質性幫助的需求
對於緊急又重要的事情當然是優先順序最高去做的，那麼我們關注的是到底應該先做緊急不重要的，還是重要不緊急的呢？管理學泰斗德魯克說「我們需要記錄時間，然後分析時間，最後才是安排時間」，時間是有限的，所以把有限的時間用來做重要的事，「要事優先」原則，做產品也一樣，好的產品不在於你做了多少功能，而是把用戶真正需要的，對於用戶來說重要的事專註做，用心做，做到極致。
kano模型
與四象限法則不同，kano模型是按用戶的滿意度和功能完善程度劃分：
必備型需求：當優化此需求，用戶滿意度不會提升，當不提供此需求，用戶滿意度會大幅降低
期望型需求：當提供此需求，用戶滿意度會提升，當不提供此需求，用戶滿意度會降低
興奮型需求：用戶意想不到的，如果不提供此需求，用戶滿意度不會降低，但當提供此需求，用戶滿意度會有很大提升
無差異型需求：無論提供或不提供此需求，用戶滿意度都不會有改變，用戶根本不在意
反向型需求：用戶根本都沒有此需求，提供後用戶滿意度反而會下降
前三種需求根據績效指標分類就是基本因素、績效因素和激勵因素。我們做產品設計時，需要盡量避免無差異屬性、反向屬性的需求，至少做好必要屬性、期望屬性，努力做魅力屬性的需求。
需求優先順序
根據需求描述和場景初步判斷該需求所屬的產品模塊，優化現有模塊或增加新模塊
版本節點
該需求是否需要對當前產品的現有功能進行版本迭代，小需求只涉及簡單頁面交互的可能不需要，如果需要版本變更則記錄新版本號
需求負責人
指定產品團隊的某一個人負責的需求，需要負責從記錄需求到產品上線的一系列工作和責任
需求添加時間
記錄添加到需求池的時間，也就是確認需求的時間，可以知道需求從確認到上線的生命周期
03
如何維護需求池
整理完所有信息就可以對需求池進行更新了，對新需求要及時補充和維護才能發揮需求池的作用，那麼如何維護需求池呢
誰來維護需求池
這也就是為什麼上邊說到一定要指定需求負責人了，通常產品團隊每個人負責的模塊都不一樣，那麼每個人接收到的需求也是不一樣的，需求的接收者也就是記錄者，需要先把接收到的需求來源和描述簡單記錄下來，由產品團隊商議由誰來負責這個需求，那麼負責需求的人就要負責該條需求整個流程的更新和維護
需求池維護和更新流程
需求的更新
需求是變化的，需求的內容會變，有可能甲方爸爸上午說的需求下午就會改變；需求的狀態也會隨著工作的進行改變
待確定：新接收的需求，基本信息已經整理完成
需求評審中：正在準備需求評審的需求
待開發：需求已經評審完畢，但還沒有開發
開發中：需求已經進入開發階段的
已上線：開發完成已經上線的需求
任何需求的變化都要及時更新。
在管理需求池時，把同一模塊的需求進行歸類整理，這樣在處理該模塊時可以一次性解決，提高工作效率。需求池的信息可以根據實際業務擴充或刪減，我的需求池還包括很多跟蹤信息是需要研發和測試更新的，方便我及時了解項目進度和重要里程碑情況
04
需求從需求池中取出的規則
指定需求取出
需求提出方指定要做的，需要在當前版本實施的內容，比如針對某些需要配合目前公司運營活動的需求
按優先順序取出
由產品經理按既定優先順序取出，將緊急重要的需求或用戶期望值較高的需求取出實施需求評審
小需求取出
通常是一些修復型，細節性的需求，成本較低的 用來在各個版本的研發空餘時間 植入進去，就像搭順風車，比如一些提升用戶體驗和性能的小功能
05
如何排出廢棄需求
當一個階段內需求池的內容到達一定容量時，需要定時對產品需求池進行整理和篩選，重新將需求分門別類，將沒有實際應用場景的需求，用戶無關痛癢的需求，反人類的需求，明顯不符合公司戰略方向的需求，定時展開需求評審會議，進一步去明確真實需求，刪除沒有必要的需求
以上便是我對需求池管理的一些想法，一個完整的產品是由一個又一個需求組成的，做好需求池管理，對產品之路收益良多。
對了，想要了解更多項目管理解決方案可前往CORNERSTONE。
1、業務方
2、運營人員反饋的需求
3、領導：很多公司大多數情況下，領導是需求的最大來源了
4、競品對標
主要的是業務，大家對業務理解的不同，造就了需求的多元性，但核心的卻很少，需要不斷確定。
其他的都是基於業務產生的，或者說是衍生的需求點。
如果你覺得有幫助的話，可以關注我的公眾號【hellojikuair】，在這裡我依舊會耐心的幫你解答問題。這裡還有150G產品經理相關的學習資料，可各取所需！
用戶反饋，業務方需求，數據分析後的優化需求，老闆需求
一：公司內部需求：
頭腦風暴——團隊成員，老闆，市場經理以及一些有深刻見解的人，最好有著不同經歷和學科背景，這樣更容易產生更多的創新點。一群人圍繞一個特定的興趣領域產生新觀點。
用戶場景分析——確認主要用戶群體，模擬不同場景用戶使用情況，發現一些需求。
從公司業務方向挖掘需求——從公司業務方向，老闆，市場客服等渠道獲取需求。
二：用戶提出的需求
實地調研——耳聽為虛，眼見為實。大多數的場景分析與頭腦風暴的出來的需求點，都是無中生有，不切實際的。當我們在某個需求拿捏不住時，不妨去實地看看。
問卷調查——在調查問卷之前，必須先弄明白調查的目的，再根據目的發到相關文員手中。一般都是線上線下問卷同時進行。
用戶訪談——用戶訪談並不是說每一個用戶都需要去交流溝通，一般都是社區找到自己目標用戶，也可以找競品用戶來經行溝通交流。訪談對象最好選擇高質量，善於表達溝通或者在某領域資深，對產品要求高，有話語權，領導權的。除了線上訪談，我們也可以約一些目標用戶線下溝通，不局限於辦公司，可以咖啡廳，這樣交流更輕鬆。
三：競品需求
競品分析是需求挖掘最常用的方法。競品也是經過重重升級換代得出產品，，我們可以從產品的市場定位，盈利模式，核心功能以及競品的用戶反饋來經行分析。正所謂」取其精華，去其糟粕。「
四：網路信息
一個產品經理不可能閉關鎖國，應該實時關注信息技術的更新。網路產品信息資源有許多。例如：人人都是產品經理社區，微博，知乎，百度等社交軟體平台。都是」百家爭鳴「之地，各種潛在用戶在社區發表自己的想法。
五：產品自身需求
用戶反饋需求——用戶反饋是用戶使用產品進行反饋的信息，是用戶直觀的對產品的評價與建議。產品經理可以通過用戶反饋了解用戶的想法和期望。每個問題都有可能隱藏著相應的需求。
用戶或監管。
老闆給的需求，競品抄的需求，用戶反饋的需求，團隊內提供的建議需求，迭代產生的優化需求，都屬於用戶需求，要讓這些最終變成用戶需求。
監管是另外一條重要的需求來源，簡稱甲方。
推薦閱讀：
