作為產品經理，你是如何分析和管理你的產品需求的？

12-23

提這個問題的初衷是想了解其它的產品經理們在處理來自不同地方的需求時的工作方式和方法，因為自己在處理這些事情時經常會陷入比較混亂的情況。
自己的方法也是如下面@高東升說的這幾種，分類管理，定期維護，但在實際操作中還是存在著一些問題，導致很多地方落不了地或是很多變更，所以想了解其它產品經理的一些情況。

點贊太多我有點惶恐。其實我真的是在吐槽啊。。。。。（無辜臉）

1，政治任務永遠優先順序P0，學會在勸阻失敗的情況下，幫老闆證明他是對的。
2，每一期產品需求的收集是不可能完善的，因為需求發起者會忘，或者老闆們會臨時起意，所以要搞嚴格的需求凍結時間來保護開發的工作。不凍結就永遠有需求，而且其實所有的需求都有自己存在的價值和道理，你要拒絕是千難萬難。
3，即便你凍結了需求，他們也會找老闆走特殊審批來新增需求，而老闆一般不會拒絕，除非你哭著對他說已經真的不能再加了——也沒什麼鳥用。最好是在他們走特批之前就打消他們的念頭，或者許諾下一期一定做這個需求。
4，P2的需求永遠不會有人想起來去做，所以你希望看到上線的功能盡量放P1。做一小部分需求，拒絕一大部分需求，拒絕不了就拖著，需求自然會消失。LESS IS MORE，做產品能解決業務問題就可以了，70分就行，不要老想打造完美的產品。
5，你想像中的那個100分產品在用戶看來也就70分，你那些天才一樣的創意多半是YY，即便你做了數據分析和用戶調研。100個創意里有一個能被用戶用起來就不錯了，其實做產品跟搞藝術很像，你信不信？
6，如果一個產品功能比較剛需，而用戶能用，只是產品設計比較垃圾，他們會用下去。除非出現一個超越你10倍的對手。如果你的產品沒有剛需功能，卻有很多用戶，那一定是走了狗屎運。我見過太多設計一流卻沒什麼剛需或者沒什麼長期需求價值的產品。
7，一般那個超越你10倍對手叫蘋果，還好他們老闆已經死了，暫時安全了。
8，一次超越對手一大截很容易，每天每年都超越對手一點點很難，做產品要有耐性——當然一般公司老闆沒什麼耐性。By UC老闆，阿里移動總裁俞永福。
9，需求管理混亂的本質是你沒什麼話語權。

做了二十年產品了，一個讓你哭笑不得的經驗就是：大多數的需求分析是白費工夫，因為最核心的需求是基礎體驗！比如說，你一個做閱讀的至少讓人可以安安靜靜看篇文章看本書吧，你一電商總得讓人正常登錄購物流程順暢吧，你一個遊戲至少把閃退控制好一點吧……然而大多數情況是，這些基於「常識」的基礎需求遠遠沒有做透的時候，就忙不顛兒地搞新需求了，更糟糕的是一些政治正確的領導需求，一些商業正確的運營需求，進入這個循環，該產品做到最好也就是平庸了。不過就我本人而言，遇到這種坑要麼頂、要麼走，讓我認帳門兒都沒有。大概也因為這個原因，雖然屢屢受挫，但總算能夠作出點兒好東西。世間好的產品都是「為人民服務」，平庸的產品往往「同志們辛苦了」，最爛的產品是「首長好！」。

下面是我的經驗。可能要解決題主的問題，未必是只從需求管理來做，而是整體流程上把控。

1. 獲取階段

需求的來源有很多。業務越複雜，需求就越雜。一個淘寶，產品需求就可以拆分成分類、檢索、排序、商品展示、營銷活動、支付、配送、售後等等。

你的職級越高，也代表著身邊人提需求的可能性越大。初入行的產品專員或助理，主要是得到被安排的任務；初級產品經理，需求來源主要是用戶和上級；產品負責人，需求來源就要增加老闆和其他相關部門；而作為老闆，誰都可能跟他提產品需求。

所以在獲取到需求這一時刻，就必須做一個判斷，並且記錄。如果不做判斷堆在那裡，等做的時候根本沒辦法梳理出頭緒，可能大部分時間都在疲於折騰需求清單。記錄當然是為了方便回溯。獲取到的再小的需求也記下來，不要指望你隨時能想起來每天聽過的每個需求。

做判斷的內容具體是什麼呢？

第一，判斷需求本身的重要性。

同樣是頁面寫錯了一個字，把「登錄」寫成「登陸」，和把「獎勵 15 元」寫成「獎勵 50 元」，重要性不言而喻吧。有個大致的預估。

第二，考慮需求來源。

需求來源會表明一些事情，要慎重思考。比如老闆提到的，未必是目前你能理解的，但他認為特別重要，就暫且把這個當成特別重要的，這是政治任務。再比如是用戶提到的，但細想他並不是目標用戶，他的需求就不必太關注。

第三，簡要得到需求背景。

我自己工作中有三類需求絕對不記：沒說清楚原因的，不記（你做個XX出來，別管那麼多）；不說清邏輯的，不記（啊，這裡我也沒搞懂，你先看看）；不是實際遇到的，不記（哎，我覺得可能有人會這樣用）。

