通過市場、競品、用戶調研以及自己這個產品經理價值觀，我們形成了初步的這款產品的需求池，需求池就是產品經理的武器，無法掌控自己的需求池，那么就無法掌控自己的產品。

筆者會從以下幾個維度逐步拆開來寫進程，慢慢形成一個系列。之前的文章，可以在筆者的個人中心閱讀。

• 一、市場分析篇：市場分析（上）；市場分析（下）
• 二、競品分析篇：競品分析
• 三、用戶調研篇：用戶調研（上）；用戶調研（下）
• 四、需求管理篇
• 五、架構流程篇
• 六、原型設計篇
• 七、UI設計篇
• 八、PRD文檔篇
• 九、開發(fā)管理篇

在此聲明：本系列的產品內容原創(chuàng)且非商用，如有雷同，你抄我的。

一、前言

進入這篇之后，我們正式進入產品設計章節(jié)。那么就從一切設計的源頭：需求開始講。需求也是產品經理在日常工作中最掛在嘴邊的詞。有人說代碼是程序猿的武器，那么需求池就是產品經理的武器。對需求池的掌握有多精準，對產品設計就有多少掌控感，也就是所謂的owner。

需求，是個大命題。在道的層面上可上升至人性、用戶心智等，需要各自去領悟。筆者能力不在此獻丑。因此筆者將從術的層面來講講0-1做App中怎么管理需求。

二、要點分析

先說結論：先做加法，建立自己的需求池，后做減法，版本排期。

關于需求的術，對于某一個需求，筆者自己按照下述4個階段進行。

1. 需求收集
2. 需求的轉化
3. 需求的甄別
4. 需求優(yōu)先級

筆者接下來將從這4個階段來復盤我們0-1設計App的需求池管理

三、需求收集

首先是需求的來源。筆者總結分為內部需求和外部需求，一共是8個來源：

對于我們從0-1做一款產品來說，基本依靠外部需求：市場、競品、用戶三個大方向。所以，我終于可以和你們說為什么前期要先做市場、競品、用戶調研了。一切都是為了需求而服務。

筆者這里對市場、競品、用戶三個再拆開稍微細講一點，著重講講三者的側重點。

3.1 市場需求

市場需求是最宏觀，用比較容易理解的話，叫“風口”，市場需求往往是宏觀趨勢，普遍性強。

市場分析，讓我們用一句話來概括就是：在（什么產業(yè)鏈條）上發(fā)現(xiàn)了（某種風口/趨勢）存在（可見/不可見的機會點），我們如果要做，會面臨（競爭格局、政策環(huán)境、用戶習慣等）挑戰(zhàn)。

那我們的0-1產品呢？，化為一句話就是：在互聯(lián)網職場在線教育上發(fā)現(xiàn)了回歸教育本質的趨勢，存在從碎片知識共享到系統(tǒng)技能陪練的機會。但是仍面臨模式創(chuàng)新、優(yōu)質老師少、教育周期長等挑戰(zhàn)。

作為產品人，日常做市場分析又看些什么呢？同樣地，筆者認為從簡為好，能保持持續(xù)關注比華麗的文檔報告更重要。筆者一般會關注以下4個方向：

1. 市場規(guī)模、產業(yè)鏈地圖
2. 上下游產業(yè)的動向
3. 當前頭部競品和潛在競爭者
4. 用戶結構、用戶習慣

3.2 競品需求

競品需求側重于差異化。一句話：抄的目的是為了不抄。

筆者日常中會從以下幾個方面持續(xù)關注競品，通過Excel記錄。

1. 競品定位、商業(yè)模式
2. 競品業(yè)務流程、功能框架
3. 競品產品/運營節(jié)奏

前兩點可以定期做分析，或者根據競品大版本和一些資訊來做判斷（一些小道消息很有用）。第3點的話強烈建議日常跟進，專人跟進競品，除了產品角度，運營角度也要核心關注。

持續(xù)做競品的需求發(fā)現(xiàn)，筆者相信會有一天你哪怕是看著對方很不錯的功能，你也只是會輕蔑一笑。

3.3用戶需求

重要性就不贅述了。用戶兩個字可能是產品嘴邊最多的詞，沒有之一。

這里筆者就提及一點感悟，再次強調。

用戶表達的訴求真的不等于需求，大概率是兩碼事。詳細的筆者接下來從需求的轉化來說。

值得一提的是，8個維度的需求，大部分都是一個課題可以研究，尤其是內部需求的4個維度，和我們日常工作相關性最大，如何處理這類需求也是有方法而論，而且更貼近PM的市場工作，不過不在本文討論范圍內。

所以我們在需求池里，可以增加【需求來源】的屬性，對每項屬性進行分類，將之前來自市場、競品、用戶、產品經理的需求區(qū)分開來。

四、需求的轉化

什么是需求的轉化？

在邏輯上有兩個環(huán)節(jié)。

1. 用戶需求–>本質需求
2. 本質需求–>產品需求

插一句，這個本質需求可以是人性（生存、追利、懶惰、虛榮、社交、安全、貪婪等），也就是筆者之前提到過的“本我”。

舉個經典的栗子：100多年前，小明周末想要去B城陪女朋友，但是騎馬需要一天時間，他就想要去挑選最快的馬，正好遇上福特，福特問他為什么要最快的馬？小明說想要節(jié)約時間早點到女朋友身邊。于是后來福特就造了汽車讓小明開，小明每周末都能陪女朋友了。

這里其實就是需求的轉化：

• 用戶需求：小明為了快速抵達B城，想要最快的馬
• 本質需求：小明要節(jié)約時間，提高效率，不浪費時間在路上
• 產品需求：造出比馬跑更快的機器，讓小明使用。

