需求是每個產品經理日常工作都離不開的一部分，貫穿著產品的整個生命周期。

先來講一個小故事

一天，和朋友一起吃飯，互相問候了下最近正在忙的事情，我就把那時候正在做的產品需求管理的工作跟他大致說了一遍，沒想到朋友倒是挺能觸類旁通，說道，這不是和搭訕很像嗎？

我感到很意外，心想這哪能扯上什么關系。

朋友微微一笑，開始給我科普了起來：你看，如果把妹紙比作一個需求，是不是先得到妹紙多的地方去找需求？比如商場、咖啡吧、夜店……

朋友接著說道，當你來到商場，是不是已經算是采集到了很多需求了？下面是不是就要評估和篩選需求了？比如說妹紙旁邊有男性的，這個就大大增加了搭訕的復雜程度，因為有障礙，這種妹紙是不是就不在你考慮范圍之內了；而被你看上的，是不是就算是經過了評估篩選了的，那么你是不是就可以進行下一步的動作，上前去搭訕了。比如“你好，剛剛在那邊看到你……”這樣操作下來，你是不是就得到了自己想要妹紙的微信，可以愉快地進入下一個階段的發展了。

我默默地點了點頭，看著不遠處幾個姑娘亭亭玉立著，一下頓悟道，看來搭訕和需求管理一樣，都是產品經理的基本功啊。

……

當然，本故事純屬虛構，如有雷同，請撥打妖妖靈，接下來進入正文部分。

需求的本質

什么是需求？

需求是每個產品經理日常工作都離不開的一部分，貫穿著產品的整個生命周期，產品經理的招聘信息上也充滿了“做好全面的需求分析與管控”、“收集和挖掘產品需求”等這樣的字眼。營銷學之父菲利普·科特勒在他的著作《營銷管理》當中為我們界定了三個概念：

1.需要：某些基本方面沒有得到滿足而產生的不足或短缺的感覺

需要是指人們對某種東西感到缺失的一種心理狀態，比如餓了想吃飯，困了想睡覺。身為人本心理學中流砥柱的馬斯洛童鞋早早就對人類需要的層次進行了分級，1954年，出版了影響深遠的巨著《動機與人格》，書中系統地闡述了著名的“馬斯洛需要層次理論”。他認為人類的需要層次有高低不同，低層次的需要是生理需要，向上依次是安全需要、愛與歸屬、社交的需要，再上去是尊重和自我實現的需要。當人類的較低需要得到滿足時，就會開始追求更高一個層次的需要。

2.欲望：想得到基本需要的具體滿足物的愿望

與需要不同，欲望有明確的指向性和選擇性，比需要更加具體。比如，當你對某個女生有好感，于是產生了想要和她進行交往的欲望（注意這個時候不是模糊的社交需要了，而是具體和某一個人社交的欲望）。但欲望又是建立在不同的社會經濟、文化和個性等基礎之上，對個體而言是具有個性的一件事情，比如一個美國人餓了想吃漢堡、薯條，而一個中國人餓了則想吃米飯和菜肴。

3.需求：需求是對于有能力購買并且愿意購買的某個具體產品的欲望

比如特斯拉作為這個星球上最豪華的智能電動車，產品經理想必都在朝思暮想。但對于買不起特斯拉的人來說，他們對特斯拉的需要只是一種欲望，因為他們不具備購買能力。

簡單梳理一下，會發現在需要、欲望、需求三者之間存在著這樣的層級關系：

很多人看到上面也許就有點困惑了，因為我們平時做的產品需求的概念，好像并不符合上面教科書的理論，畢竟很多需求用戶都不具備購買能力。簡單來說，那是因為在互聯網行業內，“免費”的商業模式逐漸打破了欲望與需求之間的壁壘，許多互聯網公司已不再對其提供的基本產品進行收費（如騰訊的qq、百度的搜索、360的殺毒軟件），而是通過其它途徑來獲取商業利潤（如廣告、增值服務等）。換而言之，是免費這一偉大的商業模式，將營銷教科書上的理論進行了重構和顛覆，所謂創新當然不會在理論的條條框框里束縛住。

那需求的本質又是什么？