需求背景沒搞清楚，完全是浪費時間。有一句話的記錄，但不說背景，也是浪費時間。記的時候，我會確保格式是問題+方案，「XXX 在用我們的 XX 功能時，感覺 XXX，我們可以嘗試 XXX 這樣的方案」。

最後，依據這三個因素，判斷屬於大致哪個類別的。一般的需求管理都會分 P0-P3 或者 P1-P4，總之先打個標籤。這裡的技巧是盡量標記為比估計的更重要一層的需求，就是你感覺是 P2 的，暫且先標為 P1。這樣以防錯漏，低優先順序的標成高的沒關係，但高優先順序的標低了會出現麻煩。這時候的預估往往不準確，但沒關係，等後面第二步再說。

比如這樣：

2. 討論/設計階段

隔一段時間，我們會開需求討論會，整理需求池，也就是記錄所有獲取到需求的表單。

我們會詳細討論每個需求的情況，確認幾個事項：

一，需求的優先順序

之前的判斷是粗估，這裡的判斷就要精細了。一般需求的重要程度很難量化，尤其來源複雜的情況下。營銷部門著急要我們配合做活動，不做就少賺好多錢，業務部門著急要我們配合做一套自動化結賬工具，做了能節省很多成本... 有時抉擇很痛苦。

這裡還是用最常用的判斷方法，緊急重要四象限法則：四象限法則_百度百科。重要程度大致按這種排序：

不做會造成嚴重的問題和惡劣的影響的
做了會產生巨大好處和極佳效果的
跟重要合作對象或投資人有關的
跟核心用戶利益有關的
跟大部分用戶權益有關的
跟效率或成本有關的
跟用戶體驗有關的

緊急程度按這個排序：

不做錯誤會持續發生，造成嚴重影響
在一定時間內可控，但長期會有糟糕的影響
做了立刻能解決很多問題、產生正面的影響
做了在一段時間後可以有良好的效果

大家把能考慮到的因素想全，會標上 P1 - P4 的優先順序。

二，方案的方向

需求有不同的解決辦法，我們會討論清楚到底用哪種解決。比如我們發現有刷單現象，可以事前提醒，告知用戶目前地理位置或訂單信息有嫌疑；可以事中限制，必須到達指定地點、拍攝當地照片等等操作來限制用戶；可以事後懲戒，提供給客服或者業務部門疑似刷單的名單和證據，罰款或者封號。這幾項到底做哪個？還是做其中哪幾個？優劣在哪？需要好好討論。

有時會有大概的方向，再去跟相關部門和需求相關的同事確認。這不在本文討論範圍內，暫且不提。

三，指定負責人

我之前經歷過兩種需求分配製度。一種是每個人負責的需求範圍有清晰的邊界，那需求對應哪個模塊，就直接分配即可；另一種是團隊作戰，每次指定或者認領，誰都有可能接手任意需求。

前一種的好處在，模塊清晰，負責人可以對自己負責的部分足夠熟悉，但缺點是，工作量很可能不平衡，有的同事一直在忙，有的可能就比較閑，因為需求不是平均按模塊分布的。

在我們需求分配時，大致還是按照模塊分配，但在出現工作量不平衡的情況時，會酌情調整一下，讓活少的同事予以配合。

不管怎麼樣，一定一定要指定負責人，他需要對需求負責，一直到產品上線後，出了的問題他也要承擔責任。要保證運營良好的工作責任制。

四、劃定時間節點

許多產品經理會疏漏這點，只是覺得儘快去做，但總是做不完。

時間節點至少也要包括方案完成的時間。就是這個需求，能夠完好提交給開發的時間。如果沒有這個時間，對需求的管理就沒有一點意義了。

另外，如果是要跟相關部門再確認、或者要跟用戶調研、或者要統計各種數據再作判斷的需求，那還要有調研/討論完成的時間。

這個時間節點的劃定，主要是按照方案的複雜程度，用經驗做個簡單判斷。最長的時間周期也不能超過一周，保證需求的推動進度，因為很難有複雜程度超過一周的產品需求。對於有嚴格上線時間的需求（經常會出現，比如很苛刻的老闆需求、投資人需求、政府需求等），要倒推出最合理又富有餘地的時間節點。

討論完剛剛入池的一批需求，我們會再整理和討論其它狀態（有方案或者調研結論）的需求。這樣會議結束，每條需求都會得到更新。

我們在這個時刻，一般會讓負責的產品經理，及時更新需求狀態給需求來源方。當然，來源方 95% 的情況下會對進度不滿意，這很正常，但除非來源方有確鑿的理由，我們不會輕易調整優先順序和時間節點。

3. 待開發階段

有了確切方案，我們會儘快跟研發的同事做可行性評審。這一步必不可少。我感覺題主出現的「落不了地」和「頻繁更改」的問題，要著重在這個步驟里解決。

可行性評審上，完成的是對需求的大致評估，要做的有這麼幾件事：

第一，方案本身的可行性。

在技術方案上，是不是能夠完成？就是讓技術部門評估這個問題。

第二，有沒有更好的方案？

一定要跟技術部門灌輸清晰的需求背景，讓他們也想一些可行的方案。方案未必是完整、準確的，但他們提供的思路，一般是可行性較高的。

第三，涉及的產品和技術環節有哪些？

