什麼是產品需求？待實現的產品功能對於產品來說就是產品需求。
在實際工作中，我們很容易將“用戶反饋”、“用戶需求”與“產品需求”的概念相混淆，這主要是因爲它們很多時候所表達的內容是相同的。例如“首頁頁面上應該有一個搜索功能”，這是用戶的反饋信息，同時它就是用戶真實的、具體的需求，而產品需求也就是要在首頁頁面上增加一個搜索功能。
但是事實上，“用戶反饋”、“用戶需求”、“產品需求”三者之間有着本質的區別。我們可以用一個簡單的例子來說明這一點：
用戶反饋：固定電話聽筒的電纜應該有10米長。
用戶需求：可以拿着電話在房間的任何一個地方通話。
產品需求：無繩電話。
從這個例子我們可以看到，“用戶反饋”並不等同於“用戶需求”，也不等同於“產品需求”。如果我們直接將“用戶反饋”當成“用戶需求”或是“產品需求”，那麼我們最後很可能在自己毫無察覺的情況下做出錯誤的產品決策——將固定電話聽筒的電纜做成10米長。因此，對“用戶反饋”、“用戶需求”和“產品需求”進行嚴格的界定是非常有必要的。
產品經理首先從用戶那裏收集反饋信息，然後從用戶反饋中分析出用戶需求， 再根據用戶需求規劃產品功能，這些待實現的產品功能對於產品來說就是產品需求。
收集用戶反饋，分析用戶需求，最終的目的都是爲了產生產品需求。產品的用戶需求是無限的，相應地產品需求也會大量積壓在產品經理手中。爲了便於記錄、評估和跟蹤產品需求，產品經理需要創建和維護一張產品需求列表，對所負責產品的產品需求進行系統的管理。
一、將用戶需求轉化爲產品需求
用戶需求的來源有很多，而且非常零散，可能來自某次用戶調研、某次頭腦風暴會議、某次數據分析，也可能來自高層突然的決策。我們並沒有能力在短時間內滿足所有的用戶需求，如果沒對這些需求進行系統的整理和管理，那麼時間一長，很多需求就會丟失，而一些關鍵需求的遺漏對於產品來說是重大的損失。
我們習慣將用戶需求轉化爲產品需求再進行管理，因爲多數時候憑藉經驗根據用戶需求制定初步的產品解決方案並不需要耗費多大的精力，卻可以讓我們更加深入地理解用戶需求以及用戶需求和產品之間的關係，同時也方便我們準確地評估滿足用戶需求的產品方案的技術可行性和優先級。
針對不同的產品，我們進行產品需求管理所要記錄的內容也不盡相同。下面是一張用Excel表格製作的簡單的產品需求管理列表。
表中每一行記錄了一個產品需求。
需求名稱：產品需求名稱就是根據用戶需求規劃的產品功能的名稱，也就是我 們期望提供給用戶的功能，例如“換膚”、“訂單物流信息”。
需求描述：需求描述是用簡潔的語言對該產品需求進行解釋。需求描述不用考慮產品功能技術層面如何實現，而是要以用戶的視角說明產品提供了哪些功能，這些功能是如何被使用的。需求描述建議按“誰可以執行什麼操作，獲得什麼好處”的格式來寫，例如“已下單的買家可以查看訂單物流信息，以瞭解並跟蹤訂單物流”。這樣寫就能夠說明產品要提供什麼功能，用戶能夠獲得什麼好處，整個需求也就非常清晰、具體了。
二、記錄產品需求的屬性和信息
選擇性地記錄產品需求的一些重要屬性，將有助於我們更好地管理產品需求，如產品需求所屬模塊、產品需求的需求類型等。
需求所屬模塊：一個產品往往是一個複雜的功能系統，爲了使它更容易分析和開發，我們會將產品分解成若干功能模塊，每個功能模塊負責完成一部分系統的子功能。需求所屬模塊就是產品需求所隸屬的模塊，用來直觀地說明產品需求在產品結構中的具體位置。如果產品較複雜，那麼我們還可以對模塊進行多級劃分。產品的模塊劃分要能夠體現產品的功能結構和信息架構。比如，我們按照功能結構將一個視頻網站的一級模塊分爲：首頁、搜索頁、列表頁、詳情頁、專題頁……然後按照信息架構將詳情頁下的二級模塊分爲：電影詳情頁、電視劇詳情頁、視頻詳情頁……
需求類型：對產品需求進行必要的分類，不僅可以幫助我們更好地管理需求，而且可以幫助我們更好地分析需求，對每個需求的價值大小做出更加準確的判斷。同樣的產品需求可以按照不同的維度進行分類，具體採用哪種維度可以根據實際需要來決定。比如，一個C2C（Consumer to Consumer，個人對個人）電子商務網站可以按照用戶身份的不同，將用戶需求分爲買家需求和賣家需求；一個客戶端軟件可以按照功能技術實現方式的不同，將用戶需求分爲客戶端需求、服務端需求和Web（客戶端內嵌網頁）需求。
另外，產品需求背後還有一些重要信息，如果這些信息將來有可能成爲產品需求決策評估的重要依據，那麼它們也應該被記錄下來。比如某個產品功能要實現的前置條件、某個bug重現的具體操作步驟等。
個別產品需求特有的背景信息可以記錄在該需求的備註中。有些背景信息是每個產品需求所共有的，而且非常重要，那麼這些信息就需要對每個需求進行記錄，例如需求方代表。
需求方代表：需求方代表就是最初提出該用戶需求的人員，比如，某運營人員代表用戶提出了一個用戶需求，那麼相應的產品需求的需求方代表就是該運營人員。在產品需求的具體實施過程中，可能由於諸多原因（如原方案在現有技術條件下無法實現等），需求方案不得不不斷調整，如果這時候產品經理不確定實現原產品需求的最初出發點，那麼就有必要和需求方代表進行溝通，確保新的產品需求能夠正確無誤地反映用戶的真實意願。
三、確定產品需求優先級
確定產品需求的優先級是我們進行產品需求管理的主要目的之一。在產品需求管理列表中，我們可以很方便地對產品需求進行橫向的比較，確定產品需求的優先級。
那麼爲什麼要確定產品需求的優先級呢？
首先，對於互聯網公司來說，時間總是有限的。互聯網是個瞬息萬變、高速發展的行業，大部分的互聯網公司都崇尚“天下武功，唯快不破”的產品開發理念。在這樣的環境下，即使是一款在行業內遙遙領先的產品，也可能在短短幾個月內被競爭對手全面超越。這樣的案例不勝枚舉。
其次，對於互聯網公司來說，資源總是有限的。一方面，有限的資源只能開發有限的產品功能；另一方面，要實現的產品功能過多必然會導致項目複雜度增加，一旦項目變得不可控，那麼所要耗費的資源成本就會不成比例地大幅提升。
因此，大部分互聯網公司都主張“小步快跑，快速迭代”的產品開發方式，每個階段只選取最重要的產品需求進行開發，力爭以最快的速度將產品新版本投入市場，通過不斷地收集用戶需求、不斷地版本迭代來逐步地完善產品。爲了確保每個階段總是在開發最重要的產品需求，就需要通過確定各個需求的優先級來對產品需求進行取捨。
確定需求優先級是個非常重要的環節，它最終決定了產品會提供哪些功能，產品會長成什麼樣。不同的需求組合會導致完全不同的產品結果，優秀的產品經理應該在確定需求優先級上有自己清晰的思路。
判斷產品需求優先級的主要依據是產品需求的產出投入比，即產品需求的產出價值與投入成本之間的比例。產出投入比越高，代表產品需求的效益越大，產品需求越值得我們開發；反之，產出投入比越低，代表產品需求的效益越小，產品需求越不值得我們投入資源。
價值：產品需求的價值包括它給用戶帶去的用戶價值和它能給公司帶來的商業價值。我們最終需要的是商業價值，但是商業價值往往是由用戶價值帶來的，產品的用戶價值越高，產生的商業價值一般也越高。因此，產品需求價值的評估重點在於確認用戶使用該功能可以獲得什麼利益，該功能滿足了用戶什麼需求，有多少用戶有這個需求，用戶期望產品滿足這個需求的迫切程度……然後我們對由此而產生的用戶價值和商業價值進行綜合評估，最後判斷得出產品需求價值的大小等級。
成本：產品需求的成本指的是實現產品需求需要投入多少成本，包括開發產品功能要投入的人力成本、維持產品功能正常運行所需的硬件投入、產品功能後續的維護成本、產品功能所需的日常運營成本，等等。其中，大部分產品功能只需要投入人力成本將其開發出來就能夠供用戶正常使用，而在人力成本中，開發資源的投入往往是最大的，開發資源常常是產品實現過程中最大的資源瓶頸，因此，一般情況下，對產品需求成本的評估只要考慮開發資源的投入成本即可。產品經理可以憑藉自身經驗粗略地評估開發成本，也可以在開發人員的協助下完成這項工作。由於這時候產品需求的細節還不明確，開發人員只能給出大概 的開發成本評估結果，但是無論如何，這個結果對於我們確定產品需求的產出投入比已經有非常大的參考價值了。
確定了產品需求的價值和成本，我們就可以得出它的產出投入比了。如下圖所示，需求A、需求B、需求C、需求D就是按產出投入比來確定優先級的。
除了產出投入比以外，產品需求優先級的判斷還需要重點考慮以下一些因素。
（1）需求的緊急程度
有些產品需求雖然不重要，但是很緊急，它仍然應該被給予較高的優先級。我們可以將產品需求的緊急程度加權折算到需求的價值裏，也可以單獨對它進行考慮。
比如，上圖中需求E是一個嚴重影響用戶基礎功能使用的bug，所以應該儘快解決。
（2）與產品策略的契合程度
產品策略用於指導一段時間之內的所有產品工作。它包括我們對產品的目標用戶、產品定位、商業模式的設定，還包括我們根據市場環境等因素制定的產品競爭策略和產品發展路線。在確定產品需求優先級時，我們要充分結合產品策略進行考慮：一些與我們的產品定位不相符合的需求，即使產出投入比很高， 但爲了不影響產品定位的清晰傳達，仍然應該放棄；每個產品的自身情況都不一樣，產品要有自己的發展節奏，每個階段實現的產品功能要能夠服務於這個階段的產品目標；並不是所有重要的需求都要一下子推出的，有時候故意忽略人們非常需要的一個功能，反而能夠激發起人們對它的渴望，當用戶之後得償所願，獲得這個功能之後，就會更加高興……
比如，上圖中需求I是用戶非常期待的一個功能，實現起來成本也並不高，但爲了製造期待效應，我們將它推遲到後續版本中實現。
（3）需求之間的潛在關係
產品需求之間往往會存在大量的潛在關係，只有充分考慮這些潛在關係，才能保證最後確定下來的優先級是合理的。
比如，上圖中需求G和需求F都是要對產品的同一個功能模塊進行改動，需求G如果和需求F一起實現只要1人日，但如果不與需求F一起實現則要5人日，那麼我們就應該考慮讓需求G與需求F一起實現。
再比如，上圖中需求H與需求F有依賴關係，要實現需求F的前置條件是要先實現需求H，所以需求H必須先於需求F進行開發。
（4）實際可調配的資源情況
產品需求的優先級還要依據實際可調配的資源情況去調整，要讓產品團隊成員的工作量達到完全飽和，以實現整體資源利用的最大化，避免資源的不必要浪費。
比如，上圖中產品需求分爲客戶端和網頁兩種實現方式，需要客戶端開發團隊和Web開發團隊分別負責開發。由於網頁需求需要和客戶端需求一起發佈，預計Web開發團隊會先於客戶端開發團隊完成所有高優先級產品需求的開發，所以我們將產出投入比並不高的需求J的優先級提高來提前實現，這樣Web開發團隊就可以在客戶端開發完成前開發更多的Web功能。
四、跟蹤產品需求進展
產品需求管理是一個持續的動態過程，新的產品需求不斷產生，同時一批批產品需求被實現。產品經理要負責對產品需求的進展進行跟蹤，並時刻更新它們的狀態。
需求狀態：產品需求狀態指的是產品需求在這一時刻所處的情況。常見的需求狀態有：待確定、未開始、開發中、已完成、擱置、取消。“待確定”說明該需求還不夠明確，需要產品經理和需求方代表做進一步的溝通確認；“未開始”說明該需求已明確，等待開發中；“開發中”說明該需求正處於開發實施的過程中；“已完成”說明該需求已開發完成，用戶已經能夠使用這個產品功能了；“擱置”說明該需求因爲某種原因被閒置了，暫時不予以考慮安排；“取消”說明該需求已被徹底放棄。
除了需求狀態以爲外，一些和需求進展相關的重要信息也應該被記錄，比如已完成需求的完成時間、擱置需求被擱置的主要原因，等等。