手機qq里面的附近的人，想必大家都玩過。如果有一個用戶給手機qq的產品經理提了一個需求，說希望能在附近的人里面提供一個付費服務，只要付了費就能夠在附近的人中進行置頂出現。

你覺得這個需求的本質是什么？

我們來嘗試簡單分析一下，用戶希望能夠置頂出現在附近的人列表里面，那么他當然是希望有人來找他聊天，以增加存在感。而我們知道，qq用戶玩附近的人，很大程度上都是看對方頭像的顏值去決定要不要和這個人進行聊天或者互動，而一個人如果長得比較丑，頭像比較難看，那么即使你把他的頭像置頂到列表的最上方，依然不會收到多少互動信息。這個時候，你會發現，即使給了他這么一個置頂的功能，他依然沒有解決自己需要被關注、需要社交增加存在感的本質需求。換個角度來想，興許給他一款美顏相機，讓他也可以輕松地拍出好看的頭像，是不是能夠更加容易地解決他的問題。

相信很多產品經理也都看過“客戶要買的不是鉆頭，是洞”和“福特造車”這兩個故事，其實這些互聯網上流傳已久的故事，要告訴我們的，也無非是這么一個道理——作為產品經理，應該透過表面需求去發現用戶真實目的或者欲望。

所以，需求的本質其實是動機。產品經理需要通過用戶的回復、行為、反饋、抱怨等現象，去深刻把握用戶的本質需求，就像用戶要的其實不是一匹更快的馬，而是更快地到達目的地。

總結互聯網的兩種需求：一種是使我們生活更方便，另一種是解決我們的無聊。

需求的前奏——產品定位

前面我們已經講述了如何搭建產品模型。

通過梳理產品模型，我們可以清楚地了解一個產品應該如何定位自己，首先想到要做什么事，是否值得做，是否能夠做，是否充分理解了用戶，然后要找到一個好的定位的落腳點。有了自己的產品定位后，我們就可以更好地開展下面的工作，產品定位是產品設計的方向，也是指導產品需求收集的方向。很多產品經理在做需求管理的工作之前，都忽略了這至關重要的一步，只有在產品定位得到項目團隊成員的統一認識，才能讓團隊后續的工作更有效率和凝聚力。

那么，什么是產品定位？

比如“最簡單易用的拍照軟件”、“產品經理交流成長的社區”、“一個專為程序員找工作的網站”、“一個神奇的網站”……諸如此類都算是產品定位。

產品定位是指確定某產品在消費者或用戶心目中的形象和地位，即通過塑造產品或企業的鮮明個性或特色，樹立產品在市場上的形象，從而使市場上的目標用戶了解和認識本企業的產品。如國內BAT三大互聯網巨頭，它們的產品都有屬于它們自身特有的定位，百度的產品定位或者特色在于搜索和技術；而阿里巴巴的產品定位有著明顯的電商屬性；騰訊的產品更不用說，qq和微信帶有強烈的社交屬性；

產品定位簡單來說，就是用一句話概括你的產品，包括使用人群、主要功能和產品特色。比如某產品的口號是“簡單好用的團隊協作軟件”，我們來分析一下，它這句話的產品定位：

使用人群：有團隊協作需求的人

主要功能：提供團隊協作功能，線上辦公

產品特色：簡單、好用

包含了這三個要素的產品定位，算是基本滿足了傳達產品形象的要求。有了產品定位，其實就已經為產品限定了一個大致的需求范圍，這樣就不至于讓團隊成員在千頭萬緒中感到無從下手，難以取舍，產品團隊的其它人員就可以根據產品定位開始去收集用戶需求。

平常大家都在談需求，但好像并沒有一個明確的概念來界定一個需求到底包含哪些東西，在收集需求之前，產品經理又應該如何更清楚、更科學地描述一個用戶需求。

用戶需求主要包括三個要素：目標用戶、使用場景、用戶目標。

舉個計步軟件的小栗子：

目標用戶：軟件重度使用者，經常徒步旅行

使用場景：剛走完一趟徽杭古道，一天下來走了接近3萬多步

用戶目標：想要將這個牛逼的紀錄分享到朋友圈，讓更多的人看到

