產品經理如何制定產品需求？
產品經理不制定需求，只是發現需求。
然後，召集一群人想盡辦法滿足這個需求。
這其實就是產品經理的本質。
感謝邀請，水平有限，希望能幫到一點是一點，給一個比較簡單粗暴的模型。
5W1H
1、需求目標WHY ：為什麼？目的是什麼？
任何需求都是因為有一個問題要解決或者一個目標要完成
【常見坑】就像解數學題，至少題乾和問題，你要清楚，很多時候，撕是因為，你和大家在題乾的信息上都不一樣。問題都沒找到，就要開始整解決方案了。
比如你的公司總戰略是為了讓用戶下單，而你們發現用戶在列表頁停留時間很長，卻跳出了，找不到需要的商品推薦，可能是推薦演算法有問題，也可能是信任問題，也可能是場景不對。
你需要在有限的時間內，定位到一個最有可能的問題來源，這需要對用戶、數據、人性（習慣）等等方面都有所積累，這也是最重要的需求分析環節，一般來說，新產品經理不太會經歷這個思考，主要是老產品告訴你，遇到了一個什麼問題，但你需要向他多請教，學習他的思考模型，並批判吸收。一切以客觀事實為依據。
2、需求場景分析：who、where、when：時間地點人物，這個需求問題發生的場景和解決問題場景是什麼?
【常見坑】產品經理脫離實際，離用戶很遠，基本靠YY，憑感覺和靠自身經驗，覺得用戶會和自己想的一樣。最後就是坑了。
比如，我們做教育產品，使用者是學生、付費者是家長，而直接加盟者是機構校長，這三個角色為什麼用我們產品，用產品的過程在哪裡，是什麼樣的用法，遇到什麼問題，他們以前是怎麼解決，解決的過程中有什麼還不太方便的地方，等等，關於用戶和產品的一切，都是需要在產品經理心中有清晰的感性畫面和理性數據的。
你需要還原用戶場景，才能更好地，找到在那樣的情況下：分清主次，優先，知道合適的用戶使用路徑。
舉個例子，我們老師端的老師，全程用我們的軟體上課，我們首先對老師進行了畫像，不同層次的老師使用軟體的方式和使用到的功能深度不同，我們在聽課的過程中，會觀察記錄所有用戶操作使用行為，並分析哪些是符合我們的設計初衷，哪些是超出我們意料之外，是我們的引導問題，還是用戶自然選擇了更優方式，是值得我們學習的。進而解決方案，可以及時現場拿出來和老師討論，並收集反饋。但這只是一條信息，不是可以直接成為方案的，也要考慮到畫像的佔比不同。
以上是產出部分，對應的是解決什麼問題，帶來多大的收益。
公司也需要盈利，對於一些解決複雜問題，需要投入大量資本，不划算的需求，是需要慎重的。
3、方案和執行上線 what、how，方案的具體步驟、如何確保順利上線
這個就不贅述了
WHAT：prd要包含的內容，HOW 如何管理版本項目，取捨優先順序，這些都是家常便飯；
核心還是在於如何分析： 是什麼支撐了我要提出這個需求。
最後一句話，其實能做產品經理的，都是聰明人，保持十萬個為什麼的好習慣，多學習，結合實際批判地吸收，適時地思考，反思，真理就越來越近了
互聯網產品崇尚小步快跑，持續迭代。如何在持續的產品研發和運營過程中，對產品做好日常管理規劃？
產品的生命周期一般都比較長，在持續的產品研發和運營過程，都要對產品做好日常管理。而做互聯網產品不像工廠生產產品那樣，可以流水線操作，需要產品團隊付出努力，一起協作去把產品管理好。在這個管理過程當中，很多其實都是日常的一些工作方式的，只不過從產品的角度結合起來。每個團隊都會有自己的一套管理產品的方式和方法，從目前的產品環境來看，有一些管理策略已經逐漸被大家所認可和接受，主要是以下幾個方面，不過看之前要注意，管理策略都是沒有最好只有最合適的。
清晰的產品規劃
產品規劃是產品持續研發和運營過程的風向標，先期的投入和後期的改進都會圍繞產品規劃來實現。產品規劃需要清晰的交代產品是什麼，說明產品的核心價值，確定產品的範圍，表明產品的戰略目標，以及你所想通過這個產品所達到的目的；以及產品的各種特性和功能，產品中所包含的任何一個功能都應該是有理有據的。總的來說，產品規劃要從用戶需求、產品目標、產品的功能組合和內容需求方面，明確的描繪產品的形態和框架。
以互聯網產品的發展速度來說，一個季度或者半年的產品規劃是較為合適的，某些產品也可以是全年的規劃，但最長不要超過一年，超過一年的規劃會顯得不切實際，技術是日新月異的，產品需求也在不停的變化，雖然小的需求變化不至於導致需要調整整體規劃，但時間太久了就不好說了。從過往的產品經驗來看，採用敏捷模式做產品的話，當個迭代排下個迭代的需求，若是太早確定的需求，到了要開發的迭代，可能都已經需要調整了。
產品按時發布
互聯網崇尚小步快跑，持續迭代。這個說法的核心意思是：通過固定的迭代發布周期，每個迭代都在完善改進產品，改完後立馬發布，以便用戶能快速體驗到產品的變化和改進，不斷提升用戶體驗。這個過程當中，最關鍵的點就是按時發布，這樣可以讓用戶有所期待，就不會在遇到不良體驗的時候快速放棄產品的使用。固定的發布周期可以讓用戶有一定的忍耐度，會希望看看新版本是否能解決問題。
持續的迭代改進
產品的第一個版本肯定不會是最完美的，需要投放到市場上去檢驗，而檢驗的結果對於產品的發展來說至關重要。可以通過產品的運營收集回來很多的反饋意見和運營數據，從中我們可以發現產品的不足和缺陷，我們所要做的就是不斷的去彌補這些不足，逐漸的把產品越做越完善，趨近於完美的水平。所以說堅持很重要，做產品不可能一蹴而就，而是一個循序漸進的過程，堅持深挖用戶需要，不斷的去改進現有產品，把產品的核心功能做到極致。
好的產品是運營出來的，不是說光靠運營手段就能做出好產品，而是要通過運營去手機市場的反饋，然後分析這些反饋數據，從中提取有價值的內容改善到產品當中，再繼續投入市場去運營，這樣的一個循環反覆的過程，才能真正讓運營打造出好的產品，只有運營手段而沒有產品的持續改進，最好的情況下也只能讓產品火一小段時間，熱度過了之後就會回歸理性。
保持良好的團隊工作節奏
團隊的工作節奏是需要一段時間去塑造的，良好的節奏可以提升團隊的戰鬥力。比如上述所說到的固定發布時間，就可以讓團隊保持在一個持續打著雞血去發布更新的狀態。當然這個迭代周期的時間長短要視團隊結構和產品來定，兩到三個星期是比較正常的。在一輪發布結束後，可以接著投入到為下一輪的發布做準備。這需要整個團隊的配合，在一段時間後，就會形成良好的循環，當團隊適應了這樣的節奏之後，整體效率就能有所提升。
再者也需要磨合團隊成員之間的配合，節奏是需要實際工作過程當中去磨合、調整出來的，從實際工作的角度來講，讓團隊成員感覺到工作的充實感是一種比較好的狀態，這可不是持續加班的形式，這是超負荷，而不是充實。這種節奏也需要產品經理去觀察團隊實際的戰鬥力，適當的安排有挑戰性的工作進度，逐步的去提升團隊的效率，而不能一下把團隊都壓垮了，一下又很輕鬆，這樣的節奏適應起來就會很困難。
內容是產品的一部分
除工具性的產品外，內容都是產品不可或缺的一部分，只有產品的空殼而沒有內容是沒法運營的。比如電商類產品會看品類豐富度，閱讀類產品要看上架小說數，新聞類產品要對比新聞的及時性，財經類產品要看數據的準確性等等，很多產品離開了內容就沒有意義了。如果一個聚集閱讀的產品經常出現內容更新，或者裡面的內容質量很差的情況，相信這樣的產品很快就會被用戶放棄。產品經理在重視產品設計的同時，也要關注內容的建設，不管是原創的、抓取的還是UGC的，內容產生和運營對於產品來說至關重要。
有針對性的運營
千萬不要盲目運營，不要看到什麼運營方式火爆就採用什麼樣的運營方式，要看這種方式是否適合產品。比如病毒式營銷，能做這樣營銷的產品是有其特性的，比如適合快速傳播，能快速吸引用戶的注意力，抓住用戶的眼球，這樣的產品才適合病毒式營銷。再比如說一個高大上的APP產品，適合去貼電線杆廣告嗎？適合像腦白金那樣去滿大街的貼廣告嗎？顯然在做產品運營的時候，還是要看一下我們的目標用戶群體的主要活動空間或者活動方式，針對性的制定運營方式，比如Android類的APP產品，如果面向的大眾人群，除了要考慮百度、豌豆莢、360這樣的大應用市場外，還需要研究一下像安智，以及很多手機定製操作系統上的應用市場，可能定製系統裡面的市場才是最大的。
注意埋點收集數據
大數據運營的思路已經越來越被人所熟知，大家應該都不陌生了。數據從哪裡來？除了產品自身產生的一些內容數據、會員數據外，還需要藉助第三方工具或自主研發的工具去獲取流量數據、訪問數據等，這個是需要埋點的。另外，從產品設計的角度講，很多交互方面的數據是不大好藉助第三方工具去抓取的，而是要靠自身去埋點解決，統計用戶點擊每個按鈕、切換聚焦輸入框的順序、頁面內容個部分的操作順序等等。這部分的埋點要依據產品的實際需要去做，畢竟很多埋點都是會影響產品運行性能的，需要權衡考慮。
減少會議所佔用的時間
高效的會議是很多團隊在追求的，經常看到很多人都在抱怨會議時間佔用太多，全天都在開會什麼的。其實這和團隊內部以及團隊之間的工作方式有很大關係，很多團隊喜歡把所有的內容都拿到會議上來討論，很多會議都是沒有議題和議程。而實際上會議是用來解決不確定性的問題，或者是用來總結的，需要控制好會議的進程和進度，避免發散開去。個人推薦敏捷模式下的幾種會議，站會、計劃會、評審會、總結會，能解決很多團隊協作的問題了。
產品的管理策略並不只關注於產品，還會關注產品團隊和工作方式，從各個方面來一起保障產品的研發。而這樣的策略，在以產品經理為主導的團隊里，是需要產品經理去牽頭的。不過策略歸策略，千萬不要變成規章制度，這東西有利有弊，大公司才用制度，小團隊只要管理策略就可以了。產品經理制定產品管理策略的時候，永遠記住一句話：沒有最好，只有最合適。
對了，想要了解更多項目管理解決方案可前往CORNERSTONE。
產品經理首先需從用戶那裡收集反饋信息，分析用戶需求，再根據用戶需求進行產品功能規劃，這些待實現的產品功能對於產品來說就是產品需求。收集用戶反饋，分 析用戶需求，最終都是為了生產產品需求。用戶需求是無限的，相應的產品需求也會各種各樣，因此，如何有效的進行產品需求的管理是非常重要的。
什麼是產品需求？待實現的產品功能對於產品來說就是產品功能。
在 實際工作中，我們很容易將「用戶反饋」、「用戶需求」、 「產品需求」等相混淆，這是因為很多時候他們所要表達的內容是一致的，比如用戶反饋說微博商業介面中的搜索結果不僅可以按降序展現，最好也可以按升序排 列，這是用戶的反饋信息，也是最真實、具體的用戶需求，而產品需求就是在下一版本升級時要增加一個排序參數。
但是事實上，「用戶反饋」、「用戶需求」、 「產品需求」這三者有著本質的區別，還是福特汽車那個比較經典的例子。
用戶反饋：一匹更快的馬。
用戶需求：用最短的時間到達目的地。
產品需求：更便捷的交通工具。
由此可見，有時候「用戶反饋」並不等同於「用戶需求」，也不等同「產品需求」，如果錯誤的將用戶反饋當成是用戶需求或者是產品需求，那麼將會造成錯誤的決策，因此對三者進行有效的界定區分是非常必要的。
產品經理首先需從用戶那裡收集反饋信息，分析用戶需求，再根據用戶需求進行產品功能規劃，這些待實現的產品功能對於產品來說就是產品需求。
收集用戶反饋，分析用戶需求，最終都是為了生產產品需求。用戶需求是無限的，相應的產品需求也會各種各樣，因此，如何有效的進行產品需求的管理是非常重要的。
將用戶需求轉化為產品需求
用戶需求收集的來源與方法有很多，包括競品分析、訪談、問卷調查、焦點小組、可行性測試、現場觀察、數據分析、任務和場景分析等，在不同階段應用的收集方法是不一樣的，需求收集是持續的過程，貫穿產品發展的生命周期。
之所以將用戶需求轉換為產品需求再進行管理，是因為多數時候憑藉經驗根據用戶需求制定初步的產品解決方案並不需要耗費多大的精力，卻可以讓我們更加深入地理解用戶需求以及產品需求和產品之間的關係，同時也方便我們準確的評估滿足用戶需求的產品新方案的技術可行性和優先順序。
記錄產品需求的屬性和信息
選擇性的記錄產品需求的一些重要屬性，將有助於我們更好的管理產品需求，如產品需求所屬模塊、產品需求的需求類型、需求方代表等。
產品需求所屬模塊：一個產品往往是一個複雜的功能系統，為了產品更容易分析和開發，產品會被分解為幾個功能模塊，每個功能模塊負責完成產品一部分的系統功 能。需求所屬模塊就是產品需求所隸屬的模塊，用來直觀地說明產品需求在產品結構中的具體位置。比如微博數據中心分為粉絲分析、內容分析、互動分析、行業趨 勢分析四個模塊，而頁面訪問分析是隸屬互動分析這個模塊。
需求類型：對產品需求進行必要的分類，不僅可以幫助我們更好的管理需求，而且還可以更好的分析需求，對每個需求的價值大小做出更準確的判斷。同樣的產品需求 可以按照不同的維度進行分類，具體採用哪種維度可以根據實際需要來決定。比如微博數據中心的後台管理支持系統就要針對代理商需求與零售商需求進行區分。
需求方代表：需求方代表就是最初提出該用戶需求的人員，在產品功能規劃與版本升級時，如果需求方案不得不調整，那麼產品經理可以迅速找到相應的需求方代表進 行溝通。比如運營人員提出發票錄入系統的相關問題，在產品實施過程中如果需要進行調整可以快速找到其進行溝通，確保新的產品需求能夠正確無誤地反映用戶的 真實意願。
確定產品需求優先順序
考慮到互聯網公司的時間、資源都是有限的，必須對產品需求優先順序進行排序。判斷產品需求優先順序的主要依據是產品需求的投入產出比，即產品需求的產出價值與投 入成本之間的比例。除此之外，還要考慮需求的緊急程度、與產品策略的契合程度、需求之間的潛在關係、實際可調配的資源情況等因素。
比如微博數據中心的後台管理系統的代理商返點比例需求是由部門BD提出的，但是在1.0版本就沒有實現，主要就是因為這個需求的優先順序比較低，不是剛需。
跟蹤產品需求進展
產品需求管理是一個持續的動態過程，新的產品需求不斷產生，同時一批批產品需求被實現。產品經理要負責對產品需求的進展進行跟蹤，並時刻更新它們的狀態。需求狀態指的是產品需求在這一刻所處的情況。常見的需求狀態有：待確定、未開始、開發中、已完成、擱置、取消。
除了需求狀態以外，一些和需求進展相關的重要信息也應該被記錄，比如已完成需求的完成時間、擱置需求被擱置的主要原因等等。
對了，想要了解更多項目管理解決方案可前往CORNERSTONE。
題主的問題有點模糊，給我的感覺可能是一名想要成為產品經理的同學提出的一個疑問
所以首先我要說的是，任何工作都離不開流程和方法，因此像「如何制定產品需求」這樣的問題就有兩個角度，一個是是指制定需求的流程，另一個是指需求產出過程是怎樣的
其實每一個企業對於圍繞需求的工作都有一套自己的方法，大多數時候執行類的產品經理都是跟著走就好了。有一個實際的經驗之後對這個問題自然就會有所理解
當然，回答這些問題之前，我們首先有必要對什麼是產品需求達成一致，其實這個問題沒什麼標準定義，所以我在這裡聲明我所使用的一組定義
- 需求：有實際場景的，未被滿足的需要
- 群體需求：一群人共同的需求
- 用戶需求/購買動機/產品價值：用戶基於怎樣的原因，會渴望以及選擇擁有這個產品
- 功能需求/使用需求：用戶在使用這個產品過程中，希望產品滿足的需求
這組定義中，後兩個應該才是題主問到的產品需求。這裡我們一定要清楚，需求和產品需求是完全不同的兩個東西，而後面的用戶需求和功能需求也是一前一後的用於不同設計階段的東西
所以需求在產品設計過程中是連續不斷的，起伏的。產品從0~1~2，我們概括性的描述需求所經歷的流程大概是這樣的
這裡只描述了需求的通用流動過程，不涉及到關於產品設計相關的部分，其中前兩個部分主要是新產品開發的階段，中間兩個部分是新功能開發的階段，後兩個是最常用的產品維護階段
不同階段需求的來源和篩選方法不同，而且篩選方法也並不唯一
常見的需求來源包括：
- 用戶研究
- 數據分析
- 用戶反饋
- 產品/商業/競爭需求
- 領導
篩選和分析方法就太多了，也並沒有什麼特別主流或者科學的方法。但核心還是需求要為上層建築比如公司戰略，產品目標和商業價值服務；重點在於如何排布優先順序；需要警惕的就是鑒別偽需求、無關需求以及個例需求
但其實衡量一個產品團隊需求能力的我個人認為還是在需求管理上。需求管理並不是簡單的把需求記錄在表格或者電子平台上這麼簡單，當然很多小團隊連這都沒有也是經常的事情。好的需求管理模式可以有效將需求工作從個人依賴轉化為團隊依賴，它應該包括：需求如何識別，如何確保每一個需求得以被跟進，如何進行分析，分析後轉化的功能需求如何描述，如何向團隊傳達，如何評審，如何納入開發計劃。很多成熟的公司都會有一套基於項目技術建立起的相應體系、方法和工具，比如用戶畫像，用戶旅程地圖，故事板，UC用例圖等等
總之需求是一個複雜的，很容易讓人混淆的東西，作為產品經理，洞察需求、正確理解需求是一個需要經驗和自我總結的工作。可以說這是一種程序性知識，它很難用文字描述，也幾乎沒辦法用語言講解，最好的學習方式就是練習
推薦閱讀：
