起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理應該如何解決各種需求
編輯導語：作為產品經理，日常工作中少不了解決各種需求的時候，本文作者分享了產品經理解決需求的相關方法，根據自身工作經驗分析了解決需求的思路等，一起來看，希望對你有幫助。
A同學：啊好煩吶，公司其他部門每天怎么提出來這么多需求?。?/p>
B同學：真是無語！剛入職一周就要處理這么多需求，都是一些前幾個月沒有解決的需求都要壓在我身上了！
作為產品經理來說，每天會面對不同人員提出的不同需求，那么我們面對這么多的需求，我們是如何做判斷的呢，如何去整理歸納呢？
哪些需求是當下最應該解決的需求呢？以下我為大家去總結了一些個人的一些經驗供大家參考使用。
一、真、偽需求
需求可以分為真偽需求，真需求就是用戶真正的需要，比如：我們去商場買一條裙子，這個裙子很好看，價格對我來說也挺合適，那么我就買了這一條裙子，我的真需求就是這個夏天缺一條這樣的裙子。
偽需求就是，用戶有某種需求但在某種場合不好意思說出口。
同樣去商場買裙子，這個裙子很好看，很合適，但是由于價格太高，我不好意思說出來，那么一般就會說，這個裙子的顏色不好看，等等理由，那么這時，我提出的顏色不好看就是屬于偽需求了，我就是覺得價格貴，不好意思說出口，說出來了會讓人笑話。
所以產品經理需要對需求進行自己的分析整理，往往在工作中，用戶可能表達出來的需求并不是真實需求，我們需要對需求進行深挖，發掘用戶的根本目的是什么。
再去對照需求去實現相對應的功能，不然這些功能做出來也無濟于事。所以這里我也也想說，產品經理不是為了功能去做功能，要去看用戶為什么需要這個功能。
二、需求的收集、整理、分析三部曲
做過To C的產品朋友應該都知道，產品是更注重拉新、促活、留存、變現，產品的方向是更偏重于運營。
往往產品都是免費給普通大眾去使用的，產品的也比較容易上手去使用的，用戶的逃離成本也比較低。
包括盈利模式也是以流量變現、廣告變現為主。
To B的產品往往是面對于企業的，客戶使用往往是需要支付費用的，系統也是有一點的復雜程度的，需要產品經理等研發人員去培訓客戶，所以客戶的逃離成本也比較大。
盈利模式也是以買斷或收取年費等為主，所以在收集需求方面也會有一定的不同，偏重點也會有變化。
1. 收集
那么C端產品在0-1的開發時，前期需求的來源有很多方式：競品、行業分析報告、行業資深人士的訪談、用戶的問卷調查、公司內部不同崗位的頭腦風暴、甚至是老板的需求等等。
B端產品往往需求的來源會比較簡單：做外包就是甲方客戶為主導，通過對甲方公司的不同人群的狙擊訪談等方式，在這里需要注意的是面對不同身份的訪談需要注意方式方法。
系統是公司自己研發的，給內部去使用，需求的來源肯能更多的就是本公司的人員、老板。
那么在時間上外包項目也是比較趕工期的，肯能在時間把控上需要進行控制，自研的給公司內部使用的系統研發時間包括項目的排期可能會比較寬松，按部就班，哪一步出了問題就停下來去解決。
所以面對不同的公司不同的行業要講究收集的方式方法以及經驗。
2. 整理
根據以上的需求進行收集后，我們前期講究的是橫向收集，也就是收集需求不問對錯，注重收集需求的廣度以及數量。
在有了這么多的需求后，我們產品經理要做的是把他們都放在需求池里，在需求池里進行分析整理。
3. 分析
就是縱向分析，像一個T字形，對需求的本質進行深挖。那么剛剛提到過的需求池是什么呢？
就是把需求做定義，誰提出的、用戶提出的需求內容是什么、這個需求的底層需求是什么、以及運用Kanon模型把需求分為：必備型、期望型、魅力型、反向型、無差異型。
通過分析提煉出當下符合產品的版本、公司目前的情況的需求，那么我們在分析時需要分析需求的廣度（多少人需要的）、需求的頻率（用戶多長時間需要一次）、時間節點（哪個版本該上）、用戶的痛度（這個需求的痛點有多痛，用戶離開這個需求還能不能繼續使用產品）。
還有一些方法，比如馬斯洛需求原理等方式去對需求進行分層等等在這里就不細說了，感興趣的同學可以私信我或度娘一下。
三、需求落地
以上通過收集、整理、分析了需求之后，我們產品經理需要對需求進行落地，通過需求分析文檔、需求的優先級排表、去把用戶的痛點找到后，提出解決方案，把這些解決方案再去交給客戶、公司內部的技術人員去看、這里我經常是開一些需求評審會議。
通過會議的方式讓不同人員用不同維度進行需求的評定，這里我們需要組織和記錄、產出一些會議紀要，再根據會議的內容去修改需求，反反復復，一直到需求評審會議里找不到問題后，再進行原型功能的設計。
所有的工作一多了就會顯得一些枯燥無味，那么我們要學會找到方式方法去面對這些困難！知難而退，碌碌無為，只有因難而上，才能無堅不摧！
本文由 @汪仔6447 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
大多數的時候，需求文檔和原型是一起產出的，需求文檔修改幾遍，業務原型也需要反復修改，這來來回回的時間，都是算在需求建設周期之內的，現在的需求來了就是急活，沒有那么多反復確認的過程
根據每個業務的習慣、公司的流程、實際產品的情況而定，感謝您的意見~
知識點滿滿的文章，作者分享產品經理解決各種需求的方法非常適用。
感謝您的支持~