一個用戶需求，可以看作是“目標用戶”在“合理場景”下的“用戶目標”，其實就是解決了“誰在什么環境下想要解決什么問題”。每個需求其實都是一個生動的小故事，產品經理在向團隊其它成員描述需求的時候，只有把這些小故事講的生動活潑，讓別人有身臨其境的感覺，才能算是真正把需求給傳達清楚了。

回到剛才計步軟件的例子上，作為一名產品經理，在你向其它成員傳達用戶想要能夠分享自己的徒步紀錄到朋友圈這個需求時，是不是應該夸張地描述一下如果用戶走了多少多少公里，消耗了多少多少卡路里，這個時候把這條消息分享到朋友圈，肯定會吸引用戶好友的點贊和評論，讓用戶的存在感爆棚，那不就對我們產品產生了正向作用么（同時還能起到產品傳播的作用）。

這樣一來，明確了產品定位，知道了如何清晰而準確地描述一個用戶需求，我們就可以放心地開始需求的收集、分析和篩選之旅了。

經過對產品定位的梳理，我們總算明確了產品的目標用戶群體，接下來就可以開始進行需求的收集、分析活動了，總體流程包含這么幾個部分：需求的收集——需求的分析和篩選——需求優先級排序。

需求收集——5種需求來源

不同規模的公司，在需求收集這個環節所使用的方法也不盡相同。這是因為需求收集這件事情本身是會耗費成本的（時間成本、人力成本、資金成本），而處在不同階段的互聯網公司，自然而然對待成本的態度不同。創業型公司一般來說，都傾向于使用低成本的需求收集方式（少數融資數輪的土豪公司除外），而大公司則會有比較專業的用戶研究團隊等來做相關方面的需求收集工作。

在我經歷的項目實踐中，需求采集的方式主要有以下幾種，如圖所示：

1、用戶調研

用戶調研是通過問卷調查、用戶訪談、行業數據報告等手段來收集需求的方式。

通常來說，用戶訪談和問卷調查需要結合起來使用，它們分別從定性和定量的兩個角度去了解用戶需求。用戶訪談的提綱通常是開放式問題，適合與較少的訪談對象進行深入交流；而調查問卷則封閉式問題比較多，適合大用戶量的信息收集，但不夠深入。我通常的做法是先做用戶訪談，了解用戶大概比較關注的一些點，然后據此來設計問卷。

用戶訪談是最常用的方法，主要形式是和用戶進行一對一或一對多的直接交流，最好是采用面對面的方式。如果條件不允許，則用電話、qq、微信等方式來進行溝通，從而獲取用戶需求；要想真正了解用戶需求，就要盡量走到用戶中去，了解他們的想法，深入了解他們在真實環境下的感受、痛點和期望。有技巧的訪談者能發現受訪者對于某項任務/產品所持觀點中最重要的部分，卻不引入訪談者的偏見。

問卷調查是我們在日常生活中經常碰到的，最常見的就是每次商家都會讓用戶做問卷滿意度評價。

網絡問卷調查通常都是通過互聯網渠道，設計問卷由用戶填寫，然后回收問卷，統計問卷數據，了解用戶反饋的方式來了解用戶需求。線上問卷調查工具網站有：麥客、問卷星、金數據等，傳播的渠道可以是微信公眾號、微博、微信群、QQ群或者郵箱、短信等。在做調查問卷的時候，需要圍繞調查目的去設計相應的問題，同時還需要注意問題的準確性，問題不能問得太過空泛或者太過虛；另外還要注意問題的長度和問題的數量，設計的問題長度應該在填寫者愿意認真填寫的時間長度內完成。

行業數據報告，作為一名產品經理，應該對互聯網中的事情有更多的了解，互聯網行業的變化日新月異，各種新的產品呈出不窮，而互聯網的各種信息也能夠給我們提供更多的需求信息。通過行業數據報告挖掘需求，也就是所說的文獻調研，它可以是一些專業的分析報告，也可以是一些比較干貨的資訊文章，與之相關的各種動態。在這里，我推薦幾個常看的網站，產品經理圈子相關網站——人人都是產品經理社區；TMT媒體以及創業類信息平臺——極客公園、36氪、虎嗅網、鈦媒體、愛范兒、品途；數據分析類網站——艾瑞網、TalkingData、友盟、企鵝智酷、中國互聯網絡信息中心。

