怎麼尋找產品需求池

❶ 新產品開發的流程

新產品開發的流程？
1、調查研究階段
發展新產品的目的，是為了滿足社會和用戶需要。用戶的要求是新產品開發選擇決策的主要依據。為此必須認真作好調查計劃工作。這個階段主要是提出新產品構思以及新產品的原理、結構、功能、材料和工藝方面的開發設想和總體方案。
2、新產品開發的構思創意階段
新產品開發是一種創新活動，產品創意是開發新產品的關鍵。在這一階段，要根據社會調查掌握的市場需求情況以及企業本身條件，充分考慮用戶的使用要求和競爭對手的動向，有針對性地提出開發新產品的設想和構思。產品創意對新產品能否開發成功有至關重要的意義和作用。
3、新產品設計階段
產品設計是指從確定產品設計任務書起到確定產品結構為止的一系列技術工作的准備和管理，是產品開發的重要環節，是產品生產過程的開始。
4、新產品試制與評價鑒定階段
試制後，必須進行鑒定，對新產品從技術上、經濟上作出全面評價。然後才能得出全面定型結論，投入正式生產。
5、生產技術准備階段
在這個階段，應完成全部工作圖的設計，確定各種零部件的技術要求。
6、正式生產和銷售階段
在這個階段，不僅需要作好生產計劃、勞動組織、物資供應、設備管理等一系列工作，還要考慮如何把新產品引入市場，如研究產品的促銷宣傳方式、價格策略、銷售渠道和提供服務等方面的問題。

❷ 如何做好需求管理

需求管理從我工作的總結來看有以下幾點 1.客戶的需求， 從客戶角度找到產品的核心的功能和用途，分析出客戶對產品的要求的模型，最關注和重視的是哪些功能，並且從現有的數據和反饋中篩分出真正的客戶需求，而不是從客戶反饋簡單判斷客戶是不是要這個東西，喜歡和討厭某個功能，為什麼喜歡和討厭。。。以及客戶的「建議」也需要去分析和判斷。 2，公司的需求， 包括公司的商業規劃，盈利的方式，盈利指標等等，以及公司高管和其他部門對產品的界面、功能、流程一些理解和要求。 3，其他部門的需求 其他部門對產品的工作量，技術門檻，資源是否滿足等，以及產品項目對他們本身的利益等需求。

我們現在使用的日事清可以將讓需求人員將需求輸入到「收集」狀態，由產品助理集中處理，視需求具體情況將需求拖拽到其他集中狀態。如果拖拽到「確認」，在該需求下添加相應技術人員讓其處理，技術人員會在日事清協作系統內收到通知並且需求同步到其收納箱，方便技術人員集中處理，解決後由技術人員拖拽到「已解決」狀態卡片。

❸ 如何做產品業務需求調研

怎麼做需求分析？

能夠像主角鎮長一樣找到村民真實的需求呢？

首先，需求分析應該服務於用戶，所以要以用戶為中心做需求分析

其次，需求分析後要形成一份PRD，讓團隊里的人更流程地工作，減少溝通成本

那麼，它的步驟是怎樣的？

第一步：給你的產品定個位

「請用一句話描述你的產品」

（結構是：主要面向XX用戶，提供XX功能，具有XX特色）

這個方法誰用誰知道，如果很難描述出來的話，你的這個產品就定位有點模糊了，方向也不明確。

第二步：找到初步需求

首先，通過用戶研究、頭腦風暴等方法，產出用戶需求示意列表

得到初步需求後，先把不可實現、不合理、價值不大、無適合場景的需求剔除。——篩選

然後，挖掘用戶的目標，找到用戶真實的需求。——挖掘

這里需要注意的兩點是：

1、傾聽用戶並不等於聽從用戶

2、用戶想要什麼不等於真實需求

接著就是匹配產品定位，找出產品主要功能和特色功能。——匹配

最後就是根據項目的資源來確定需求的優先順序

❹ 需求收集、分析、管理的方法