這個需要相關的同事仔細討論。尤其是很多公司產品線比較多，有可能存在牽一髮動全身的情況，如果相關的產品同事和技術同事不知情，必然會延期，必然會扯皮，必然會造成麻煩，必然會有各種改動。即便是再小的產品，也要分前後端，讓技術的同事來判斷有哪些人需要知情和參與評估。

第四，方案的成本如何？

看方案需要多少人、多少資源、多少時間來完成，也要看方案在技術層面耗費的不太明顯的成本，比如伺服器成本、帶寬成本，給用戶造成的流量成本等。

有了這樣的討論，會議輸出的，就是比較嚴謹的可執行方案（或草稿）了。

如果會上遇到各種問題，要確認解決問題的時間節點。

4. 開發階段

開發需求的次序，我們不是完全按照需求池裡的需求優先順序來的。剛才說到，在可行性評估會上，我們會核算大致的需求成本，那成本結合需求的優先順序，就可以得出需求的性價比了。

我在創業公司產品經理怎麼做？ - 劉飛的回答里提到過具體的方法，這裡不再贅述。大概是用這樣的表格：

提交開發之後，相當於關閉需求。原則上，本次迭代不再加入新的需求。

當然啦，如果什麼事情都是原則上那樣...就不會出現這麼多扯皮的情況了。

在開發中，扯皮的問題歸納起來就是三種：需求太多，沒按時做完；需求有改動，導致了額外工作量以及開發的不滿；有新的緊急需求，導致發布延期。

這三種問題，再抽象一下，導致的原因很多，大概有幾類，分別是：

一，產品方案不完整

方案不完整往往是沒有考慮全面。這個跟需求管理本身沒關係，就是在出方案的途中，看能不能把事情想全。

之前我們經常出現，做的時候技術才發現卧槽這裡有個邏輯沒想通啊。然後喊產品來一起討論的時候，大家發現需要加一些功能才能完善邏輯。最後結果就是周六加了個班，大家很不開心。

這種事情也不好追責，畢竟參與者很多，流程拖得很長。硬要說是負責需求的產品經理有問題倒也可以，但總是片面的：他也不一定知道技術上開發才發現的邏輯。

後來我們反思，各個流程中的環節都要做一些調整，才能確保最終產品方案的完整：

分析需求時，先梳理邏輯再出方案。能畫流程圖的畫流程圖，能畫邏輯圖的畫邏輯圖，能畫腦圖的畫腦圖，窮舉整體的邏輯。
討論方案時，所有產品經理參與小組討論，一起提出疑惑，發現問題。
可行性評審時，技術從邏輯角度提出質疑，發現問題。

之後再出問題，會回溯原因。如果是前兩個環節出的問題，那就是產品經理的責任；如果是產品經理未知的邏輯，那就是可行性評審中，技術的同事的責任。

二，需求方的主觀改動

這種情況基本都是需求方或者產品經理的問題：他們在提交方案前沒有完全想清楚。

有時候都開始開發了，業務部門來人說，哎我們發現這個問題好像不存在了，大家不要做了。他們覺得無所謂，還減輕了開發負擔。但對技術部門的同事來說，就好像在說「你被耍了，哈哈哈」。造成的影響是惡劣的。

產品經理在對接他們的需求時要做判斷，他們是不是完全想清楚了，是靈機一動的小點子，還是不得不解決的問題。

另外，還有一種情況，是需求方跟產品經理對接時出了問題。表述有誤，並且方案沒有跟他們核對清楚，結果產品功能上線，才發現並沒有解決問題。

我們的做法剛才多少提到了一些：要在任何需求的屬性（內容、時間點）發生變化時，跟需求方同步。讓他們知道我們的情況，也獲取他們的意見和建議。

比如這是我們的需求同步流程：

三、無法預測的客觀原因

這種是唯一一種能夠接受的原因，不需要有誰承擔責任。

比如，本來要做一個功能狙擊對手，結果做了一半，競爭對手倒閉了，那這個功能就沒有意義了，確實要廢除。

還有一些業務上的確無法預測的各種原因，導致原本存在的問題不存在了，也無可厚非。

這種情況下，產品經理最重要的是安撫技術的同事，尤其是跟他們解釋清楚背景和詳細的原因，不要讓他們誤以為是剛才提到的前兩種理由。

5. 復盤階段

需求從獲取到上線，走完生命周期之後，還要有一個很重要的復盤階段，尤其是在需求管理出過故障和問題的時候。

略靠譜的團隊，都會有復盤的機制，主要是防止問題再次發生。解決問題很簡單，如何盡量規避下次再出問題很複雜。

大致就是，要搞清楚之前出現問題的所有邏輯和流程，再去看在哪些環節可以做點什麼，去防止再次出現。這塊的內容說得多了又得寫一篇文，就不多講了。

以上就是我的經驗，僅供參考。沒有什麼流程和機制是完美的，關鍵在於怎麼去解決自己的問題。如果哪些思路給你了啟發，那就夠了。

仔細地看了幾遍問題描述，基本上發現和分析需求沒什麼關係，更多是集中於如何應對來自各方的需求。

其實每次當我收到其他人的需求提議時，我都是非常興奮的，因為平常總是苦苦地在想還有哪些地方可以優化，有人直接給自己提出來，其實省了不少功夫。其次，作為一個對產品依然抱有熱情的 PM，總是好奇地想知道別人會提什麼需求，在不在自己之前考慮的盲區之內，如果在的話，自己為什麼想不到，以及以後如何才能不遺漏這樣的需求。