2、競品分析

競品分析是找到同類競爭產品，深入體驗競品功能，為產品設計及需求收集尋求思路。

競品分析可以在產品設計之初就開始進行，也可以在產品后期迭代的過程中進行分析，前面也已經提到過每次競品分析的目標是有所不同的，而我們這次做競品分析的目標，就是為了收集用戶需求。在體驗競品的過程中，我們可以研究別人是怎么擬定產品戰略、方向的，為了這個產品方向做了哪些功能，這個功能的背后對應的又是用戶的哪些需求。

上圖是網友對美拍和秒拍進行的競品分析。

3、頭腦風暴

頭腦風暴就是一群人圍繞一個特定的話題進行討論。

我常常拉著我們家的產品經理、設計師、運營、市場、銷售，甚至開發進行一場頭腦風暴，當然，教科書上說參與者最好有不同的閱歷和學科背景，這樣更容易產生更多創新的觀點。嗯，我看我們這個團隊陣容就挺搭的。

在頭腦風暴的整個過程中，我會先明確討論的議題，并且會注意引導和發散大家的思維，讓所有的人都能夠參與其中。討論時注意讓參與者自由暢談，并且不對他們產生的觀點和說法進行任何的批評，而且產生的觀點要足夠多。頭腦風暴是一種發散式的討論，特別要注意對討論內容進行詳細的記錄，這時候可以使用錄音、拍照、思維導圖等方式對整個過程進行記錄，方便后期整理，避免遺漏重要觀點。

4、用戶反饋

用戶反饋是產品在測試階段或正式發布后，我們會收到很多的用戶反饋。

通常來說，用戶反饋是在產品上線之后，產品經理能夠在用戶的反饋中了解到用戶的使用情況，也能夠通過用戶反饋了解到用戶所遇到的問題，以及用戶的想法和期望。

收集用戶反饋有哪些渠道呢？產品內的反饋入口、用戶QQ群、知乎、微博、微信、貼吧、產品社區、客服、銷售等等都是收集用戶反饋的渠道。產品經理可以考慮鋪設多個反饋的入口，讓用戶能夠隨時隨地只要遇到或者想到一些問題都能夠快速反饋。

5、數據分析

數據分析在產品上線后，就可以收集到產品的相關數據了。

比如常規的訪客數據、瀏覽數據、在每個頁面的瀏覽時長等概括數據，還包括比較精細的用戶行為數據，如點擊事件、轉化漏斗、用戶畫像等，這些都是產品數據的范疇。產品經理可以依據數據，來衡量產品迭代的效果，也可以通過數據來快速驗證自己的想法。比如某天某個頁面的某項數據指標急劇下降，官網注冊轉化率最近三個月都持續走低，面對這些現象，我們都需要通過數據來分析原因，必要時結合一下用戶訪談會更有效果。

當然，需求收集也并不僅僅是產品設計之前的工作，而是一個貫穿始終的過程；它并不僅僅是產品經理的事情，團隊里的每一個人都能向產品經理提出需求。上面所述的5種基本方法，都是面向用戶層面的需求收集，但一個產品的需求，不僅僅來自于用戶本身，有時候團隊內部也會產生需求，如運營團隊提出的統計需求，銷售團隊提出的CRM需求等。需要注意的是，從公司業務方向、老板/領導、運營、市場、客服等獲取的需求，并不能直接當成最終的需求，還需要更深一層去挖掘需求，并且最終評審確定最終需求。

最后總結一下，這幾種需求收集方法都是獨立的，可根據產品的特性以及產品的發展階段來選擇一種或幾種進行組合使用。

需求分析和篩選

經歷了一次高強度的需求收集運動，絕大部分PM都已經得到了很多的備選需求，像是好不容易去果園摘了一籮筐的橘子回來。接下來，我們就要把一些還沒有成熟的橘子給挑揀出去，對我們收集進來的需求進行分析和篩選。

如何分析與篩選需求呢？

我們先來看一個《精益創業》中的故事：

