接下來，我們要開始講產(chǎn)品經(jīng)理工作中最重要的環(huán)節(jié)——需求分析與管理。

這里我對需求分析的定義要廣一些，包括：需求的獲取、需求的評估、需求的評審、需求的管理等。因此，本文是對產(chǎn)品全生命周期需求分析的描述，不僅僅是產(chǎn)品前期的需求分析。

本文結(jié)構(gòu)如下：

No.005 如何做好需求分析.png

我們先來看看需求的分類。

一、需求分類

1、從商業(yè)角度分為用戶需求和商業(yè)需求

用戶需求：2C產(chǎn)品我們通常叫做用戶，2B產(chǎn)品我們可能還會叫他客戶。這些人的訴求稱之為用戶需求。
商業(yè)需求：和企業(yè)利益密切相關(guān)的需求。

作為產(chǎn)品經(jīng)理，我們一定不能只考慮用戶需求，還要考慮其與商業(yè)需求的權(quán)衡。你做一個所有人都喜愛的產(chǎn)品，但是卻沒有任何盈利點，又有什么用呢？

用戶的需求包括但不限于一下這些：

• 娛樂休閑
• 歸屬感
• 溝通
• 意見領(lǐng)袖：意見領(lǐng)袖的一言一行是追隨者愿意模仿，意見領(lǐng)袖存在是具有其自身價值的。
• 利益：物質(zhì)利益、精神利益
• 獲取知識和資訊
• 自我情感表達
  • 對人情感的分類：懷念，痛惜，懷恨，輕蔑，佩服，失望，嫉妒，慶幸，誠信，通信，嫉妒，快慰，信任，顧慮，顧忌，嘲笑。
  • 對己情感分類：自豪，慚愧，得意，自責(zé)，開心難堪，自卑，自信
  • 在現(xiàn)在生活中，人對自己情感的閱讀很差的，很少有人愿意去讀自己的內(nèi)心。所以產(chǎn)品經(jīng)理要學(xué)會洞察并把握用戶情感。
• 愛和被愛
• 社交
• 分享
• 安全
• 尊重

當(dāng)然，這里有一個經(jīng)典的理論模型——馬斯洛需求層次理論模型。用戶所有的需求都可以對應(yīng)到這個模型上。我們要的不是說要了解該模型中每一層都對應(yīng)哪些需求，而是要能夠知道該需求可以對應(yīng)到那一層，這是一個思維問題。

馬斯洛需求層次理論.jpg

2、從產(chǎn)品開發(fā)角度分為功能性需求、非功能性需求

功能性需求：即產(chǎn)品設(shè)計上的功能

非功能性需求：包括產(chǎn)品性能、安全、兼容性、運營、UI、數(shù)據(jù)統(tǒng)計等需求。

很多產(chǎn)品經(jīng)理都會忽視非功能性需求，最終導(dǎo)致產(chǎn)品出現(xiàn)各種bug、宕機、頻繁修改等問題。
這里提醒大家一點，我們永遠不能假設(shè)開發(fā)同志們在開發(fā)時，能夠考慮到性能、兼容性等問題。考慮這些問題，是產(chǎn)品經(jīng)理的工作。

3、按需求重要性分

3.1 必備型需求

必備型需求是用戶認為產(chǎn)品“必須有”的屬性或功能。

當(dāng)其特性不充足（不滿足用戶需求）時，用戶很不滿意；當(dāng)其特性充足（滿足用戶需求）時，無所謂滿意不滿意，用戶充其量是滿意，如婚嫁網(wǎng)站中搜索異性的功能等等。

用戶認為是理所當(dāng)然應(yīng)該存在的比方說：汽車里面的空調(diào)、車輪子

3.2 期望型需求

期望型需求（又叫績效性需求）需求提供的產(chǎn)品或服務(wù)比較優(yōu)秀。

注意期望型并不是“必須”的產(chǎn)品屬性或服務(wù)行為（有些期望型需求連用戶都不太清楚）但是是他們希望得到的。