然而在問題描述中卻說面對各方的需求時，容易陷入混亂，我想當中的原因是非常值得探討的。

為什麼會混亂？猜測主要有兩點原因：

1. 工作比較繁忙，工作流經常被臨時的需求提議打斷，導致原有的工作計劃未能按時完成，有時甚至遺漏掉

2. 各方都說希望自己的需求能夠早點被落實，但一個版本能做的需求確實有限，不知道如何推遲甚至拒絕他人的需求

第一點其實是 GTD 的事情，工作流被頻繁打斷確實影響效率，且十分消耗精力，讓人感覺疲憊和混亂。在產品經理怎麼與團隊成員建立信任和信服感？ - 鄭堅義的回答中的「跟進到位」部分中有簡單說過 GTD 對於產品經理工作的重要性。其實，關於如何避免或者降低來自於他人的打擾，GTD 入門書籍《番茄工作法》里就有說到，要安排專門回應他人的時間。在這個時間段內，統一處理需要和他人溝通的工作事項，而在這個時間段外，遇到他人的 interruption 時，則會告知對方自己正在忙，要不在某某時間再溝通此事。一般只要不是什麼緊急的事情，對方都不會拒絕這樣的請求。

雖然我在平常的工作中也不會嚴格地遵循《番茄工作法》，但只要我意識到自己正處於不應該被打斷的狀態時，都會請求對方稍後再聊。這樣也讓人感覺到你的時間是稀缺的，是需要被尊重的，而避免一些事無巨細的隨意打擾。

至於第二點，是需求優先順序判定及版本規劃範疇的問題。

關於需求優先順序的判定，在產品設計的「節奏感」該如何把握？ - 鄭堅義的回答有提及過，在這裡簡單說一下哪些需求的優先順序比較高：

1. 產品初期，快速地搭建重要功能優先順序比較高
2. 有「窗口期」的戰略性需求優先順序比較高
3. 與近期運營目標契合的需求優先順序比較高
4. 性價比高的需求優先順序比較高
5. 用戶反應惡劣的需求優先順序比較高

其實要判定需求的優先順序，是繞不開對需求有效性的分析的，在產品經理如何判斷一個新功能是否應該添加？ - 鄭堅義的回答有講過，在此不做論述。

然而，在工作中我們發現，其實大部分來自於他人的需求，如果完全按照需求的有效性進行分析的話，優先順序往往都不高，那是否就意味著要把他人的需求無限延期？事實上這樣做效果並不會很好，因為對於你或者對於產品優先順序不高的需求，對於需求方而言卻非常重要。如果不做變通、一味地拖延，同事會認為你不配合他們的工作，難免產生消極的氣氛。每個版本我們都應該爭取出一些資源投放到配合他人的工作中，這樣以後他人也更願意配合自己。

對於不能及時放進當前版本的來自於他人的需求，則需要主動跟對方說明版本的重點是什麼，為什麼排不上，以及會推遲到哪個版本處理。一般而言，如果能夠及時地同步需求的進展，並且表現出配合的積極性，別人都不會故意刁難你。

至於版本規劃，個人一直是提倡提前做好兩個版本左右的需求方案。在產品經理怎麼管理項目進度？ - 鄭堅義的回答有說到，這樣可以靈活地調整或穿插需求，面對變化的時候不至於手忙腳亂。請記住，即便明知道每次規劃最終都會擁抱變化，但也一定要做好規劃，因為你必須梳理清楚每個版本的重點是什麼。

最後簡單說一下很多人在回答中說到的需求池的管理。由於在需求管理上自己基本不需要與他人協同，而且會經常回顧，所以我一般都不會標記優先順序是 P 幾，至於需求的來源更是沒什麼作用。在關於發現需求、篩選需求和設計產品，有哪些成體系的方法論？ - 鄭堅義的回答有說過如何挖掘需求，有零散地收集的、有專門抽時間進行行業調研及競品分析得來的，也有通過用戶的行為或者業務邏輯進行推導的。所有的這些需求，我最終都會通過一張樹狀圖把它們串聯起來。需求被落實後，相應的分支會從樹狀圖中被剔除掉。我的樹狀圖一般都是基於幾個維度去延伸的，這樣會盡量地避免遺漏。因為一些需求在某些維度去分析很容易挖掘出來，而再其它的維度卻很難被發現。對於我而言，屢試不爽的是產品業務數據維度的分析，四大分支分別是：拉新、留存、活躍及銷售。另外，數據統計也是一個通用的重要維度。對於不同的具體產品，還可以將關鍵指標作為一個單獨的維度給提出來。

之所以這樣進行需求池的管理，原因很簡單，因為所有的產品需求都應該緊緊圍繞如何提升產品數據去進行規劃。不要一味地做些花拳繡腿，或者僅僅是感動了自己的功能。

最後放一張經過模糊處理的需求池樹狀圖的示意圖：

一張Excel表即可搞定記錄。

其他的，都是日常積累：

多看用戶反饋
多和團隊成員交流產品想法，多問問其他人產品體驗方面的不足
多看看競品的動態

