一、需求來源

以用戶為中心的思想，但也不要試圖滿足所有用戶

1.1用戶是需求之源

• 人類為什么有需求

生活中有很多不滿意（現(xiàn)實與理想的差距）
需求：去減少或者消除差距

• 用戶VS客戶：

用戶是User，有時也叫做終端用戶，End User，是使用產(chǎn)品的人；
客戶是Customer，是購買產(chǎn)品的人、為產(chǎn)品付錢的人

• 以用戶為中心的思想&不要試圖滿足所有用戶

• 需求的本質(zhì)就是“問題”，問題的本質(zhì)就是“理想與現(xiàn)實的差距”。作為產(chǎn)品經(jīng)理，我們每天都在設(shè)法滿足用戶的需求，其實就是在解決各種各樣的問題。
• 優(yōu)先滿足哪些用戶需要和產(chǎn)品的商業(yè)目標要結(jié)合起來考慮，簡單說就是看KPI是什么，值得注意的是，不要把KPI狹義地理解成一些數(shù)字，可以把它想象成一種綜合的指標，也可以包含客戶的滿意、員工的開心等。

1.2你真的了解用戶嗎

• 體會真實的用戶：空想是無用的

• 試著描述用戶：Persona

• 用戶研究

橫向，用戶的說和做：怎么說表現(xiàn)了目標和觀點，怎么做反映了行為，用戶怎么說和怎么做經(jīng)常是不一致的。
縱向，定性與定量：定性研究可以找出原因，偏向于了解；而定量研究可以發(fā)現(xiàn)現(xiàn)象，偏向于證實。

具體來說
第一輪，聽用戶定性地說，確定產(chǎn)品方向，做什么？隨機抽樣40個用戶做訪談，據(jù)此寫出需求列表。
第二輪，聽用戶定量地說，確定需求優(yōu)先級，先做什么？投放了20萬份調(diào)查問卷，確定了需求優(yōu)先級的排序。
第三輪，看用戶定性地做，要先做的那幾個需求，應(yīng)該怎么做？一邊設(shè)計，一邊陸續(xù)找了10個用戶來驗證，做可用性測試。
第四輪，看用戶定量地做，根據(jù)產(chǎn)品的用戶使用情況做數(shù)據(jù)分析，不斷改進產(chǎn)品。

二、需求采集

• 需求采集過程：

明確目標、選擇采集方法、制定采集計劃、執(zhí)行采集、資料整理，然后進入下一步的需求分析階段。

2.1 用戶訪談

• 用戶訪談常見問題&策略

1. 說和做不一致
   a. 一邊交互一邊訪談
   b. 區(qū)分用戶說的事實or觀點
2. 樣本少，以偏概全
   a. 隨機
   b. 識別偏差因素&標注在報告里
   c. 增量式訪談
3. 用戶過于強勢：要把控訪談方向&進度
   4.我們過于強勢：牢記訪談目的&管好自己的嘴

• 用戶訪談注意點
  1.避免一組固定的問題
  2.首先關(guān)注目標，任務(wù)其次
  3.避免讓用戶成為設(shè)計師
  4.避免討論技術(shù)
  5.鼓勵講故事
  6.避免誘導(dǎo)性問題

2.2 調(diào)查問卷

• 調(diào)查問卷常見問題&策略
  1.樣本偏差
  a. 識別偏差因素&標注在報告里
  b. 目標群體特征定義成問題，回收時再篩選
  2.樣本過少：增加樣本
  3.內(nèi)容細節(jié)問題
  a. 無引導(dǎo)性
  b. 準備答案順序不同的問卷
  c. 小范圍試答，再大面積投放

2.3 可用性測試

• 流程
  1.招募測試用戶：代表將來真實的用戶
  2.準備測試任務(wù)：實際使用中的典型任務(wù)
  3.測試過程：用戶通過使用產(chǎn)品來完成所要求的任務(wù)，同時組織者在一旁觀察用戶操作的全過程，并把發(fā)現(xiàn)的問題記錄下來。
  4.測試結(jié)束后：組織者可以詢問用戶對于產(chǎn)品整體的主觀看法或感覺。另外，如果用戶在測試的過程中沒有完全把思考的過程說出來，此時也可以詢問他們當時的想法，詢問他們?yōu)槭裁醋龀瞿切┎僮鳌?/li>
• 可用性測試常見問題&策略
  1.如果可用性測試做得太晚（往往在產(chǎn)品將要上線的時候）：什么時候都能做
  2.總覺得可用性測試很專業(yè)，所以干脆不做。（杜絕）
  3.明確是測試產(chǎn)品，而不是測試用戶。
  4.測試過程中，組織者該做的和不該做的。
  該做的：持續(xù)時間；要做什么；觀察&記錄；小禮物
  不該做的：引導(dǎo)&暗示

2.4 數(shù)據(jù)分析

• 數(shù)據(jù)分析常見問題&策略

