上一篇文章，我們一起探討了選擇有效需求的三個建議其中的第一個建議，判斷需求是否符合產品本身的定位，這篇文章我們繼續(xù)探討另外兩個建議。

是否符合產品當前階段的重心

越是成熟的團隊，越是不那么隨心所欲，當小團隊在埋頭找不到需求做時，大團隊的需求可能已經排期到下半年了，這是團隊發(fā)展的必然趨勢，需求會隨著產品的發(fā)展變得越來越多。

需求排期這樣的開發(fā)模式里，我們會很清晰的告訴團隊，這個階段，我們的重點是什么，重心是什么，需求要往哪個環(huán)節(jié)傾斜，不符合當前階段重心的需求，則會考慮往后延期。

我們需要理解什么是當前階段，什么是重心。

版本編號對于大家來講一定不陌生， 常見的版本編號由4段編碼組成，A.B.C.D 如“1.2.3.4” 其中 A表示大版本編號，B表示模塊新增，C表示功能新增，D表示bug修復。

實際上，每個編號都有其對應的一套衡量標準， 對于圖片處理類產品而言，我們已經有了水印功能，此時增加一個設置水印字體的模塊，會在B段編碼增加一位，而在原有水印顏色的基礎上增加一個顏色，則會在C段編碼里增加一位，如果是增加一個貼紙模塊，則是在A編碼增加一位。

在我們進入版本開發(fā)之前，我們的leader就會告訴我們，這一階段是做什么類型的需求，是做一個小版本，還是做一個大版本，這將會極大的幫助我們去尋找合適的需求列入開發(fā)計劃。

實際上A段和B段編碼由于成本較高，往往是由leader直接明確指定重心任務，是已經確定要做的事情，不妨將這個重心理解成暫時性的“產品本身的定位”。

對于C段和D段編碼而言，往往是以“完善”和“修復”作為重心，且這兩個段位我們都稱其為“小版本”，這樣的階段里，我們更多的去追求完善的功能數(shù)量，修復的bug數(shù)量，在單位時間里，追求更高的覆蓋面積。

等同于“做一些簡單的功能，不要耗費太多時間，盡量去完善”。

因此，一旦我們評估出某個需求的成本過高了，不妨告訴自己的leader，將其放到某個大版本的規(guī)劃里去執(zhí)行。

該需求的潛在群體面積有多大

我們已經知道需求是要經過選擇的，前面兩個建議，是從團隊，也是從項目角度出發(fā)去做判斷，而這個建議則是直接從需求本身出發(fā)，去進行判斷。

作為產品經理而言，我們的決策具備舉足輕重的影響力，這不是說我們有多么的權威，而是說我們決定了整個團隊的力量往何處使。

一個7人小團隊，產品經理的一個需求，會耗費整個團隊一個月的時間，換算成人工成本，我們的一個想法，需要耗費十萬人名幣去實現(xiàn)。

如果這個需求被判定為無效需求，就相當于打牌輸了十萬人名幣。

實際上，產品經理是比較兇殘的賭徒，假如我們持續(xù)半年乃至一年都在做無效需求，就等同于輸了上百萬人民幣，盡管這筆錢并不表示由我們自己來承擔。

因此，什么樣的需求能做，什么樣的需求不能做就顯得尤為重要了。

做面積大的，不做面積小的

這個道理很簡單,100位固定的用戶，90位喜歡吃蘋果，10位喜歡吃香蕉，作為商人來講，你是賣蘋果呢，還是賣香蕉呢？

我們滿足大部分人都存在的需求，舍棄小部分群體的需求，不論這個小部分群體有多么的迫切，因為產品的價值無限接近于使用的人數(shù)，愿意買單的人越多，那么這個需求 便越有價值。

這點，在用戶需求里，我們更多的是去反推，根據(jù)某位用戶明確的需求反饋，去推測在目標用戶里，有多大的潛在群體，他們占比的面積有多大。

“消息的閱讀狀態(tài)” 能讓我們知道發(fā)給朋友的消息，對方是已經看到了，又或者還沒看到，這個功能對于現(xiàn)在而言并不陌生，許多社交產品都提供了類似的功能，而微信卻一直沒有推出，實際上微信以后也不會推出該功能。

對于微信的目標群體而言， 只有少部分群體以及少部分場景需要這個功能 。

相對于我們每次使用微信所發(fā)出去的消息，非常關注閱讀狀態(tài)的這部分消息占比少，可能一個星期里會有1-2條，我們會對閱讀狀態(tài)保有期望

相對于情侶，職場這樣的強迫性關系而言，朋友或者半熟人在微信的用戶關系體系里占更高的比重，而對消息的閱讀狀態(tài)保有期望的更多的屬于情侶以及職場的上下級。

以上兩個結論，我們完全可以通過用戶的抽樣訪談，用戶調研等一系列手段來得到參考數(shù)據(jù)。

而這部分數(shù)據(jù)就會直接的告訴我們，“消息的閱讀狀態(tài)”是多數(shù)人的需求還是少數(shù)人的需求，盡管當我們和上級聯(lián)系時，當我們和伴侶聯(lián)系時，真的很希望能知道對方是否已經閱讀了這些消息。

響應用戶需求

當我們已經明確鎖定了某些需求時，也就是說我們已經決定了要做某個需求了，可以再來判斷一下這個需求是屬于什么類型的，是簡單的，還是復雜的，又或者是線性的。

簡單需求

簡單需求是指獨立性比較高的，于其他模塊牽連很小的需求類型，就像積木游戲里多了一塊豎條對整個模型而言，不會有太大影響。

典型的簡單需求比如在微信的錢包里，增加某個功能入口，點擊進入對應的功能。

復雜需求

復雜需求是指會和其他功能模塊有密切交互的，需要開發(fā)額外系統(tǒng)的，這就好比拼圖游戲，我們要增加一個圖形，就需要考慮周邊其他圖形的邊緣。

微信朋友圈允許發(fā)布短視頻便是一個復雜的需求，需要考慮到本地上傳，多平臺的播放，關系的屏蔽或開放等，都會受到影響。

線性需求

線性需求是比復雜需求更加復雜的需求，幾乎已經不能視為一個模塊了，他應該是一套完整的系統(tǒng)，并且一個版本沒有辦法完全開發(fā)，需要在后續(xù)若干個版本里進行完善，進行迭代，需要進行維護的。

朋友圈的廣告功能，便是一個線性需求，除了播放廣告以外，還需要有一套廣告管理系統(tǒng)，一套廣告和用戶的匹配系統(tǒng)，甚至一套銷售管理系統(tǒng)來支撐。

即學即用

音樂的歌詞非常的唯美，再搭配上一張唯美的圖片，實在是提升朋友圈逼格的利器，你覺得制作音樂歌詞海報對于音樂類產品而言是大面積需求還是小面積需求，比如說QQ音樂。

（QQ音樂具備該功能，可以體驗一下）