這個專欄將定期發布產品部關於產品設計方面的思考。主要有以下四個方面：1）產品規劃 2）用戶需求探討 3）產品設計過程思考 4）競品分析。

開設這個專欄的目的很簡單，主要有兩個，一是讓公司各位同事能隨時了解並參與到我們產品設計的環節中，同時能通過這樣的平台給我們多提意（tu）見（cao）。二是通過這樣的專欄也能倒逼我們更多地思考，提高自身的產品設計能力，從而設計出更好的產品服務大家。。

這是我們產品部的第一篇關於產品設計思路的文章，想了很久要怎麼寫，從什麼角度開始。最後我覺得任何產品的起源都來自需求，這期就主要聊聊我們是如何收集、分析和管理需求的辦法。如考慮不周的也請各位多多指正。

首先是我們如何進行需求收集的。主要有三個方面：

畢竟老闆對行業和業務比我們熟悉太多，前期需要吳校和各位大佬多給我們提意見和想法，幫助我們產品方向不會跑偏。

目前我們的用戶反饋包括兩個環節，一是開發前我們將產品需求轉化為原型DEMO，同時我們會選取對此產品最熟悉的用戶並把我們的原型一一和他們進行確認，如果還有問題則繼續調整原型，如無問題則可進入開發階段。如極運營在最初的產品設計時我們與財務同事確定需求不下10次，同時也到各校區找到相應負責人進行了多輪的溝通和確認工作，收集了大量寶貴的意見。（這里要特別感謝申琴，在前期我們產品對極運營的需求一無所知時，是她在反復耐心地給我們講解需求）

二是開發完成上線後我們通過面聊或通過《需求反饋表》給我們反饋的需求。我們目前使用的需求反饋表還用的是比較傳統的excel表格，後期會考慮做成簡單的系統，這樣採集反饋問題更及時，反饋人也能更方便了解自己反饋需求的狀態。

當然，在整個用戶反饋環節，我們也有需要反思的。比如需求調研覆蓋的面還不夠廣，覆蓋的層次還不夠多，包括各大區不同崗位層級的用戶還沒來得及全部溝通到位，後續我們也會在此投入更多精力。

從進公司到現在，產品部已經完成兩版的競品分析報告，也分析了大量教育類產品，從中收獲非常多。無論是對整個行業軟體水平的了解，還是學習借鑒優秀產品，都幫助我們對行業內產品有了更深的了解，後期有機會我們會把這些分析報告整理後發出，希望引發大家更多的思考。不過關於競品分析，有一點需要我們注意的： 競品畢竟是競品，它的業務場景可能和我們不一樣，不能直接，需要辯證的分析它存在場景的價值和意義。

就在前段時間有老師給我們提出，學而思和新東方都在課堂上使用答題器收集學員課堂學情數據。於是我們在網上也做了相應競品調研，看了很多課堂使用答題器的視頻，發現確實通過答題器收集學員學情數據很方便，既能調動課堂氛圍還能產生學情數據。但隨著調研深入，同時我們也到學而思和新東方線下課堂去體驗，發現他們線下面授課無一例外都沒用到答題器，只有雙師模式才在運用。對這一現象，我們認為，基於現有的線下小班授課的課堂答題器數據採集的迫切性不高，學員只要通過舉手或老師挨個查看學員作業就能很快收集到班級學情數據。而雙師模式需要一個老師覆蓋幾個班，上百人，同時還是遠程教學，實時掌握學員學情數據就必須通過答題器這種模式實現。從另一方面答題器的成本也相對較高，不僅是軟硬體投入成本，還包括課堂、課後管理成本都會帶來較大麻煩。我想這也是答題器雖然已經很成熟但仍在傳統課堂中使用不高的主要原因吧。

當然除以上幾種需求收集方式外，我們目前還缺少通過數據反饋中收集需求，比如通過在產品中對功能進行數據埋點，獲取各功能使用情況的數據，從中了解用戶的使用頻率及習慣來獲取需求。這個部分我們會在後續開發中逐步加入，畢竟人可能會說謊，但數據不會。