在市場調(diào)查中，用戶談?wù)摰耐ǔＪ瞧谕托枨螅谕托枨笤诋a(chǎn)品中實現(xiàn)的越多，用戶就越滿意;當(dāng)沒有滿足這些需求時，用戶就不滿意。

例如婚嫁網(wǎng)站中除了搜索功能外，還可以為用戶在瀏覽異性的時候，根據(jù)瀏覽的異性匹配和推薦一些異性出來（根據(jù)喜好推薦）。

3.3 魅力型需求

魅力型需求要求提供給用戶一些完全出乎意料的產(chǎn)品屬性或服務(wù)行為（興奮型需求）。

魅力型需求使用戶產(chǎn)生驚喜。當(dāng)其特性不充足時，并且是無關(guān)緊要的特性，則用戶無所謂，當(dāng)產(chǎn)品提供了這類需求中的服務(wù)時，用戶就會對產(chǎn)品非常滿意，從而提高用戶的忠誠度。

比如：進入婚嫁網(wǎng)站就直接給你推送喜歡的異性，都是你中意的或超出預(yù)期的。

3.4 無差異型需求

無論提供或不提供此需求，用戶滿意度都不會有改變，用戶根本不在意。

比如：婚嫁網(wǎng)站上面提供PM2.5值、預(yù)告婚嫁網(wǎng)站上面提供物流快遞查詢等。

3.5 反向型需求

用戶根本都沒有此需求，提供后用戶滿意度反而會下降。

比如：婚戀網(wǎng)站上面提供在線離婚咨詢

4、學(xué)會探究問題的本質(zhì)

社會進程的推動，其實就是滿足需求的過程。我們來看“國家的需求是穩(wěn)定”這樣一個需求，我們該如何去探究：

• 國家需要穩(wěn)定
  • 合理的社會福利
    • 醫(yī)療
    • 社保
    • 公積金
  • 法律與執(zhí)法機器
    • 嚴格的法律
    • 警察，武警
  • 安全需求
    • 軍隊
    • 武器

互聯(lián)網(wǎng)產(chǎn)品也是基于這樣的需求大環(huán)境下被推動。
所以，思考問題是有方法的，當(dāng)我們把一些根本的東西本質(zhì)看透以后就能比較清晰的分析和思考問題了。

二、需求獲取

需求獲取的流程：明確目標 - > 選擇采集方法 - > 制定采集計劃 - > 執(zhí)行采集 - > 資料整理。

這個流程沒什么好說的。需求獲取（采集）的方法有很多中，有些我們已經(jīng)在《市場調(diào)研與分析》中講過了，除了那些，還有可用性測試、從運營等業(yè)務(wù)部門獲取等方法。

這里從需求獲取工作中單提出來3點：用戶調(diào)研、可用性測試和單項需求卡片。

1、用戶調(diào)研

1.1 用戶群細分

市場細分麥肯錫方法.png

1.2 明確目標用戶群及特征

用用戶群細分方法簡單描述我們的目標用戶群及其特征。

1.3 用戶場景及建模

用戶角色模型：新手用戶；熟練用戶；價值用戶。

其實就是對用戶進行畫像，類比與很多刑偵劇心理咨詢師對罪犯的心理測寫（這個類比好像不太合適哈），我們會對用戶的基本人口特征、需求等進行描述。下面是一個示例：

核心用戶畫像.png

我們通常會在目標用戶群中提煉出幾個典型的用戶，進行畫像。最后產(chǎn)出的用戶畫像將是后續(xù)的各種討論和決策的基本依據(jù)。

基于各種原因，我們的用戶畫像可能是會變化，這時我們就需要及時更新這些畫像。

1.4 用戶核心需求把控/目標用戶需求痛處

用戶口中所說的需求未必就是真實的需求，我們要學(xué)會把用戶需求轉(zhuǎn)化為產(chǎn)品需求。

用戶需求：用戶自以為的需求，并且經(jīng)常表達為用戶的解決方案。

產(chǎn)品需求：經(jīng)過我們的分析，找到的真實需求，并且表達為產(chǎn)品的解決方案。

所以我們所說的需求分析其實就是，從用戶提出的需求出發(fā)，找到用戶內(nèi)心真正的渴望，再轉(zhuǎn)化為產(chǎn)品需