我們需要不斷思考，Why？why？why？通過幾個why來追問自己和追問用戶你的本質需求是什么，然后你再給出一些解決方案，即產品需求。

根據我們設計的APP再舉個栗子：

• 用戶需求：用戶認為課程不錯時，希望能繼續(xù)上該老師的課程，會持續(xù)關注老師的動向和新課。
• 本質需求：對權威的一種認可，想要跟隨權威學習知識。
• 產品需求：設置老師的私密圈子功能，用戶加入圈子之后，可一直免費關注老師的動態(tài).

所以我們在需求池里，可以增加【用戶需求】和【產品需求】的屬性，對每項新的需求進行轉化。這個過程需要思考，也是之前提到的【道】的部分，看似簡單確實產品經理的核心功能，因此我建議大家可以針對每項需求做需求轉化，哪怕是當作練習也好，久而久之你會有意想不到的收獲。

五、需求的甄別

什么是需求的甄別？說白了就是砍需求。或者說是一層過濾網。

那么一般通過哪些維度來過濾呢？

1. 用戶價值（場景、問題）
2. 商業(yè)價值
3. 數(shù)據支持（灰度、A/B）

在筆者的工作中，主要依據這三個維度。前兩個維度合在一起也叫做戰(zhàn)略層（參考《用戶體驗要素》）

具體怎么判斷，筆者也給不出具體答案。但是可以說的是，產品的不同生命周期階段，側重不同。

換句話說，需求是有其時空約束的。跟愛情一樣，對的需求也要看時間的。

如果很難理解的話，不妨去回看以下抖音的發(fā)展歷程，抖音是如何從用戶價值逐漸偏向商業(yè)價值，微信也行。期間不斷輔之以數(shù)據的支持（A/Btest、灰度測試等）來做他們的需求，最終呈現(xiàn)給我們的是產品功能。

需求的篩選比較偏向主觀，但是這也正常，考驗的還是產品經理的功底。所以很多人說產品經理是需要人文、哲科都“略懂”的人，大家平時也要注重“無用之學”的積累。

顯然，對于我們0-1的產品來說，現(xiàn)階段一定是用戶價值大于商業(yè)價值的，不用考慮商業(yè)價值，商業(yè)產品，只用考慮如何滿足用戶需求即可。凡是不能切實解決用戶問題的需求，都是可以直接砍掉的，或者凡是沒有用戶實際使用場景的需求，也是可以砍掉的。

六、需求優(yōu)先級

筆者在之前特別信奉多維度進行判斷需求的優(yōu)先級，然后做出了類似如下的需求池：

但是實際工作中，會有3個實際情況。

1. 需求池基本上是給自己看的。
2. 打分數(shù)這個看似客觀的方法，其實最主觀。
3. 往往最后判定優(yōu)先級的還是一念之間。

因此，筆者建議，給需求的優(yōu)先級打分，依據腦中的主觀意識即可，最多打個ABC三個級別。

錯了怎么辦？ 錯誤的經驗會讓你的判斷力大幅度上升，會越來越準，越來越有感覺。

所以，現(xiàn)在的需求池就是這樣的：

最后奉上我們0-1產品的需求池。需求池主要是給自己看，如果你們看不太懂，請見諒。

七、版本規(guī)劃

• 一個字：砍。
• 兩個字：減法。
• 三個字：去需求。

在實際工作中，產品和開發(fā)苦版本久矣！產品做不好需求控制，開發(fā)天天臨時加需求，怎么能不撕逼。

一句話概括：版本==每次封閉的需求集合（兩個等號是為了尋求開發(fā)理解）。

給出一個比較靠譜的方法：自己的產品每個版本最多就動3個模塊，每個模塊最多動3個功能，也就是無論大小需求，最多動9個功能。多了就放到下個版本里。俗話說，盯著碗里看著鍋里，咱們產品人要盯著這個版本，看著下個版本還要展望下下個版本。。

道理不說太多，做不好版本規(guī)劃也能推進項目，但是能做好版本規(guī)劃，你一定是人品口碑很棒的產品。

那么針對我們0-1的產品呢？

這里再提出一個更加重要的概念：MVP（最小可行性產品）。

針對MVP怎么做筆者日后再說，這里舉一個筆者工作中的例子，希望對你們有所啟發(fā)。

當時同花順內部想要上線一個收益計算器的功能，因為涉及的算法和客戶端開發(fā)比較復雜，工程量較大且無法知曉用戶的反饋。我們當時決定做一張圖片，簡單說明一下多少錢能帶來多少收益，放到資訊運營條上測試一下效果，看看數(shù)據和評論情況。花了一天做完圖上線，在接下來7天內數(shù)據大好，評論區(qū)討論熱烈。于是我們才決定做這個功能。

MVP可能是圖片，可能是個假功能，甚至可能是一句話。通過數(shù)據的的分析，再來決定是否做，這將幫助我們砍掉大部分拍腦袋的需求。

因此，對于我們V1.0.0版本的功能，也稱Feature Lists，筆者這里直接給答案了。簡而言之，就是產品最核心的功能，除此之外，統(tǒng)統(tǒng)砍掉。

OK，本系列第四篇：需求管理篇?，F(xiàn)在我們已經基本掌握了第一個版本的功能項，在范圍層上打好了基礎，接下來要組織好這些需求，搭建一副產品骨架。下一篇，我們將開講最重要的架構和流程。

作者：朱魯斌，同花順產品經理（B端方向）

本文由@朱魯斌? 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash， 基于CC0協(xié)議。