作為產品經理，最大的痛苦可能就是產品需求的管理，既要廣泛的聽取用戶和小夥伴們對產品的意見，又要不時地應付老闆突如其來的奇思妙想。而這些還只是需求的收集，還有需要評審的，評審中的，評審過了等待開發的，開發完成了的等到測試的等等。此外還有版本的管理，bug的管理等。如果沒有對需求進行很好的管理很有可能造成工作上的疏漏甚至是產品重大功能的缺失，所以對需求的有效管理勢在必行。

第一步，廣泛的收集需求

#截圖來自teamin示例，略有修改，下同

需求的收集不是越多越好，但是在不知道是不是必需的時候全部搜收集過來，從裡面找到符合產品定位和功能需求的也不失為一個方法。把收集到的需求用列表的方式列出來，列的時候可以採用標籤的方式標明需求的來源，方便後期的管理。

第二步，需求分解

在把所有的需求列出來後，需要對收集到的需求進一步進行分解細化，比如常見的註冊登錄功能，用戶可以使用那些工具進行註冊，註冊完成後後可否與第三方賬號綁定，登錄時可以用那些方式進行登錄等這些都是需要產品經理去考慮，而且需求的粒度劃分的越細，對於後期開發的實現難度就越低，換句話說產品更容易做成功。

第三步，需求計劃安排

對收集到的需求進行評審，是否採用，採用的需要在哪個版本里實現，並將評審通過的需求添加到相應的實現產品版本里，沒有通過的放在另一邊。通過評審的需求可以指定不同的執行者來負責這條需求的最終實現，也可以給需求制定截止時間並通過添加標籤的形式來標明需求的重要緊急程度，以示區別。

第四步，需求跟蹤

需求評審通過後，需要技術哥哥去開發實現了，需求的開發進展是怎麼樣的呢，這個可以通過看板的方式來實現。這個流程也是可以自定義的，添加你認為是必須的環節，比如測試驗收，產品驗收環節等。通過這個看板，需求甚至是整個產品的進展一目了然，再也不用為紛繁複雜需求感到頭疼了。

看到這裡是不是發現產品的需求管理其實也沒有那麼難？

整理了一下平時工作中的需求管理的理念和原則，歡迎拍磚。
需求管理理念：按複雜度區分，按優先順序權衡；
1. 將提煉出的需求按複雜度，區分成Task和Project級別，Task級別一般屬於細節、文案調整類的，繁瑣細節但是佔用資源不高，可以快速處理的任務；
2. Project屬於有一定工作量，需要做詳細的需求評審，評估工作量等；
按複雜度區分就是指根據區分的Task和Project，以不同的節奏實施，非緊急情況下的Task需求，根據團隊約定的產品迭代節奏，依序實施迭代優化細節。而Project的實施，則更多的依照項目實施流程，根據優先順序和時間計劃實施。
3. 要設立意外情況方案，當出現緊急情況時，需要有相應的預案快速實施，快速上線；
永遠要記得，人應該handle原則，而不是被原則handle。

需求管理原則
1. 戰略級項目（政治任務）永遠P0，不要試圖強行扭轉老闆的觀點，如果不可行要想辦法從根子上把事兒做成，在底下做事兒永遠要記得，「讓老闆思考細節就是你的失職」，只要方向一致執行上的問題是可以bargain的；
2. 在項目實施是一定要控制需求產出，就像 @曾軼說的要有Freeze Time，需求的產出一定是無止境的，在項目實施中無限制的加入需求是很多實施失敗的根本；
3. 把握好老闆的心態，明確老闆的目標。控制需求越級下達在於能把握老闆的大旗，能把控產品的節奏和主線，需求的存在有他的合理性，但是時間是要有產品owner說了算；
4. 低優先順序別的需求就好像那些不緊急也不重要的事兒，項目爽完之後沒有人想起；
5. 不要幻想一個匠心獨具優雅的設計能大殺四方，能大殺四方的永遠只有為用戶帶來的價值；
6. 如果每天為了管理需求各種艱難困苦，從根源講你沒有能力把控這個產品的走向，從而使得你沒有得到話語權。

感謝@曾軼的回答，以上回答是就著他提的框架將我做項目管理的經驗寫下與大家分享。

有多少產品經理系統地學過軟體工程？
有多少產品經理看過《軟體需求》？
有多少產品經理理解scrum並不斷實踐？

有多少產品經理說：軟體工程那套東西是程序員才看的，跟產品經理有一毛錢的關係嗎？

這是我剛剛在微信公眾號（yinjianli88）上寫的文章，歡迎關注交流。

產品經理如何有效地管理產品需求

什麼是產品需求？待實現的產品功能對於產品來說就是產品功能。

在實際工作中，我們很容易將「用戶反饋」、「用戶需求」、「產品需求」等相混淆，這是因為很多時候他們所要表達的內容是一致的，比如用戶反饋說微博商業介面中的搜索結果不僅可以按降序展現，最好也可以按升序排列，這是用戶的反饋信息，也是最真實、具體的用戶需求，而產品需求就是在下一版本升級時要增加一個排序參數。

但是事實上，「用戶反饋」、「用戶需求」、「產品需求」這三者有著本質的區別，還是福特汽車那個比較經典的例子。

用戶反饋：一匹更快的馬。

用戶需求：用最短的時間到達目的地。

產品需求：更便捷的交通工具。

由此可見，有時候「用戶反饋」並不等同於「用戶需求」，也不等同「產品需求」，如果錯誤的將用戶反饋當成是用戶需求或者是產品需求，那麼將會造成錯誤的決策，因此對三者進行有效的界定區分是非常必要的。