求的過程。

2、可用性測試

可用性測試是指通過讓實際用戶使用產(chǎn)品或原型方法來發(fā)現(xiàn)界面設(shè)計中的可用性問題，通常只能做少數(shù)幾個用戶的測試，看他們怎么做，屬于典型的定性研究。

可用性測試需要注意的問題：

第一，如果可用性測試做得太晚（往往在產(chǎn)品將要上線的時候），這時發(fā)現(xiàn)問題也于事無補了。

其實，可用性測試在產(chǎn)品的各個階段都可以做。在尚無任何成型的產(chǎn)品時，可以拿競爭對手的產(chǎn)品給用戶做；在產(chǎn)品只有紙面原型的時候，可以拿著手繪的產(chǎn)品，加上紙筆給用戶做；在產(chǎn)品只有頁面 Demo 的時候，可以拿 Demo 給用戶做；更多的時候，在產(chǎn)品已經(jīng)可以運行以后，可以拿真實的產(chǎn)品給用戶做。不同階段不同做法，從中都能發(fā)現(xiàn)相應(yīng)的問題。

第二，總覺得可用性測試很專業(yè)，所以干脆不做。

可用性測試，聽著很專業(yè)，但收益又無法量化，所以對很多老板來說，不太愿意在這個上面投入資源，經(jīng)常因為項目時間過緊被略過。我們知道，可用性測試通常來說做 5 個左右的用戶才可以發(fā)現(xiàn)大部分的共性問題，前前后后的準備也耗時不少，但只做一個用戶，并且簡化步驟，也比不做要好。

第三，明確是測試產(chǎn)品，而不是測試用戶。

可用性測試要邀請用戶來做測試人員，我們在開始之前，應(yīng)當(dāng)明確地告訴用戶，這個測試的目的是發(fā)現(xiàn)軟件產(chǎn)品中的問題，而不是要測試用戶是否有能力來很好地使用軟件。所以，不要讓用戶聽到“可用性測試”的術(shù)語，而是說“來試用一下我們的 新產(chǎn)品，提點意見”。 清楚地說明這一點將有助于減輕用戶的壓力，使得他們能像在真實環(huán)境一樣來使用軟件。

第四，測試過程中，組織者該做的和不該做的。

剛開始的時候，可以告知用戶大概持續(xù)的時間，要做哪些事情，讓用戶心中有數(shù)，輕松愉快地完成任務(wù)。

可用性測試中，我們可以要求用戶在使用產(chǎn)品的過程中采用一種名為“發(fā)聲思維”的方法，即在使用產(chǎn)品的同時說出自己的思考過程，比如為了完成某個任務(wù)，用戶想先做什么，后做什么，為什么要做某個動作，等等。

做測試的過程中千萬不要有任何的引導(dǎo)與暗示，而只是觀察和記錄，因為任何引導(dǎo)都可能使得原本可以發(fā)現(xiàn)的問題無法暴露。用戶行為和預(yù)想的不一樣時，可以提問，實在進行不下去的時候，給予提示。記住，一切的錯都是產(chǎn)品和我們的錯，用戶絕對沒有錯。如果真覺得用戶錯了，那也是你找錯人了，不是這個人錯了。

結(jié)束之后，如有可能應(yīng)該送個小禮品，當(dāng)然在邀請的時候就要告訴用戶會有一些對他付出時間的補償。盡快總結(jié)，并且發(fā)給用戶，一方面讓用戶感到他做了一件有意義的事，另一方面也是表示感謝，建立長期和諧的“用戶參與產(chǎn)品設(shè)計”的氛圍。

3、單項需求卡片

單項需求卡片的理念就是： 產(chǎn)品的需求工作不只是需求分析人員的事，而是涉及產(chǎn)品的每個干系人的義務(wù)，至少得參與“采集”的過程，理想的狀態(tài)是產(chǎn)品的所有干系人都參加過“需求采集” 的培訓(xùn)，然后在日常工作中養(yǎng)成主動提交需求給產(chǎn)品人員的習(xí)慣，但實際很難做到，所以作為專業(yè)的需求分析人員，就應(yīng)該盡量降低同事們，比如銷售、服務(wù)、技術(shù)人員提交需求的成本，也是節(jié)省我們自己的時間。