同步云存儲服務Dropbox的創始人德魯休斯頓（Drew Houston）在沒用寫一行代碼的前提下，拍了一段視頻通過在YouTube上發布視頻來聚攏早期用戶，后面這個視頻被瘋狂轉載，于是他們就有了信心開始正式開發這個產品。

德魯休斯頓（Drew

Houston）并沒有急于馬上動手開發，是因為在當時需要克服重大的技術障礙，且投入成本暫時無法預估。取而代之的是，他選擇了在目標人群中發布一則宣傳視頻，一本正經地向科技愛好者“虛構”了Dropbox的產品功能，用這個方法來驗證用戶需求是否真的存在。我們稱這個方法為可用性測試，用來驗證發現的需求是否確實存在。

當然這種方法，一般是用來測試產品大方向的需求，對于產品大方向已經明確，在收集具體的產品功能模塊需求的時候，就不太合適了。

很多產品經理去面試的時候，可能都碰到過這么一個問題：

在過去的產品工作中，你是如何評估需求的？哪些需求該做？哪些需求不該做？評估的標準又是什么？

有些產品經理可能會說依靠自己的產品直覺，拍腦門進行決定；或者是老板決定后，產品經理來執行。這兩種方式有其一定的道理和適用場景，不過都并不適合產品新人，一是因為產品新人對市場情況、用戶需求的不了解，并不能有很好的產品直覺；二是如果每次直接都是老板拍板。久而久之，你也就成了執行的機器，而喪失了獨立思考的能力。

作為產品新人，我們可以借用其它靠譜的分析理論來進行需求的分析和篩選工作。

1、篩掉明顯不合理的需求

哪些是不合理的需求？比如當前技術不可能實現的或者是明顯意義不大的，投入產出比比較低的，無匹配的產品使用場景的，明顯不合理的需求等，都可以歸類為不合理的需求。

2、再來看如何做需求分析

把明顯不合理的需求排除后，我們就需要把剩下的需求一個一個進行分析了。首先要了解需求的三個分類：用戶講述的、用戶實際想要的、用戶的潛在需求，這是三件不同的事情，卻又有著千絲萬縷的聯系。我們需要通過用戶描述的需求，找到用戶實際需求，發掘潛在需求.

舉個例子：

一天晚上，小明和媽媽走在回家的路上，突然小明感到餓了，鬧著媽媽說：“媽媽，媽媽，我要吃肯德基，我要吃雞腿。”但是附近沒有kfc之類的西式快餐店鋪，媽媽有點犯愁，怎么辦呢？但又不能餓著小明，媽媽突然想起來早上路過面包店買的面包還在包里，便拿出面包給小明充饑，小明一看還有面包，于是很高興地開始吃了起來。

我們按照需求的三個分類來分析一下這個問題：

用戶描述：想吃雞腿

用戶實際想要的：餓了，只要有好吃的都行

用戶的潛在需求：飲料？水果？

這個故事相對來說比較簡單，但是也比較具有代表性。孩子不是很能表達自己的需求，但是媽媽很了解自己的孩子，所以能找到孩子的實際需求，在我們的工作場景中，我們也要多花些時間了解我們的用戶，同時可以參考借鑒一下阿里巴巴前CEO衛哲的“3+1思考法”去分析用戶需求：

需求從哪里來，目標用戶是誰？

到底是我們想做，還是客戶想要，亦或是老板想要，給誰解決問題；

有多少人有這樣的需求？這個需求緊迫嗎？

有多少人有這樣的需求意味著市場的容量，緊迫程度意味著解決需求的價值；

用戶的痛點是什么？使用場景是什么？（用產品之前／后）

解決了什么問題，不解決會存在什么問題，用戶問題的使用場景我們是不是真的找到了；

+1?怎么驗證需求是否解決與解決效果？

解決之后在網站數據上會有什么表現？是網站數據提升了，還是用戶反饋效果比較好。

我從前阿里產品經理蘇杰的博客文章《衛哲的3+1思考法：測量項目“靠譜程度”》中把衛哲和產品經理之間對話給扒了下來，我們還是來好好感受一下畫風吧：

衛：你們怎么想到要做這個產品的？（需求從何而來，目標客戶是誰？）