產品經理首先需從用戶那裡收集反饋信息，分析用戶需求，再根據用戶需求進行產品功能規劃，這些待實現的產品功能對於產品來說就是產品需求。

收集用戶反饋，分析用戶需求，最終都是為了生產產品需求。用戶需求是無限的，相應的產品需求也會各種各樣，因此，如何有效的進行產品需求的管理是非常重要的。

將用戶需求轉化為產品需求

用戶需求收集的來源與方法有很多，包括競品分析、訪談、問卷調查、焦點小組、可行性測試、現場觀察、數據分析、任務和場景分析等，在不同階段應用的收集方法是不一樣的，需求收集是持續的過程，貫穿產品發展的生命周期。

之所以將用戶需求轉換為產品需求再進行管理，是因為多數時候憑藉經驗根據用戶需求制定初步的產品解決方案並不需要耗費多大的精力，卻可以讓我們更加深入地理解用戶需求以及產品需求和產品之間的關係，同時也方便我們準確的評估滿足用戶需求的產品新方案的技術可行性和優先順序。

記錄產品需求的屬性和信息

選擇性的記錄產品需求的一些重要屬性，將有助於我們更好的管理產品需求，如產品需求所屬模塊、產品需求的需求類型、需求方代表等。

產品需求所屬模塊：一個產品往往是一個複雜的功能系統，為了產品更容易分析和開發，產品會被分解為幾個功能模塊，每個功能模塊負責完成產品一部分的系統功能。需求所屬模塊就是產品需求所隸屬的模塊，用來直觀地說明產品需求在產品結構中的具體位置。比如微博數據中心分為粉絲分析、內容分析、互動分析、行業趨勢分析四個模塊，而頁面訪問分析是隸屬互動分析這個模塊。

需求類型：對產品需求進行必要的分類，不僅可以幫助我們更好的管理需求，而且還可以更好的分析需求，對每個需求的價值大小做出更準確的判斷。同樣的產品需求可以按照不同的維度進行分類，具體採用哪種維度可以根據實際需要來決定。比如微博數據中心的後台管理支持系統就要針對代理商需求與零售商需求進行區分。

需求方代表：需求方代表就是最初提出該用戶需求的人員，在產品功能規劃與版本升級時，如果需求方案不得不調整，那麼產品經理可以迅速找到相應的需求方代表進行溝通。比如運營人員提出發票錄入系統的相關問題，在產品實施過程中如果需要進行調整可以快速找到其進行溝通，確保新的產品需求能夠正確無誤地反映用戶的真實意願。

確定產品需求優先順序

考慮到互聯網公司的時間、資源都是有限的，必須對產品需求優先順序進行排序。判斷產品需求優先順序的主要依據是產品需求的投入產出比，即產品需求的產出價值與投入成本之間的比例。除此之外，還要考慮需求的緊急程度、與產品策略的契合程度、需求之間的潛在關係、實際可調配的資源情況等因素。

比如微博數據中心的後台管理系統的代理商返點比例需求是由部門BD提出的，但是在1.0版本就沒有實現，主要就是因為這個需求的優先順序比較低，不是剛需。

跟蹤產品需求進展

產品需求管理是一個持續的動態過程，新的產品需求不斷產生，同時一批批產品需求被實現。產品經理要負責對產品需求的進展進行跟蹤，並時刻更新它們的狀態。需求狀態指的是產品需求在這一刻所處的情況。常見的需求狀態有：待確定、未開始、開發中、已完成、擱置、取消。

除了需求狀態以外，一些和需求進展相關的重要信息也應該被記錄，比如已完成需求的完成時間、擱置需求被擱置的主要原因等等。

文章來源於@尹劍利，微信公眾號（yinjianli88）

尹劍利，微信公眾號@尹劍利（yinjianli88）。研究生在讀，曾創業2次，並在多家知名上市公司實習。熱愛人文歷史，痴迷互聯網。希望遇到更多志同道合的朋友。歡迎關注，多多交流。

前某大廠vp跟班出來答一發。
作為產品經理，你是如何分析和管理你的產品需求的？

其實這個問題提的蠻好的，也蠻壞的。
首先看需求來源，如果需求來源於你的老闆，額，如果你權衡了下覺得拿不準，那就要做。

如果需求來源於其他渠道，那麼就要看了。所以我理解這個問題的本質是：

【如何管理需求池？】

也就是如何吃進去需求，如何再選一些需求去輸出。

那好簡單啊。

先說怎麼去完善自己的需求池。

來源
1.論壇用戶意見
2.app store用戶的評論
3.用戶在app內的留言。。。這類插件友盟什麼的都有，不贅述了

管理
1.打上標籤【技術】【需求】【bug】
2.分類搜集在excel裡面

輸出
1.看看排期
2.看看哪些是值得做的，哪些是可有可無的
3.看看有沒有順手就可以改到這版本的
4.看看值得做的那些裡面，哪些值得最近做

然後就是做~

========================================================
求贊求關注。

。。。你可以去看看項目經理那套wbs分解。。。
用在產品裡面也是妥妥的

敏捷就能解決題主問題啊。

其實題主是在尋求一個產品管理的方法論。這個方法論要有兩個要素：

成熟
團隊認可