一張單項需求卡片描述了一個用戶需求到底包含哪些內(nèi)容，重點是描述用戶場景，誰在什么時間、地點產(chǎn)生了何種需求。

需求卡片還有一個好處是可以存檔，可以避免后面的扯皮。為什么說這點呢，因為我曾經(jīng)吃過虧啊！o(╥﹏╥)o

這里提供一個非常簡單的模板：

需求采集表.png

三、需求評估

需求評估有2個目的：

• 評估需求合理性：不合理的一般不會進入需求列表中
• 評估需求優(yōu)先級：若需求合理，則評估其優(yōu)先級

1、需求優(yōu)先級的評估

我們把需求匯總好之后，會進行需求分析，這里會對所有的需求進行合理性的評估，結(jié)合產(chǎn)品戰(zhàn)略與市場狀況，決定哪些需求做哪些不做，匯總進產(chǎn)品需求池中。

需求優(yōu)先級的評估需要綜合考慮產(chǎn)品戰(zhàn)略、市場狀況、開發(fā)量、性價比等。其中產(chǎn)品戰(zhàn)略和市場狀況決定商業(yè)優(yōu)先級，商業(yè)優(yōu)先級和開發(fā)量決定性價比（即需求優(yōu)先級）。

需求優(yōu)先級計算公式.png

我們通常會把商業(yè)優(yōu)先級在1-5級中，1最高，5最低。開發(fā)量一般以所需開發(fā)時長來定，以N小時/人作為計量單位。

這里面有個問題，商業(yè)優(yōu)先級固定在[1,5]，但開發(fā)量的數(shù)值缺失不確定的。

舉個例子：

上面兩個需求那個優(yōu)先級高呢？

這里有幾個答案：

• 答案1：需求1和需求2優(yōu)先級一樣高；
• 答案2：如果需求1的確很重要的話，那么需求1的優(yōu)先級更高；
• 答案3：如果需求1不是非常重要的話，那么需求2的優(yōu)先級更高。

那個答案更合理呢？

在我看來，我認為答案1和答案2是合理的，答案3是一個偽命題。

對于答案3，如果需求1不是非常重要的話，我們就不應(yīng)該給它的商業(yè)優(yōu)先級定為5，定為5本身就是不合理的。

對于答案2，看起來比答案3合理多了。這里的邏輯是如果量化性價比出現(xiàn)問題的話，可以由主觀意愿介入來做決定。

其實面對這種情況，我們還有一種辦法。

前面的解決辦法其實是建立在商業(yè)優(yōu)先級和開發(fā)量的權(quán)重一樣的情況下，一旦權(quán)重不一樣，就會出現(xiàn)答案2 所說需求1的確很重要的情況。

這個時候，我們可以引入歸一化的概念，對商業(yè)優(yōu)先級和開發(fā)量進行歸一化處理，然后加上其權(quán)重。此時就變成了如下公式：

需求優(yōu)先級計算公式-加權(quán)重.png

注：w1，w2為權(quán)重，商業(yè)優(yōu)先級和開發(fā)量均經(jīng)過歸一化處理

另：我們很少會使用這種方法，了解即可。

1.1 商業(yè)價值評估

即便是已經(jīng)篩選評估出來的需求，很多時候量也是非常大的，而哪些該做，哪些不該做，很多時候我們會遇到：

• 老板拍腦袋要這么做
• 自己拍腦袋要這么做
• 顧此失彼，左顧右盼

其實，在產(chǎn)品不同階段，對需求的排序，也是有一些方法可以參考的，其實需求變通一下，和我們?nèi)粘９ぷ鞯脑u估方式是差不多的，可以分為四類：

• 重要且緊急
• 重要不緊急
• 緊急不重要
• 不緊急不重要