我：我們在和賣家接觸的時候發現有很多人花很多時間了解競爭對手的情況和市場上什么好賣。（需求來源的描述，這里注意到“賣家”“很多時間”“對手的情況”均是概念模糊的，沒有一個明確的描述或定義。衛哲下面的提問也是在對這些模糊概念的提問。）

衛：有多少賣家做這件事？多久做一次？（有多少人有這樣的需求？這個需求緊迫嗎？這里就是對“賣家”“很多時間”的一個提問。）

我：大部分賣家每周都會做幾次

衛：他們現在是怎么了解競爭對手的情況和市場上什么好賣的？（詢問使用產品前的場景，這里是對“對手的情況”進行一個提問，從而知道對手的情況到底是什么情況。）

我：他們現在每天都會上淘寶進行搜索，找到同類商品賣得好的賣家，然后看他的關鍵字設置有什么特點，價格是多少，賣了多少個，做了什么活動，每周要花好幾小時。（關鍵字、價格、銷量等詞匯對“對手的情況”有了一個較為明確的描述。）

衛：那用了你們的產品，他們怎么做這件事？

我：用了我們的產品，他們一方面可以看到針對他的某個寶貝，同行的類似寶貝有哪些，價格如何，銷量如何。另一方面可以看到某一類目下特定關鍵字下，哪些寶貝賣得最好。（解決方案）

衛：也就是說你們是幫他們節約時間？小企業的時間是不值錢的，中國是這樣，美國也是這樣。（通過以上的問題，成功挖掘出了真正的需求“為賣家節約時間”）

我：…

衛：這些數據他們自己在網上能看到嗎？（如果沒有這個產品，用戶會死嗎？側面幫助分析需求的重要性和緊急性）

我：能，但有些統計和分析，比如平均價格，有多少人比他價格高之類的他不知道。

衛：那知道了這些信息之后呢？他能做什么？（詢問使用產品后的場景，繼續挖掘需求。）

我：他可以做一些關鍵字的修改，價格的修改，或者換一下推廣的商品，做直通車的時候可以更有的放矢。

衛：那我們的功能有沒有和推廣掛鉤，比如和直通車做整合？直接讓他做直通車的優化？（挖掘出新的需求或者說是更深層次的需求“商家需要解決方案”。）

我一愣，這個問題我還沒有想過，但立刻意識到這可能是個方向：還沒有，不過的確是個很好的方向。

衛：那客戶在用了你們的產品后，網站數據上會有什么反應？（解決之后在網站數據上會有什么表現？產品目標是必須有明確的成功標準的，并且必須是可衡量的。）

我：也許賣家的搜索行為會減少吧，修改的次數會增加。

……

怎么樣，是不是被ceo們的分析思路給深深折服了。通過這一系列的問題，我們大致就能夠將每一個需求是否要做，什么時候做，優先級如何有了一個大致的預測了。

3、需求的減法

我一直信奉一個產品理念——少即是多。其實，有時候決定不做什么往往比決定做什么更加重要。產品的需求可以說是無上限的，大量的堆積需求，會使得產品非常臃腫，而且毫無特色，而需求的過多，還會導致工期過長，拖慢了產品推出市場的進度，對產品百害而無一利。因此，應該傾向于做“輕產品”，學會做需求的減法。這方面，蘋果前ceo喬布斯就是個做減法的大師，蘋果的所有產品都透露著一種極簡風格。

這就涉及到我們接下來要討論的話題，如何判斷需求的優先級了。

如何判斷需求的優先級

評估需求的優先級也是產品經理的一項重要能力，在前面已經通過需求分析評估和篩選了哪些需求該做，哪些需求不該做，對于決定要做的需求，由于數量過多，不可能全部都在同一時間全部開發完畢。這個時候，就需要產品經理對所有的需求來定義一下優先級，優先級高的需求優先研發，優先級低的需求延遲研發。

由于我們整個部分都是在介紹如何從0到1的打造一款產品，所以新產品在未上線之前，是沒有相關的運營數據作為支撐的。這個時候，大部分在定義需求的優先級時，我們一般通過需求對用戶的重要性和緊迫性來判斷。