1. 過于學(xué)術(shù)，沉迷于“科學(xué)研究”。
   一切的一切需要的只是一種感覺，一種對數(shù)據(jù)的敏感，對商業(yè)的敏感。
2. 雖然數(shù)據(jù)不會主動騙人，但我們經(jīng)常無意或有意地誤讀數(shù)據(jù)。
   a. 無意地誤讀數(shù)據(jù)，這個問題的對策，是學(xué)習(xí)統(tǒng)計學(xué)的知識，努力提高自己的水平。
   b. 主動地誤讀數(shù)據(jù)，一個簡單的對策就是對數(shù)據(jù)保持中立的態(tài)度，盡量不要“為了迎合一個觀點而去找數(shù)據(jù)”，減少利益牽扯。
3. 平時不燒香，臨時抱佛腳。
   在產(chǎn)品設(shè)計的時候就把數(shù)據(jù)分析的需求加進去

2.5 需求采集方法

1. 現(xiàn)場調(diào)查
2. AB測試
3. 日記研究
4. 卡片分類法
5. 自己提需求

三、需求評審

3.1明確我們的價值

用戶跟福特要一匹更快的馬，福特卻給了用戶一輛車。這就是我們存在的價值。

• 用戶需求VS產(chǎn)品需求

用戶需求：用戶自以為的需求，并且經(jīng)常表達為用戶的解決方案。
產(chǎn)品需求：經(jīng)過我們的分析，找到的真實需求，并且表達為產(chǎn)品的解決方案。
需求分析：從用戶提出的需求出發(fā)，找到用戶內(nèi)心真正的渴望，再轉(zhuǎn)化為產(chǎn)品需求的過程?！咀ⅲ?a target="_blank" rel="nofollow">“Y理論”】

需求分析的Y

小秦出現(xiàn)了，他說要吃牛肉火鍋（用戶需求），160，他碰到了小張。
“真的想吃？”
“想吃！”
“為什么？”
“我餓了……”（找到了本質(zhì)?。?br> “哦，這里是兩個饅頭（產(chǎn)品需求），請你吃，才1塊錢?！?/p>

“……”
小秦無比不爽，但沒辦法，真的餓，還是吃了。
小張是這樣分析的，想吃牛肉火鍋，這個用戶需求無非兩個原因——餓了或者饞了。如果他真的是饞了，那就吃吧，不過如果是餓了，那我完全可以用一個低成本的解決方案——饅頭。雖然小秦眉頭緊鎖，但現(xiàn)在經(jīng)濟不景氣，畢竟節(jié)省了98.75%的成本啊！

• 滿足需求的三種方式

1. 提高現(xiàn)實：去開發(fā)
2. 降低理想：不要忽略嘴遁的力量
3. 轉(zhuǎn)移需求：尋找更強烈的需求

• 創(chuàng)造需求

我們千萬不要——沒有喬布斯的命，卻有喬布斯的“病”！

3.2 給需求來次DNA檢測

檢測流程

• 用戶需求—>產(chǎn)品需求
• 確定需求的基本屬性：編號；提交人；提交時間；模塊；名稱；描述；提出者；BUG編號；...
• 需求分類：性能需求；維護需求；運營需求；功能需求；...
• 需求層次：基礎(chǔ)；期望需求；興奮需求；【注：“KANO模型”】
• 需求的商業(yè)價值：重要性；緊急度；持續(xù)時間；【注：“如何對一個需求做價值判斷”】
• 需求實現(xiàn)難度：開發(fā)量；

• 性價比=商業(yè)價值：實現(xiàn)難度

  
  
  
  
  一個需求的DNA

四、需求篩選

4.1需求PK

做項目，終極目標就是：多快好省，即范圍大、時間短、品質(zhì)高、資源省。互聯(lián)網(wǎng)、軟件項目，比較推崇敏捷方法，所以有比較固定的項目時間，專業(yè)點叫“迭代周期”

1. 需求打包：業(yè)務(wù)邏輯圖
2. 需求依賴，功能之間的相互依賴
3. 需求粒度大小問題

• 產(chǎn)品會議

商業(yè)需求文檔BRD：項目背景；商業(yè)價值；功能需求描述；非功能需求描述；資源評估；風(fēng)險和對策；

4.2做精不做多

情愿把一半的功能做到盡可能完美也不要把全部功能都做成半吊子。

• 做得少不如做的巧
• 問題基本解決
• 盡可能的多放棄

五、與需求同行

產(chǎn)品反復(fù)地經(jīng)歷著需求采集、需求分析、需求篩選的過程，不斷進化。

5.1 需求的生老病死

5.2 需求的管理

• 統(tǒng)計每個“提交人”的需求數(shù)量
• 統(tǒng)計“提交時間”、“發(fā)布時間”等信息
• 統(tǒng)計每個“模塊”的需求數(shù)量
• 統(tǒng)計每個“分類”的需求數(shù)量

5.3 永遠保持對產(chǎn)品的熱愛——和需求一起奮斗

一個需求的奮斗史