其實，無論需求到底是什么，產(chǎn)品終歸是商業(yè)性產(chǎn)品，所以打造產(chǎn)品的商業(yè)價值才是最重要的，所以在衡量需求的時候，最重要的衡量指標就是這個需求是否具有商業(yè)價值，商業(yè)價值越大，那么它就越重要越緊急。

商業(yè)價值也只是產(chǎn)品某一個階段的目標（有可能是一個長期的目標），基于這個目標我們會對其進行分解，當(dāng)前的需求排序，應(yīng)該最為符合當(dāng)前的目標。

商業(yè)價值的評估是個哲學(xué)性問題，需要產(chǎn)品經(jīng)理對行業(yè)和產(chǎn)品足夠理解。

1.2 開發(fā)量評估

開發(fā)量評估，其實是需要產(chǎn)品經(jīng)理根據(jù)自己公司開發(fā)人員的具體情況來定的。

但還是有些定量和定性方法可以遵循。

（1）標簽估計法

選定一個大家已知的功能，例如：上傳照片（上傳，編輯，保存等，已知該功能需要3天時間）

• 將此功能工作量設(shè)定為50

• 請研發(fā)工作人員參照這個50的系數(shù)（上傳照片工作量）對目前手中需要完成的功能工作量進行評估，并寫出他們估計的系數(shù)。

• 假定估算系數(shù)為：55（工作量和上傳照片差不多）,80（工作量稍高）,200（工作量特別大），出現(xiàn)明顯的數(shù)據(jù)差距，則說明研發(fā)人員對此功能并不理解，沒有達成一致，這個時候則需要：

  • PM邀請成員進一步明確需求，理清功能

• 如果估算系數(shù)表現(xiàn)為：80,100,90，則說明大家意見比較統(tǒng)一（也有可能集體對需求理解錯誤，所以需要在明確一次需求），如果無誤，則可以估算出該功能耗時時間大概是在5-6天，具體時間可商議確定。

（2）實際討論法

實際討論法其實就是與研發(fā)人員通過“溝通”大家達成一種默契，即可以保質(zhì)保量的完成工作，也不至于大家熬更守夜（要注意：熬夜不是光榮的，更不是值得長期去干的事情）。

當(dāng)大家達成意見一致以后，產(chǎn)品經(jīng)理再根據(jù)討論的結(jié)果來和領(lǐng)導(dǎo)以及其他部門協(xié)調(diào)各種時間。

其實在于職場，很多時候都是一種默契，即你讓別人好過，自己也會相對好過。

（3）強制手段法

強制手段法顧名思義就是狹天子以令諸侯了，強制在某個時間點前完成。

產(chǎn)品經(jīng)理要善于去爭取各種資源，尤其是公司領(lǐng)導(dǎo)和老板，一些時候比較困難的事情可能因為老板點個頭或者一封郵件，就會變得比較好辦。

• 第一，不要總是拿老板壓人，很多時候需要先和同事溝通在自己的底線范圍內(nèi)，都爭取溝通解決。

• 如果確實對方無法在底線范圍解決，而且你對當(dāng)前任務(wù)確實相對看中，則需要想各種辦法來推動整個事情的進程，可以通過郵件，電話，當(dāng)面匯報等，向老板提請需求并說明實際情況，為什么需要由他來推動，重要在哪里，需要怎么推動等等。

• 這種情況一定注意一個原則，就是對事不對人。

（4）放棄法

規(guī)范的做法是標簽估計法，最常用的方法是實際討論法，經(jīng)常需要用到的是強制手段法。這些方法都可以解決開發(fā)量評估的問題。

這里說一個，在很多小企業(yè)或者不規(guī)范的企業(yè)中存在的問題，就是需求可能是完全由產(chǎn)品經(jīng)理來定，不會經(jīng)過需求的審核流程。這是會出現(xiàn)產(chǎn)品經(jīng)理提的合理性需求，開發(fā)不愿意做，老板也不愿意做，但需求的確是真實合理的，此時怎么辦。

一、試圖說服老板；二、老板說服不了，就放棄。

碰到這種情況，沒必要去埋怨老板和開發(fā)傻逼，因為有些東西實在是你控制不了的，產(chǎn)品經(jīng)理一定要明確這一點。