KANO模型是用來進行判斷需求重要性的一條非常有用的法則。KANO模型定義了三個層次的用戶需求:基本型需求、期望型需求和興奮型需求。基本需求是必須具備的，即使不說也應該做到，這部分需求一般是產品初期需要做的功能。期望型需求是用戶期望的，用戶能夠較清晰地知道的。而興奮型需求是超出用戶預期的，用戶不知道有這方面的需求，如果提供，用戶滿意度會更高。一般情況下，用戶需求的重要性依次為：基本型需求→

期望型需求→ 興奮型需求。

考慮完了需求的重要性問題，我們接下來考慮需求的緊迫性問題。通常情況而言，基本型需求的重要性最高，且也最緊迫，所以基本型需求的優先級默認是最高的。但是由于公司其它部門，如運營、市場、銷售等部門業務需求的迫切需要，會同時研發一部分期望需求（重要不緊急）和興奮型需求（緊急不重要）。

來個經典的案例講解下如何進行用戶需求的優先級排序。

話說，網上流傳騰訊有一道經典的面試題，題目的具體內容是這樣的：

1998年，QQ開始規劃，1999年2月推出Beta1版本，1999年5月Beta2，1999年8月Beta3。Beta1版本只能實現3個特性，優先推哪三個呢？請從以下選項里勾選：

卡通頭像

QQ表情

聊天記錄管理器

看誰在線上

安全性

傳文件

很小的.exe文件

視頻

聊天室

語音

速度超快0.5秒反應

皮膚管理

大家可以嘗試著用KANO模型進行需求的優先級排序，但是別忘了結合當時的互聯網發展狀況及背景進行分析，想好了答案可以關注我公眾號與我進行溝通交流。

當上述的重要性和緊迫性問題都考慮完整后，我們就可以輸出一份高質量的功能需求列表了，同時也意味著我們即將進入需求管理的階段。

我們已經通過需求分析和篩選，評定了需求的優先級，這時候就應該把這些整理好的需求，通過一個表格給呈現出來，功能需求列表Feature List就是這樣一個承載器。

輸出功能需求列表

什么是功能需求列表？顧名思義，就是把需求分析、篩選和評定優先級之后的結果，以產品功能的形式展現出來，再用列表的方式將其呈現。這是需求分析之后，提出解決方案的第一步。

功能需求列表的價值，一是在于幫助產品經理自己理清思路，二是在于幫助項目團隊的其它成員了解產品功能需求，好讓他們提前做好相關準備。

我們來看一下功能需求列表大致包含哪些內容：

模塊：一般來說，每個模塊下分3~6個子模塊是合理的，否則要考慮重新劃分。

子模塊：也就是一級模塊的二級分類，這里就已經涉及到產品架構的梳理了（但我們這里只是大致地梳理一下，后期在產品設計的下一個環節“搭框架”會進一步調整）。

功能：要給用戶提供什么功能，給這個功能起個名字。

功能描述：這個功能具體包含哪些操作，可以描述的具體一些，如支持用戶填寫基本信息可自由創建課程，進入課程空間就可對課程進行編輯和管理，還可發布、刪除課程等。

用戶價值描述：也就是可以給用戶提供什么價值。

需求優先級：這塊是整個Feature List工作中核心的部分，判斷的準確直接影響著將來產品的方向，我們只需要將我們之前評定的需求優先級照抄過來就好。

開發量：一般由研發部門的項目經理或者開發來確定。

投入產出比：簡單來說，就是商業價值除以開發工作量（或開發難度），當然每個團隊可以找出一個合適自己產品需求ROI的計算方法。

備注：覺得需要強調的，比較特殊的東西。

上圖是功能需求列表的一部分，當然現在也有越來越多的產品經理直接通過腦圖軟件來進行功能需求的梳理，然后通過腦圖軟件自帶的標注、附件、筆記、優先級排序等功能進行說明，比如下圖這樣的：

形式其實并不是那么重要，重要的是團隊成員能夠通過你的文檔更加清楚地了解產品的功能需求，也便于產品經理和團隊成員進行溝通。有了這份功能需求列表，我們就可以召集團隊相關成員進行一次需求評審會議了。