成熟的產品管理理論不少了，首推敏捷。但無論是敏捷還是瀑布，一定要在團隊由上而下進行貫徹，形成共識。這個共識，不僅僅是認可，更是共同的知識。要由老闆開始，就理解和認可這套產品理論。所以產品經理們就不要造車輪了，你們是很難拿自己的一套東西在全公司推廣的。團隊共識做不好，產品管理過程就會有扯不完的皮。

下面簡單說下敏捷中怎麼處理需求確認和變更的。

需求確認：

首先需求是誰都可以提的，無論客服、銷售還是掃地大媽，只要是公司成員，都有為產品提出需求的權利。只要說明白用戶故事，即：

作為一個***用戶，需要一個***功能，以便實現***目的。

在敏捷產品管理中，這個格式是神聖的。格式不對，一律直接刪除，就算boss也不能赦免（當然高情商的pm自然知道怎麼做）。

需求是否採納、具體解釋、優先等級等問題，是由po（product owner）負責的。如果遇到懸而未決的問題，po要勇於決斷，團隊也要速度服從。理論上來講，po是由甲方人員兼任的。但在產品團隊中，會是一個高級別的產品經理做這個角色。po的權威性不僅僅來自自身能力，更來自於他是用戶代表。能代表用戶，就意味著要為產品的未來負責，就是說能背鍋。所以擔任po的產品經理，應該是合伙人級別。

需求變更：

敏捷和瀑布的重要區別就是需求是否凍結。如果能在開發前期花大量的時間進行調研和設計，那麼需求會穩定得多。但現在誰會這麼干呢？既然沒有能力確保需求的準確，幹嘛要談凍結？這也就是敏捷提出擁抱變化（Responding to change over following a plan）的原因。當然，敏捷要搭配scrum，將項目周期的粒度儘可能縮小，這樣會減小需求變更產生的影響。

說這麼多。

這個問題有點籠統，需求包含以下幾個方面：
1）如何收集和管理需求。注意合適的歸類整理，別漏掉收集到需求。
2）如何制定合理的優先順序。
3）如何記錄未實現的需求或發現的問題，並制定個合適的優化時間（不解決也是一種解決辦法）。
4）更新你的列表，完整記錄每個需求的上線時間和基本的實現方案。

貼一個之前寫的

我花了超過十年參與開發商業化的高科技產品，並攻讀DBA工商管理博士。

產品開發的商業化、分析和管理有兩個原則，這是（1）市場拉動–你打算出售給已對有產品需要的市場
，或（2）技術推動–你打算把一個新產品推出到市場上，希望人們想買它。
即使有這兩個方面的考慮，有一個總體實施路徑，如下：
第一部分是開始（你要做什麼），設計（你將如何做），開發（實現它），測試它，然後營銷和銷售它。
每個階段將有不同的法律法規，以確保產品的工作是否按照設想運行、是否能保證安全。這也是一個好主意，去檢查產品性能如何（是否容易被破壞），並監測它的市場表現。

我的建議是，作為產品經理，你需要參與到涉及市場營銷部門的所有階段，了解產品從一開始的調研階段到銷售的整個過程。這對於通過「市場拉動」銷售的產品更容易，因為消費者已經知道他們想要什麼。但對於新奇產品，因為市場還沒有見過，所以會更加困難。不過，聚焦人群、深入訪談、調查或者只是和懂行的人和引領潮流的人去聊聊，就可以奏效。

最後我要說，作為一個產品經理，意味著你需要有一個深入的總體觀念並了解所有這些領域，並不斷地向不同的團隊、管理人員和每個同事交流，讓他們參與其中。這個可能是對於產品最關鍵和重要的部分，但不幸的是，不是總能得到應有的重視。

I have spent over a decade involved in commercialising high-technology products, and carried out my DBA (doctorate in business administration) examining this! There are two principles for commercialising, analysing and managing product development, which are (1) market pull – you intend to sell to a market that already wants your product, or (2) technology push – you intend to sell a product new to the market, hoping people want to buy it. Even though there are these two considerations, there is a general path to take, as follows: The first part is inception (what are you going to make), design (how you are going to make it), development (making it), testing it, and then marketing and selling it. Each of these stages will have different legal regulations attached to them to make sure the product works as it is supposed to, and how safe it is. It is also a good idea to check how robust the product is (does it break easily), and measure how it performs in the market. My suggestion is that you involve the marketing department in all of these stages to inform all aspects of the product from inception through to sales. This is easier for products that are sold through 『market pull』 as consumers already know what they want. It is much harder for novel products that the market hasn』t seen before. However, focus groups, in-depth interviews, surveys and just talking to people 『in the know』 and trend setters can be useful for all of this. As a final comment, being a product manager means having an in-depth overview and understanding of all of these areas, and continually speaking to the different teams, managers, and everyone involved in this. This area is perhaps one of the most critical and important for products, but unfortunately doesn』t always receive the attention it deserves.

總結一下，看圖：（源文件在公眾號：產品經理PM資源君，回復：需求管理）

工具只是幫助我們實現目標的，而非目標本身，所以，無論用哪個工具只要能幫忙我們完成目標就好，我們不迷信工具，只相信效率。

現在我們回歸到產品的始末

需求分析-產品生產階段

從產品的可行性分析——編寫可行性分析報告(MRD)——需求收集與導出——需求描述——需求驗證——需求文檔（PRD）。