2、KANO模型

評估需求還有一個重要方法——KANO模型。

KANO模型.png

這個模型對應(yīng)到我們在第1節(jié)第3小節(jié)講到的各類需求。

使用KANO模型最簡單的方法就是考慮每個模塊或需求， 對它所屬的類型進行討論。 我們可以設(shè)計一套問卷， 對用戶進行問卷調(diào)查。

KANO建議通過對一個功能問兩個問題來確定分類。 一個問題是： 如果產(chǎn)品中有這個功能， 用戶會覺得如何？ 另一個問題是：如果功能不存在， 用戶又覺得如何？

對每個問題采用5點度量方式進行回答： A表示我喜歡這樣； B表示我期望這樣； C表示我沒有意見； D表示我可以忍受這樣； E表示我討厭這樣。

經(jīng)過訪談后， 根據(jù)歸類矩陣， 將問題進行歸類來確定需求的類型， 如圖所示。

KANO模型需求歸類矩陣.png

注： M代表Must-have， 是基本型需求； L代表Linear， 是期望型需求； E代表Exciter， 是興奮型需求； R代表Reverse， 是相反的需求； Q代表Questionable， 是可疑的結(jié)果； I代表Indifferent， 是無關(guān)緊要的。

通過上述的矩陣分析， 可以得出： 哪些是用戶需求表達時自相矛盾的； 哪些是用戶自己都不確定的； 哪些是無關(guān)緊要、 可有可無的； 哪些是必須要有的； 哪些是期望有的； 哪些是自己都沒有想到， 但用戶喜歡的（ 即興奮型需求）。

具體的評估方法就是對應(yīng)基本型需求的功能必須要做， 不能在這方面失分； 對應(yīng)期望型需求的功能選擇性做， 提高其質(zhì)量， 力爭超過競爭對手； 對應(yīng)興奮型需求的功能選擇1或2個必須做， 讓用戶尖叫。

Kano模型的優(yōu)勢和不足

結(jié)合過往的資料和自己的心得，認為在調(diào)研中，Kano模型有以下幾個優(yōu)勢：

• Kano模型可以細致全面的挖掘功能的特質(zhì)
• Kano模型可以幫助業(yè)務(wù)方在工作中排優(yōu)先級，輔助項目排期;
• Kano模型可以幫助人們擺脫“誤以為‘沒有抱怨’等于用戶滿意”的想法。

同樣，Kano模型也有它的不足：

• Kano問卷通常較長，而且從正反兩面詢問，可能會導(dǎo)致用戶感覺重復(fù)，并引情緒上的波動，若用戶受到影響沒有認真作答，則會引起數(shù)據(jù)質(zhì)量的下降。
• Kano問卷在針對產(chǎn)品屬性進行測試時，部分屬性也許并不是很好理解。
• Kano模型類似于一種定性歸類的方法，以頻數(shù)來判斷每個測試屬性的歸類，這種情況下，可能會出屬性歸類結(jié)果表中，同一屬性出現(xiàn)了不同歸類欄頻數(shù)相等或近似的情況。

由于KANO 模型存在這些不足，在運用KANO模型分析數(shù)據(jù)的時候就要注重數(shù)據(jù)收集前期的準備工作。比如在問卷設(shè)計時，把問卷盡量設(shè)計得清晰易懂、語言盡量簡單具體，避免語意產(chǎn)生歧義。同時，可以在在問卷中加入簡短且明顯的提示或說明，方便用戶順利填答。

3、一些特殊情況的需求評估

3.1 偽測試

偽測試指的是先不實現(xiàn)功能， 只提供一個按鈕鏈接或文字鏈接或圖片入口， 用戶點擊之后提示此功能正在建設(shè)當(dāng)中。 根據(jù)用戶的點擊率數(shù)據(jù)情況來決定是否實現(xiàn)該功能。

偽測試在什么情況下比較適用呢？

如果產(chǎn)品團隊和研發(fā)團隊雙方爭執(zhí)激烈， 誰也說服不了誰， 需要拿出能讓團隊彼此信服的證據(jù)，這個時候就可以采用這種方法。