需求收集完，自然是需要對需求進行分析、過濾、篩選，從中去偽存真和優先順序排序。首先我們需要區分收集上來的需求是真需求還是偽需求。有時真的很難區分，很多需求看起來都無比真實，但還原到實際場景卻是個偽需求。

舉個我自己提偽需求的例子，當時我剛到極客，希望快速提升產品逼格，於是聯繫到一家自動批改數學主觀題作業的公司。那家公司在做主觀題數學作業批改上確實很牛，在2016年通過它們的高考機器人參加北京數學卷考試得了105分。我當時希望能通過引進它們的自動批改作業功能，幫助咱們的老師減輕工作量。但後來我把這個產品推薦給老師時，存在兩種截然相反的態度，一種是認為有這個功能太好了，能幫助老師減輕工作量，甚至可以完全可以不要助教了。另一種認為其實老師批改作業的時間也佔用不到太多，必要性不強。後來我們產品也經過多次內部溝通、討論，到實際上課和作業批改場景里實地調研，發現確實有問題。一來是我們很多老師本來就有助教，這些批改作業工作會交給助教完成。即使沒有助教，我們的班級都是小班教學，一個班也就十幾二十個學生，每次作業也就不到半小時能搞定，而且老師在實際批改作業時還能快速了解孩子學情狀況。這個自動批改作業的需求雖然從表面粗略一想完全合乎需求，但還原到真實場景里卻就不是那麼回事。

從這件事里也讓我總結出如何識別偽需求的兩個心法： 1）任何需求必須還原到具體應用場景去思考和分析 2）不要看用戶怎麼說，關鍵看用戶怎麼做。

需求去偽存真後，還需對真實需求進行優先順序排序，分清需求的輕重緩急和節奏對產品設計也非常重要。現在我們的做法是把收集上來的每一個需求都錄入到禪道（軟體項目管理平台）的需求池裡，每次規劃下一個版本時我們會從需求池裡根據輕重緩急把需求重新梳理和設計，並把需求移到下一個版本中進行排期開發。

這里需要重點講講我們關於需求優先順序排序的方法。很多人講把需求優先順序通過緊急、重要兩個維度生成四個象限， 重要緊急〉重要不緊急〉緊急不重要〉不重要不緊急 。當然，這個處理需求的原則沒有問題，但沒有定義什麼需求重要什麼需求緊急。其實緊急這個維度很好判斷，取決於 交付時限、任務依賴 。交付時限是指需求最終截止期限，如果過期上線將對業務有較大影響。任務依賴是指該需求是某個流程中的一環，如果缺失這一環將對整體流程造成影響。但重要這個維度就很難的定義，我認為重要維度有兩個因素： 影響范圍、商業價值 。影響范圍很簡單，是指能滿足多少用戶的需求。商業價值是指該需求能對用戶帶來多大價值或給公司帶來多大的競爭優勢。

分清了重要和緊急的定義，我們就可以以量化的方式對優先順序進行排序。量化的方法就是把重要和緊急兩個維度滿分設置為5分，分別定義需求兩個維度的分值然後兩項相乘就得出該需求的總分，最後根據總分再進行排序。

當然，以上需求管理辦法主要適用已經上線的產品功能迭代，新項目開發需求還不適用。因為新項目開發會利用大量研發資源，也存在一定風險，而現在來自各個部門越來越多的新項目需求，這樣的需求開發與否以及優先順序排序就不能只在產品部內部進行決策，需要上升到公司級層面共同決策。因此後期我想可以通過在公司內部成立<產品評審委員會>的形式，召集公司產品智囊團在更大范圍內對產品方向、規劃進行探討和決策。

以上是本期產品部關於需求收集、分析及管理辦法的分享，過程中肯定有不完善的地方，也希望大家多多批評指正，幫助我們及我們設計的產品共同成長！

再次感謝大家利用寶貴時間看完此文，我們下期見！