參加需求評審會議的可以有產品經理、老板/領導、運營以及市場相關人員、開發主管、測試經理等。為了保證需求評審能夠順利進行，最好提前做好相關的準備，產品經理要能夠講清楚需求的來源，為什么要做這個需求，做這個需求有什么意義，這個需求需要哪些功能配合，同類競品是否有該功能需求，為什么這個需求的優先級比較高……

整個需求評審的過程，考驗了產品經理對需求的熟悉程度以及對需求的判斷能力。同時，參與評審的人也將會對你提出的需求提出自己的看法，是否同意該需求，并且會提出同意或者不同意該需求的理由。需求評審是多人圍繞已經收集到的需求進行評審的過程，通過集合大家的智慧，能夠避免一個人閉門造車拍腦袋進行決策的局限。

如果時間比較充足，有些產品經理在需求評審會議上還會展示產品低保真原型，用來輔助說明，讓大家更加理解這個需求以及需求以后會是怎樣的樣子，這樣也能夠讓自己在講解需求的時候更加有依有據，避免錯過一些有用的需求。當然，我們這里只是第一次需求評審，到了后期產品原型乃至ui設計稿全部定稿的時候，依然需要進行產品的需求評審。

如何管理需求——需求池

之前就已經說過，需求是每個產品經理日常工作都離不開的一部分，貫穿著產品的整個生命周期。所以，如何管理需求，就成為所有產品經理必備的一項技能了。

在這里要給大家介紹一下需求池這個東西。

什么是需求池？

嗯，你可以把它類比為一個需求的收集器。需求池其實就是存放跟產品有關的未來可能會做的功能點的聚集地，然后在規劃新版本的時候，從池子里根據“輕重緩急”和“優先級”來篩選出幾個需求，排一排、整一整，弄成一個新的版本項目計劃。

需求池工具有很多，比如Project、Execl、MindManager等等都可以作為需求池管理工具，你也可以使用一些團隊協作軟件（如tower、tita、明道、teambition等）里面的項目管理功能來做需求池工具。

一般來說，我會將需求池按產品的功能模塊來進行劃分，這樣所有關于產品功能的需求都會被歸類到相應的產品模塊里。當然，這個需求池里還會包含來自運營及其它部門的需求。我們要做的就是告訴這些需求提出者，他們的需求我們都重視了，已經放到了需求池當中，但是是否安排開發需要根據所有需求進行“輕重緩急”和“優先級”的權重比較才能決定。我們需要定期去審核和分析這些需求，是做還是不做、要做的話是什么時候做？

對需求池的建議有兩點：

1、不必考慮能不能做或者是做了沒用什么的這樣的限制，先不必設置偽命題，只要是覺得OK的，都可以先列出來，在產品生命周期管理中，靠譜的、不靠譜的、緊急的、不緊急的；

2、需求池需要產品經理經常去整理，不然就失去了需求池本身的意義，如果你不去整理，不論是市場環境，用戶行為都有可能發生變化，任何一個產品都是變化很快的，這個時間段的需求有可能過一段時間就失去意義了。這個整理其實就是復原了一次需求的分析和篩選過程，同時還要去進行需求的優先級定義，每一次安排產品版本計劃的時候都要重新審視一遍需求。

總結

需求管理是一個完整的閉環過程，同時也貫穿著產品經理工作的每一天，比如：

1、我們是不是每天都要去思考這個需求是否需要去做？這個需求到底重要不重要，緊急不緊急；

2、我們是不是經常都要去用工具把需求給做出來，用visio這樣的流程圖工具去梳理業務流程，用axure這樣的原型工具去設計產品原型，做的同時還得思考這個功能需求究竟放在產品的哪個功能模塊合適；

3、我們是不是每天都要去和各種人溝通需求，和設計師溝通需求，和前端工程師溝通需求，和后臺開發溝通需求，還要和測試、市場、運營、銷售等溝通需求。同時，你還要和用戶談需求，讓用戶了解和認識你的產品；

不得不說，要做好產品經理真不是一件容易的事情。

原文鏈接：http://www.woshipm.com/pmd/421678.html

----------------------------------------------------------------------------------------------

閱讀更多好文，請關注公眾號：

新雨社