第二章從需求採集開始講，一直講到產品專案需要實現那些對應的需求。
需求從使用者中採集，最終又服務於使用者，而產品經理在這過程中需要提取使用者的需求，並將其轉化為公司的產品，另一方面，也可以替使用者提需求完善產品。而在這過程中的乙個核心思想是「以使用者為中心」，這裡說的是以使用者為核心，而不是以客戶，客戶一般指購買產品的人，但是不一定是最終使用產品的人，比如某些經銷商購買產品，但是他們其實並不使用。
需求分析的具體方法
產品經理需要了解使用者，通過不斷地接觸最終制定出乙個「使用者畫像」，即目標使用者需要有的一些基本特點。深入一點的就是使用者研究，使用者研究可以分為使用者的說和做，定性分析與定量分析四個方向。將需求採集與使用者研究結合，按以下步驟：明確目標，選擇採集方法，制定採集計畫，執行採集，資料整理。
一手需求從使用者直接產生，可以分為以下幾類採集方法：
使用者訪談（說+定性）：適合開放式問題，注意使用者「說」和「做」不一致的問題，另外需要注意樣本採集不要以偏概全，或者在報告中說明樣本的取樣問題。
調查問卷（說+定量）：適合封閉式問題，作答時間最好不超過10min；需要思考的問題一般放中間；關於被訪者個人資訊的題目一般放最後；同時需要注意樣本偏差、樣本過少的問題，還有調查問卷的內容細節問題，例如選項的排列方式等。可以採用灰度發布的方式設計乙份調查問卷，即先小規模投放，再修改調查問卷，最終大規模投放。
可用性測試（做+定性）：可用性測試在產品的各個階段都應該做，而不是到最後才做。
資料分析（做+定量）：資料最能說明問題，但是需要注意的是，在產品設計階段就需要考慮資料分析的問題，而不是臨時抱佛腳。
二手需求可能從其他同事那裡產生，可以有以下幾種方法：
單項需求卡片，現場調查，ab測試（測試按鈕放哪邊，先用1000個使用者測試，再決定按鈕放哪邊，類似於灰度發布），日記研究（其他同行的評價，我覺得不如改為同行評價），自己提需求。
產品經理在需求分析中要做的
產品的職責是聽使用者的並轉化為產品需求，而不是滿足使用者的所有「使用者需求」。蘇杰覺得需求分析的過程是：樹葉-樹枝-樹幹-樹幹-樹枝-樹葉的過程，即分-總-分，但是我還是不太明白，可能工作以後會有更多的理解吧。滿足乙個需求的三種方式：改變現狀，降低理想，轉移需求，我覺得pm主要還是側重於改變現狀和轉移需求兩方面吧，盡量達到四兩撥千斤的效果。
給需求做一次dna檢測，目的是為了使其對應到產品的具體實現中，即本文第一句話的後半段。本人覺得需求採集過程中的技巧性內容較多，初學者可以學習的較快，而下面才是體現產品經理重要價值的部分。
將需求轉化為產品的過程：使用者需求轉化為產品需求->確定需求基本屬性（同時確定需求的種類）->分析需求的商業價值->實現需求的難度->計算價效比
使用者需求轉化為產品需求：可以用excel做成**，每一行代表乙個需求
需求的基本屬性：主要包括編號，提交人*，提交時間，模組*，名稱*，描述*，提出者，提出時間，bug編號；乙個產品一般有5+-2個模組比較好，**產品的模組劃分會直接影響其導航結構，因此需要特殊注意。標*的一般是必填的。
需求的種類主要包括需求分類和需求層次，分類主要包括：新增功能，功能改進，體驗提公升，bug修復，內部需求等，需求層次包括：基礎，擴充套件（期望需求），增值（興奮需求）幾類，但是這些劃分方式其實沒那麼決定，很多情況需要酌情處理。
需求的商業價值：不能因為商業價值大就馬上做，也不能因為商業價值小就不做，商業價值有以下幾個維度：重要性，緊急度，持續時間，商業價值*，一般將這幾個維度抽象為乙個具體數字代表其具體價值，例如將這些因素抽象為5,4,3,2,1的五個優先順序。
實現難度：以xx人天來計算，一般以團隊中的瓶頸資源（一般為開發）為標準。
價效比：價效比=商業價值/實現難度（簡化為開發量）。
一般利用需求的價效比來確定先做哪方面工作，後做哪方面工作，但是一般也不是說商業價值越高的就先做，價值低的就後做，還取決於其他的很多因素。
將需求放入專案的實現列表中-需求的戰場
公司的組織結構方法-按產品線劃分和按職能線劃分兩種。
首先，按產品線劃分的方式適合初創團隊（貌似是現在我公司的劃分方式），以某個產品為主線，產品經理的權力更大，可以按照自己的想法做，資源有保障，產品規劃不容易改變。此外，各職能員工之間單線領導，對產品有利。
按職能線劃分（即我同事說的，正常的大公司的ued都是橫向的，這些資源是多個團隊公用的），這種方式對多個產品間的資源共享有利，可以讓資源流向更需要的地方，但是單個產品的發展速度會降低，pm和設計師為產品的發展苦苦思索，對公司有利。
在進入產品會議的戰場前需要準備的幾方面：
1、需求打包，將前述的excel需求列表中基本屬性類似的放在一起打包，之後可以將其做成乙個介面圖（即我實習的時候的那些系統劃分圖），這樣便於講解也便於理解。
2、在上述需求列表和需求介面圖中需要標明相互之間的依賴關係。
3、需求的粒度大小問題，一般需求列表中的任意一行，工作量最好不要超過5人天。
產品會議
某個產品團隊亮相的時候，一般要先回顧上一次產品會議通過的專案，現在進展如何，是否需要調整時間進度，是否需要追加資源，是否有重大的需求變更，已經發布的專案有什麼問題。
之後拿出brd，每個產品都會拿出2-3個，佔滿2-3倍的潛在資源。
重頭戲：商業需求文件brd（business requirement document）
brd包括的內容：專案背景，商業價值（最重要，做出專案以後有什麼價值，一定要說到點子上，一般還要**相關數字的變化），功能需求描述，非功能需求描述，資源評估（第二個重點，決定價效比的第二個因素），風險和對策。
情願把一般的功能做到盡可能完美也不要把全部的功能都做成半吊子！！（即讓既有的作品完美）。
至此，可以得到乙個需求的完整dna：
編號提交人*
提交時間
模組*名稱*
描述*提出者
提出時間
bug編號
分類層次
重要性緊迫度
持續時間
商業價值*
開發量*
價效比*
狀態*負責pd*
開發工程師
專案名稱
發布時間
備註最後，需求管理的最後，還可以製作出包含以下內容的**，表明產品設計過程中團隊每個人的工作量：
統計每個「提交人」的需求數量、統計「提交時間」、「發布時間」等資訊
統計每個模組的需求數量
統計每個分類的需求數量
統計需求的商業價值、價效比變化
人人都是產品經理之第二章摘要02
1.使用者研究不是附屬內容，而是前提，必須在做產品的過程中隨時納入計畫。也許，突然有一天，當你有機會去接觸使用者，卻很可能不知所措，我們到底應該找誰？通過什麼方式？聊些什麼？如何指導產品發展 其實使用者研究 市場研究 需求採集等，都是為確定產品應該有哪些功能服務的。2.使用者怎麼說表現了目標和觀點，...
人人都是產品經理
剛看完了人人都是產品經理試讀的章節，對於本書的作者設計的目錄感覺不錯。但是，從頭到尾試讀的章節中都沒讓我明白怎麼才能作為乙個好的產品經理。首先我們需要知道三個問題的答案 工作職責 工作目標 工作方向。1 產品經理的工作職責就是探索產品的價值與挖掘需求並分析可用性 可行性。2 產品經理的工作目標就是在...
人人都是產品經理
一 初識 創業公司一般的發展路徑都是產品成功，然後公升級到多產品系列和平台階段，所以任何乙個主管都要有產品思維，產品思維本質就是滿足使用者需求。網際網路時代，戰略降至一維，回歸產品。專案經理是把已經提出的問題完成，需要的是執行 計畫和控制能力。產品經理是任務的提出者，更需要創造力，也應具備專案管理能...