但是， 必須注意的是， 先在產(chǎn)品的忠實用戶中進行灰度測試， 看點擊率情況怎么樣再做決定是否該做。

具體的評估方法就是測試用戶中有超過40%的用戶點擊或使用了， 則表明值得做。

3.2 A/B測試

AB測試比較有趣，是相對成熟的團隊，有一定用戶基礎(chǔ)的團隊使用的一種方法。

A/B測試的基本思想：

• 同時提供多個方案并行測試。
• 不同方案之間只存在一個變量， 排除其他干擾因素。
• 以某種標準判定結(jié)果優(yōu)劣， 篩出最優(yōu)方案。

3.3 新產(chǎn)品上線

新產(chǎn)品未上線時候的需求特點：沒有運營數(shù)據(jù)支撐、需求一大堆。

在產(chǎn)品研發(fā)初期，還會遇到一些非用戶需求，例如：后臺編輯的方便性、基于產(chǎn)品自身的數(shù)據(jù)反饋等。

所以其實產(chǎn)品初期更重要的是形成產(chǎn)品的框架架構(gòu)，即基本需求要打造完成。

3.4 免費型產(chǎn)品已經(jīng)上線

免費型產(chǎn)品的分類：全免費、部分免費、限時免費。

因為免費，免費產(chǎn)品都能相對獲得更多的用戶運營數(shù)據(jù)，也就是說產(chǎn)品經(jīng)理除了通過KNAO模型或者其它方式獲得需求篩選甄別排序依據(jù)外，還可以通過真實的運營數(shù)據(jù)來分析用戶的實際需求。

我們可以通過數(shù)據(jù)公式來計算用戶的期望型需求和魅力型需求：

用戶需求重要性=用戶使用率（有多少用戶用過）*功能或者內(nèi)容平均使用次數(shù)（經(jīng)常用還是偶爾用）*類別重要性權(quán)重（次功能的重要性，通過專家團隊來評估）

3.5 需求有前置/后置條件

對于一些串行的產(chǎn)品需求，例如：A之后才能是B，B之后才能使C。那么按照需求重要排序則是 A>B>C。

4、小結(jié)

還是那句話，諸行無常。今天的興奮需求也許明天就是基本需求，今天的基本需求通過改進也許就成了明天的興奮需求。大家，可以思考一下那些需求以前是興奮需求現(xiàn)在變成了基本需求。

在產(chǎn)品的生命周期中，應(yīng)該做好基礎(chǔ)需求，發(fā)現(xiàn)期望需求，創(chuàng)造興奮需求。爭取在產(chǎn)品上線的時候，就應(yīng)該有一些期望和興奮需求，這樣才能在短時間里面讓用戶發(fā)現(xiàn)產(chǎn)品的價值。

注意，對于一些拿捏的很準的需求，就請忘記KANO模型吧。產(chǎn)品經(jīng)理一定要學(xué)會靈活處理問題，很多時候可以對需求進行多重考量，而不是僅僅是套用一種方法。

產(chǎn)品經(jīng)理對需求排序的能力，會影響到整個產(chǎn)品的進度以及開發(fā)人員，所以，產(chǎn)品經(jīng)理一定要對需求排序心中有數(shù)，胸有成竹，說出道理，讓大家明白，這樣大家才能信服你，更好的與你展開合作。

有些東西說清了是什么和為什么之后，怎么做的問題就很清晰了，所以之后我會盡可能多說是什么和為什么，怎么做的問題我只會簡要說明一下方法論。

四、需求評審

一個產(chǎn)品的開發(fā)過程會經(jīng)過很多次評審，大概的順序基本是：

BRD/MRD評審→PRD/需求評審→交互設(shè)計稿評審→視覺設(shè)計稿評審→開發(fā)需求評審→測試用例評審→運營規(guī)劃評審→閉環(huán)循環(huán)

其中每個環(huán)節(jié)的評審所對應(yīng)的人員都是不同的，每個環(huán)節(jié)可能都不止評審一次。

