產品經理每天要接觸到各種不同的需求。要對這些需求進行分析，才能更好地了解問題，從而制定相應的解決方案。那么，怎么做需求分析呢？一、需求的選擇很重要需求的選擇，是前置選擇，先做了選擇，才會有對應的結果，才會知道這個需求的價值是高還是低。在我們做出選擇之前，每一個需求對應的價值，都是未知的，即使在我們做出選擇以后，也只能通

每天5分鐘，你也可以成為優秀的產品經理 。你好，我是郭杉。歡迎來到 《郭杉 產品經理50講 》第22講。 正式開始今天的內容之前，我想先問你一個問題，你會整理用戶反饋嗎？你肯定會說：“這個問題也太簡單了吧。直接收集匯總用戶反饋不就完事兒”。真的是這樣嗎？真的就像我們想象的這么簡單？但如果真的是這

當接到一個功能需求，你通過主觀判斷不需要滿足時，該拿什么來支撐你的說法呢?“需求不是無中生有的，有需才有求”，所以你只圍繞“需求不合理”來說服別人，是很難達到效果的，你需要一套思維邏輯組合拳還給提需求的人，才能讓其信服。下面，我們就一起來看看產品經理該如何快速對需求進行分析?軟性分析需求來源是否可靠?不要誰的需求都聽，

編輯導語：可能大家也都聽說過“第一性原理”，在前兩年這個詞開始火起來是因為“鋼鐵俠”伊隆·馬斯克經常用這個詞來解釋他的創業思路。但產品經理該如何通過第一性原理進行需求分析？本文就此問題作出了解答。推薦對第一性原理感興趣的用戶閱讀。一、目的寫這篇文章的目的有兩個：一是總結一下個人的經驗方法，二是闡述一下對于需求分析的理解

繼續接著 上篇文章 的內容，來看看需求轉化階段的一些工作內容。 交互設計圖完善后，還需要編寫系統需求文檔。這里類似于C端PM的PRD工作。基于交互圖，指出某一功能在某一場景下的操作步驟和結果。但需要注意的是，系統需求文檔還需要給出一些基本的技術參數，如查詢功能的響應時間要求、底層結構的

上篇文章 給大家分享了B端產品經理的需求整理工作，整理完需求之后，接下來就是需求轉化了。 03 需求轉化 在整理好需求矩陣后，我們可以開始需求轉化了。說白了就是寫文檔，畫原型。需要注意的是，與C端PM需要編寫的PRD不同，B端PM需要編寫兩個文檔，一個是用戶場景需求文檔，一個是系統需求文檔。

上篇文章 給大家分享了兩種實用的需求整理方法，下面就繼續看看另外兩種方法。 3. 基于緊急程度進行整理 這里可以采用大名鼎鼎的四象限法則進行整理，舉例如下： （皮一下不要當真）4. 基于整體性進行整理 基于完整性的整理意味著，在整理需求時，我們不僅要能夠看到產品的細節，還要能夠看到產品的宏

上篇文章 給大家簡單分享了需求收集的方法，接下來就看看如何整理需求。 02 需求整理 對于需求整理，核心是從大量需求中挑出需求，然后按優先級排列。 關于優先級，作者有一點想法。我曾經在一篇前輩的文章中看到一種優先級的做法，即根據百分比系統對需求進行評分，高分的優先級很高。后來，我

在一些的PM論壇上，C端產品的需求分析和指導文章非常常見，許多大牛對C端產品的需求分析提出了自己的有針對性的看法。本文，作者結合自己的實際工作經驗，分享了B端產品設計早期需求分析的經驗，供大家共同學習和交流。 筆者將從三個步驟對需求分析進行討論，即需求收集、需求整理和需求轉化。 01 需求收