- 產(chǎn)品經(jīng)理的價值：聽取用戶需求表述（但不要照著做），經(jīng)過分析，把用戶需求轉(zhuǎn)化為產(chǎn)品需求（滿足用戶的本質(zhì)需求而不是口頭上的表象），千萬不能當用戶的“傳聲筒”。
- 用戶與客戶的區(qū)別：用戶是使用產(chǎn)品的人--User；客戶是購買產(chǎn)品的人--Customer。兩者可以互相交叉。例如老板買軟件，老板是管理員用戶。
- 需求采集方法：用戶訪談、調(diào)查問卷、可用性測試、數(shù)據(jù)分析
一、用戶訪談（定性的說）：單個用戶訪談、焦點小組
問題1：用戶說的和做的不一致。例如用戶說喜歡黃色的衣服、而買的時候缺買的灰色。
對策1：盡量讓用戶做一次，以驗證說法；區(qū)分用戶說的事實和觀點，如“做了什么、步驟如何、遇到什么問題”比較可信，而“我覺得、我認為”則需要慎重，帶著問號去聽。
問題2：樣本少，以偏概全。例如訪談對象都是男性、都是某個地區(qū)子公司的員工。
對策2：識別可能引起偏差的因素，操作時避免或報告中標明；用增量的方式訪談，例如先訪談5個用戶，得出基本結(jié)論，再訪談5個用戶驗證結(jié)論是否有變，若有變動則反復(fù)上一過程，若沒有變動則結(jié)束訪談，節(jié)省成本。
問題3：用戶過于健談，訪談話題偏題或描述過于冗長
對策3：及時扳回來，如果多次無效就結(jié)束，換下一個。
問題4：我們過于健談，用戶被說服，真實想法無法表達
對策4：牢記訪談目的和主題，管住嘴。
二、調(diào)查問卷（定量的說）：通過訪談的開放式問題和溝通為問卷采集設(shè)計封閉式問題
問題1：樣本偏差，即樣本與想了解的目標用戶群體出現(xiàn)偏差。
對策1：盡量覆蓋各類型用戶，如年齡、性別、行業(yè)、收入等；保證各類型用戶的樣本比例接近全體比例，如用戶中男女比例為7：3，那么樣本也應(yīng)該保持這個比例；標明調(diào)研約束和限制條件等篩選條件；把目標群體特征定義成一系列問題，放入問卷，以便篩選使用和調(diào)整比例偏差。
問題2：樣本總量過少。
對策2：報告中只能說“5個用戶中3個選擇了A”，除了補充外沒其他太好辦法，統(tǒng)計意義不大。
三、可用性測試（定性的做）：讓測試用戶通過使用產(chǎn)品或原型來發(fā)現(xiàn)界面設(shè)計中的可用性問題，通常只需要少數(shù)幾個用戶，觀察用戶怎么做，并不時詢問、記錄問題。
問題1：做的太晚，即使發(fā)現(xiàn)問題也來不及修正了。
對策1：產(chǎn)品的各個階段都可以做，從原型有了交互行為開始，各功能測試、版本上線都可以抓很少的1，2個用戶盡早的做。
問題2：組織者說的過多或帶有引導(dǎo)性，影響用戶自主性和操作真實性。
對策2：少說多看，管住嘴，多提問，多記錄，時候討論。
四、數(shù)據(jù)分析（定量的做）：用戶的操作日志、后臺管理系統(tǒng)日志、訪問信息。
問題1：統(tǒng)計使用不得當而誤讀數(shù)據(jù)。
對策1：統(tǒng)計學知識補充，?；仡櫋z查。
問題2：平時不下功夫，臨時抱佛腳。
對策2：數(shù)據(jù)采集要從產(chǎn)品設(shè)計時就考慮進去，方式、途徑、內(nèi)容、頻次，以及重要的檢測點和檢測對象設(shè)定。
-
一手需求VS二手需求
一手需求類似“生孩子”：在產(chǎn)品誕生前，沒有用戶使用，由產(chǎn)品人員驅(qū)動，發(fā)揮空間大，是從潛在用戶那里“拉”來的需求。
二手需求類似“養(yǎng)孩子”：已經(jīng)運行的產(chǎn)品，用戶已經(jīng)在使用，由用戶驅(qū)動，按需改進，是已有客戶“推”給產(chǎn)品的需求。 -
需求采集的補充方法
現(xiàn)場調(diào)查：融入業(yè)務(wù)一線，需要一定時間。
AB測試：基于大用戶量使用。
日記研究：互聯(lián)網(wǎng)新興個人應(yīng)用，往往是同行意見。
卡片分類法：把需求單獨寫在便利貼上，讓用戶去分類，了解用戶是怎么給產(chǎn)品劃分模塊的。
自己提需求：自己用自己的產(chǎn)品。 -
用戶需求VS產(chǎn)品需求
用戶需求：用戶自以為的需求，經(jīng)常表達為用戶的解決方案。
產(chǎn)品需求：經(jīng)過產(chǎn)品人員的分析，找到的真實用戶需求，并且表達為產(chǎn)品的解決方案。
示例：用戶說我想加其他人為好友，其他仔細詢問過后才知道他想得到其他人的文章更新提示，因此產(chǎn)品中增加“訂閱用戶新文章功能”就夠了。 - 需求分析過程就是把用戶零散的真實需求，分類抽象提煉為最終用戶需求，轉(zhuǎn)換為對應(yīng)產(chǎn)品功能，指導(dǎo)開發(fā)。
-
滿足需求的三種方式
改變現(xiàn)狀：開發(fā)或更新產(chǎn)品功能，最笨。
降低理想；“打預(yù)防針”、“丑話說在前頭”等。
轉(zhuǎn)移需求：引導(dǎo)用戶關(guān)注更重要的功能。 -
需求的檢查過程
相應(yīng)工具見《用戶需求清單》《產(chǎn)品需求清單》《需求開發(fā)清單》
- 需求的生老病死
- 一個需求的奮斗史
Tips
- 以用戶為設(shè)計指導(dǎo)、以老板為實際出發(fā)，協(xié)助老板更好的實現(xiàn)用戶價值。
- 要根據(jù)重要程度將用戶進行分類排序，不同程度的滿足，畢竟資源和約束限制是必定要考量的。
- 用戶需求優(yōu)先級應(yīng)該結(jié)合商業(yè)目標作出評價和甄選。
- 產(chǎn)品需求規(guī)劃的各階段目標和用戶主體不同，因此需要動態(tài)調(diào)整用戶需求優(yōu)先級。
- 比用戶說的和做的更重要的是背后的原因，多向用戶問為什么，刨根問底。
- 避免讓用戶設(shè)計產(chǎn)品功能或與用戶討論技術(shù)實現(xiàn)細節(jié)，抓住訪談主題和目的。
- 鼓勵用戶以故事的方式講出來，是最好理解用戶的方式。
- 無論線上還是線下問卷，最好不要超過10分鐘，自己要先測試答一下。
- 問卷開篇問題應(yīng)簡單、少思考；中篇應(yīng)重點、需思考、較敏感；末篇應(yīng)個人信息。
- 樣本總量少時，使用百分比分析是沒有意義的，結(jié)果不穩(wěn)定；要使用百分比的話，最好約有100份有效的調(diào)研結(jié)果。
- 問卷表述應(yīng)無引導(dǎo)性，與用戶訪談類似。
- 對于重要的問卷，需采用先小范圍試答，根據(jù)反饋修改后，再大面積投放的方式，類似產(chǎn)品的灰度發(fā)布。
- 招募測試用戶時應(yīng)盡可能貼近真實用戶群體。
- 可用性測試前組織者應(yīng)給用戶準備好一系列典型、重要、頻繁操作的業(yè)務(wù)。
- 改版上線前的可用性測試和AB測試很重要，需要給自己留退路。
- 在一個團隊里，應(yīng)統(tǒng)一一種記錄用戶需求的形式，如mindmap。
- 用戶需求和產(chǎn)品需求可能出現(xiàn)多對多情況，因此需要在《用戶需求清單》給用戶需求編號，在《產(chǎn)品需求清單》中標注對應(yīng)用戶需求；產(chǎn)品需求也應(yīng)在《產(chǎn)品需求清單》中編號，在《需求開發(fā)清單》中標注對應(yīng)的產(chǎn)品需求。
- 做項目的終極目標：多快好省。范圍大、時間短、品質(zhì)高、資源省。
敏捷迭代、一般2-4周，把類似的功能點、業(yè)務(wù)邏輯上關(guān)系密切的放在一次迭代中。 - 功能互相之間依賴。那些只能先做的功能，應(yīng)該在產(chǎn)品需求列表里注明；功能與人力資源之間的依賴關(guān)系也會經(jīng)常存在，比如有些功能只能由團隊里的特定成員來做。
- 需求的粒度大小。商業(yè)價值很高的功能，如果細分的話，會發(fā)現(xiàn)其中也有價值相對低的部分，所以需求的粒度應(yīng)該盡量細，前提是細化引起的管理成本上升在可接受的范圍內(nèi)。經(jīng)驗是，在需求列表里出現(xiàn)的任意一行，工作量最好不要超過5人天。
- 情愿把一半的功能盡可能完美也不要把全部功能做成半吊子。