BRD/MRD評審基本上會是產(chǎn)品經(jīng)理和老板或高層一起評審，不僅包括需求的評審，還會有對產(chǎn)品戰(zhàn)略、運營規(guī)劃等方面的評審。

PRD評審是一個多方參與的工作，涉及到老板（最好叫上他哈）、開發(fā)、設(shè)計、測試、運營等。一般我們在做出比較大粒度的PRD之后就會做一次評審，以便盡早發(fā)現(xiàn)問題。

交互設(shè)計稿評審是在PRD評審之后，由交互設(shè)計師根據(jù)產(chǎn)品需求進行設(shè)計，參與方為：交互設(shè)計師、產(chǎn)品經(jīng)理等。

視覺設(shè)計稿評審是由UI設(shè)計師根據(jù)產(chǎn)品需求和交互設(shè)計稿進行設(shè)計，參與方為：UI設(shè)計師、產(chǎn)品經(jīng)理、交互設(shè)計師等。

開發(fā)需求評審是開發(fā)接到產(chǎn)品需求后，將產(chǎn)品需求轉(zhuǎn)化為開發(fā)需求，一般是在研發(fā)人員內(nèi)部進行評審，當(dāng)然產(chǎn)品經(jīng)理也可以參與。我的建議是最好參與進來。

測試用例評審，俗稱TC評審，是測試人員根據(jù)產(chǎn)品需求對每一個需求寫測試用例，測試會根據(jù)測試用例進行測試工作。此階段的參與方為：測試、開發(fā)、產(chǎn)品。

運營規(guī)劃評審是由運營人員產(chǎn)出運營規(guī)劃后對規(guī)劃進行的評審，參與方為：運營、產(chǎn)品、老板等。

對于由產(chǎn)品經(jīng)理主導(dǎo)的評審會議，我們要注意以下問題：

開會前要注意幾點：

• 開會前，最好能有一份會議議程給大家，然后大家提前熟悉一下，讓大家?guī)е鴨栴}來開會。
• 或者，開會的時候，先請大家過一遍內(nèi)容等。
• 再或者，是開會開始的時候，產(chǎn)品經(jīng)理先定一個基調(diào)，講一下背景等等。

開會過程中要鼓勵大家多提問題：

• 注意只要與會人員能放開提問題就是好事兒，這樣能打消團隊成員的疑慮。
• 也可以把沒有想明白的東西提出來大家一起討論

這里面涉及一個團隊決策的問題，需要我們需注意：

在做團隊討論時，產(chǎn)品經(jīng)理的思路很有可能會被淹沒在團隊決策中，產(chǎn)品變得四不像，這非常考驗產(chǎn)品經(jīng)理的拿捏以及決策能力和定力。

因為，團隊討論很有可能是每個參與者會“略微”站在自己的維度考慮問題，例如技術(shù)研發(fā)人員可能會考慮工作量，市場人員可能會考慮銷售指標等，他們會選擇對他們有利的方式，但不一定對產(chǎn)品有利。

因此，我們雖然提倡團隊討論，但決策還有要由我們自己來做。

五、需求管理

1、需求管理池

這里提供一個簡易模板。

任何一個環(huán)節(jié)delay，都會導(dǎo)致整個項目的delay，因此，我們需要時刻關(guān)注一些時間和進度性質(zhì)的字段，把控項目進展。

2、需求變更

幾乎很少有從頭到尾都不變更需求的產(chǎn)品，產(chǎn)品經(jīng)理對于需求變更的控制也是貫穿到產(chǎn)品始終的。

很多需求變更都是通過口頭溝通的，但是我們最好要做好書面記錄（甩鍋必備）。

這里也提供一個簡易模板。

小結(jié)

到這里，我們對需求分析與管理的講解就算完成了。原稿大概是2萬字，但有太多廢話，所以刪減到了現(xiàn)在9千字左右的精華版本。

需求分析的方法論不止以上這些，但我們?nèi)粘９ぷ鞒Ｓ玫幕揪褪潜疚乃v的了，我上面所提到的很多細節(jié)都是非常需要大家注意的。

本來打算把MRD和PRD也放在這里的，但這樣篇幅太長了，因此我把這些放在下一篇講。