人人都是產品經理
需求
- 用戶是需求之源，常用需求採集方式：數據分析、調查問卷、用戶訪談，可用性測試等
- 聽用戶的但不要照着做，明確產品經理的價值，把用戶需求轉化爲產品需求，即需求分析，確定需求的基本屬性，分析商業價值，評估實現難度，從而計算出需求的性價比
- 資源有限，進行需求篩選，有時候只能做高性價比的需求
- 需求管理，相關需求文檔，用例文檔
- 發現一個問題，設法將其轉化爲一個任務來解決
需求採集人人有責，儘可能多地採集
用戶訪談常見問題
- 用戶說的問題可能跟實際有偏差
- 樣本少，以偏蓋全的問題，儘量隨機
- 用戶過於強勢，訪談被帶偏
- 我們過於強勢，把用戶帶偏
牢記訪談目的，圍繞訪談目的聊，避免誘導性問題
用戶大會
邀請用戶到某一集中地點開發，耗費資源較多，要充分利用
- 明確目的
- 資源確定， 時間，地點
- 現場執行
- 結束以後
調查問卷
- 樣本要具有代表性
- 樣本較少時，百分比分析沒有意義
- 問卷內容細節，不要有引導性，總要問卷應該先小範圍試答，然後根據反饋修改後再大面積投放
可用性測試
可用性測試：通過讓實際用戶使用產品或原型方法來發現界面設計中的可用性問題，通常只能做少數幾個用戶的測試，屬於典型的定性研究。
對於改版升級，要把“暴力革命”變成溫柔和諧的“和平演變”
數據分析
數據分析時，根據不同的目的，數據來源多種多樣，常見的有用戶使用產品的日 志、客戶管理系統裏的信息、網頁訪問情況的統計信息等
需求採集方法
- 現場調查
- AB測試，基於大用戶量比較合適
- 日記研究，互聯網新興的個人應用比較適合，很多業內朋友會寫一些對於新產品的使用體會
- 卡片分類法，把產品的各種需求寫在便利貼上，讓用戶一起討論並完成分類
- 用戶自己提需求，每個靠譜的產品都有一羣粉絲用戶，他們會主動提需求，要提供相關反饋渠道
用戶需求VS產品需求
用戶需求：用戶自以爲的需求
產品需求：經過分析，找到的真實需求，並且表達爲產品的解決方案
需求分析：從用戶提出的需求出發，找到用戶內心真正的渴望，再轉化爲產品需求的過程。
銷售人員常說：用戶是爲想要的東西買單，而不是需要的
滿足需求的三種方式
需求來源於理想和現實的差距，那麼減少這個差距就有3種方式
- 改變現狀
- 降低理想
- 轉移需求
創造需求，提供更優質的產品
需求的種類
| 需求屬性 | 屬性說明 |
|---|---|
| 分類 | 新增功能、功能改進、體驗提升、Bug修復、內部需求 |
| 層次 | 基礎、擴展（期望需求）、增值（興奮需求） |
其實產品需求遠非我們直接可以想到的功能需求，還包括了很多非功能需求，比 如：性能、可培訓、可維護、可擴展……有很多需求不是爲終端用戶做的，而是爲銷 售、服務、測試團隊的同學做的
層次：把需求分成“基礎、擴展（期望需求）、增值（興奮需求）”三層，理論 依據參見KANO模型
KANO 模型以東京理工大學教授狩野紀昭（Noriaki Kano）的名字命名，是一種對顧客需求或者說對績效指標的 分類，通常在滿意度評價工作前期作爲輔助研究模型，KANO 模型的目的是通過對顧客的不同需求進行區分處 理，幫助企業找出提高企業顧客滿意度的切入點。
需求的商業價值
任何一個需求都要滿足一定的商業目的，商業價值極其重要，可用重要性、緊急度、持續時間3個指標來衡量。
重要性：可以參考時間管理裏“重要與緊急”的概念。這裏的重要度又可細分爲： 滿足後“一般”到“非常高興”；未實現“略感遺憾”到“非常懊惱”，更多可以學 習 KANO 模型加深理解。
緊急度：在時間維度上判斷這個需求是否迫切，緊急不重要的需求通常表現爲解
決了短期的問題，如果熬過去沒做，對長期影響不大；或者解決了局部的問題，如果 不做對於大多數用戶沒有影響。比如某個用戶是大老闆的朋友，通過大老闆“天外飛 仙”地提過來一個需求，就很可能是一個超級緊急的需求，但重要性未必很高。
持續時間：需求是有生命的，有的長壽有的短壽，比如迎合過年過節的運營活動 需求，一般就比較短壽。試想 8 月我們錄入了一個慶國慶的主題運營活動，如果到了 9 月底還沒資源做，那一年內也就不用再考慮這個需求了。
初評需求的實現難度
大部分情況下需要考慮人力成本，即工作量，又時會考慮資源的消耗，如額外的硬件成本。
工作量瓶頸多表現爲 開發量，需要技術經理評估。
需求的性價比
性價比 = 商業價值÷實現難度（簡化爲開發量
需求篩選
小團隊多采用按產品線劃分，產品經理按自己想法做
大團隊可以按職能線劃分，對多個產品間的資源共享有利，但是效率不高，激勵產品經理
鮎魚效應即採取一種手段或措施，刺激一些企業活躍起來投入到市場中積極參與競爭，從而激活市場中的同行業 企業。其實質是一種負向激勵，是激活員工隊伍之奧祕。
準備出發-需求打包
- 需求打包最好打包類似的功能點，可通過業務邏輯圖的方式可視化展示
- 需求依賴，功能相互之間有依賴關係，組建團隊的時候要重點考慮
- 需求的粒度大小問題，需求的顆粒度要儘量細
商業需求文檔
我們剛剛把需求打好包，接下來就要描述一下這個包了，這就是商業需求文檔， Business Requirement Document，簡稱 BRD，它也是我們參加資源爭奪戰的武器。
BRD怎麼寫？
- 項目背景:我們在哪裏，爲什麼做，解決什麼問題
- 商業價值：我們去哪裏？最關鍵的重點，項目完成後有什麼價值，可預測相關數字的變化，提出這個項目的商業目標
- 功能需求描述：我們怎麼去，通過哪些事情來達到目標，最好能畫出業務邏輯關係
- 非功能需求描述：如運維、分析用需求
- 資源評估：項目成本
- 風險和對策：潛在的風險
ps ：少做就是多做，做得少不如做的巧，性價比，產出價值>投入是根本