整個的需求工程，包括了四個階段：

1.可行性分析；

2.需求導出與分析；

3.需求描述；

4.需求有效性驗證。

整個過程走完，你會接觸到該產品的始末，因為需求過程中，涉及到了產品的研發思維及後期的軟體模型，還涉及到競品分析，得到一些新的運營思維，一個產品的戰略思維。

這個過程涉及到文檔如下：可行性分析報告、MRD、需求列表、競品分析文檔、PRD、原型、DOME。

需求工程完成後就是軟體的實現，需求分析前期的工作做好後，初步的軟體模型及軟體的架構基本可成型，具體的流程及邏輯將在實現這個階段進行；個人理解為三大步驟：

設計輸入：平台模型，需求描述，數據描述及邏輯思維圖，腦圖等；

設計活動：軟體架構設計，介面設計，組件設計，系統設計；

涉及輸出：系統體系架構，資料庫描述，介面描述，組件描述；

完成軟體的實現後接下來就是測試，測試一般分三類，介面測試，組件測試，系統測試，最後交付的時候驗收測試；測試階段是一個有效性驗證的過程，也是一個反覆的過程；等到測試完成後就可以進行產品的交付；也可以說一個項目的中止。

如果目前基於中小團隊、不願增加項目成本、開發資源又十分有限的前提下，幾款最適合的有teambition、teamin、worktile、tower 。如果開發資源充足，還可以考慮開源集成的工具，比如Trello和Forecast都提供了開發者文檔，另外還有Redmine、Jira、禪道等各式各樣的項目管理工具可以參考。

如果這些項目管理工具並不能自項目管理上提供幫助反而增加了項目管理負擔，我建議是：選擇一支筆、一張白板和幾張便利貼就可以去實施項目管理流程了。

產品迭代需求分析來源

網站的統計數據

網站上線前應該做好網站統計代碼的部署，比如百度統計、谷歌統計、360統計等等，為了後續上線後搜集用戶行為做好數據準備。

目前這些第三方統計系統做的已經非常完善了，比如可以統計網站的頁面瀏覽量(每個頁面的被訪問次數)、網站的訪問入口頁面（通過哪個鏈接訪問的網站）、用戶來源（來自搜索引擎，還是直接輸入網址訪問），頁面點擊圖統計、頁面熱力圖（用戶點擊了頁面的哪一塊區域）；更高級的功能還可以統計用戶下單量、綁卡量、交易量等等（這點谷歌統計做的非常好），在用戶操作的每一步都可以配合後台做好用戶信息的統計。

有了這些統計數據就好像在每個頁面都安放了一個眼睛，時刻都能掌握用戶瀏覽、註冊、下單、綁卡、支付、生成訂單的進度情況。如果在某一個環節用戶跳出率比較高就可以有目的的進行功能排查或流程優化。

參考競品的迭代功能點

競品在每一版做了哪些改動，是我們應該參考的有力證據。不要完全模仿，要在參考的基礎上進行需求評估，審慎的考量到底有沒有必要也去做這樣的改動？如果有，那就做！做也要再想想有沒有更好的實現方案或交互方式，要弱化模仿痕迹。不鼓勵抄襲，但是如果能在別人造好的「輪子」上做一點優化改進，這也是一種進步。

產品的附屬功能挖掘

任何產品都不可能一個版本就做的完美了！都需要不斷的迭代摸索，用戶需求也是在不斷的摸索中被挖掘出來的。

產品規劃中的其他未完成需求

產品的發展也是分短期規劃和中長期規劃的；

產品都是在不斷的探索中，在圍繞著核心功能進行迭代開發。每一次的版本迭代都應該有利於產品圍繞著規劃目標更進一步，或是有利於後續的迭代朝著規劃目標的功能上靠近。

產品迭代可以做一些錦上添花的工作，但是核心也要保持錦越織越長。

用戶對產品的反饋

產品一般都應該有用戶反饋模塊或者聯繫客服功能，這就是直接搜集用戶反饋的渠道。用戶是最直接的產品使用者，他們反饋的信息和所關心的內容應該作為重要參考的產品升級迭代依據。

普通用戶對產品的理解不如開發人員、產品、運營那麼深入，所以以普通大眾的視角來審視產品才能做出更符合大眾習慣的互聯網產品。

配合運營、市場做相應的推廣模塊

產品迭代應該配合市場、推廣、運營人員工作，積極配合開發出相應的模塊以利於活動的推廣，高質量的推廣活動必然能帶來更多的訪問者和使用者、這是一個相互促進的良性循環。

這是我文章的原地址歡迎大家拍磚：大白PM http://www.dabaipm.cn/static/woshipm/178.html

分析產品需求時，可以先問幾個問題來把握方向？
1. 自己是不是產品的核心用戶？
2. 怎麼接觸到核心用戶，他們是不是核心用戶？
3. 產品能幫用戶解決什麼問題，效率、情感、功能、方法？
4. 核心用戶的行為場景？獨立的，交互的，社區的？
5. 行為的初衷是什麼？自然的？逼迫的？期望的？
6. 行為中的斷點是什麼？
7. 斷點後，用戶場景是怎樣變化的？

需求管理首先是需求的排序，根據用戶具體場景，市場發展形勢，公司戰略，產品資源進行排序和取捨