在產品的整個生命週期中，一定會遇到各種各樣的需求蜂擁而至，包括部門內部由於運營需要而提出的需求，領導心血來潮提出的需求，也有通過使用者投訴或反饋得來的需求，以及通過你個人對自身產品和競品的體驗以及產品的資料分析得來的需求。

同時你還得負責專案的跟進，新版本的規劃等等，在這個過程中你既要面對專案研發過程中的諸多問題，又時時刻刻面臨需求的不斷轟炸，這時候我們就會感覺到事務非常的多且雜亂。

所以，理清楚產品的整個規劃的流程就非常重要，這套流程能夠幫助自己理清思緒，讓你知道你現階段應該做什麼，接下來要做些什麼，這樣才能讓自己的工作非常有條理，也會讓產品的迭代更有節奏。

需求管理

需求管理是做產品的人最首要也是最核心的任務，一款產品遇到的所有的需求最終都將彙集到我們產品人這邊過來，如果沒有及時做好需求的記錄和把控，就很容易造成需求的遺漏，重複記錄等，最後講導致產品規劃的混亂。

產品需求的產生主要有以下四種方式

1.產品研究

產品人每天至少需要對自己的產品以及競品反覆體驗在30分鐘以上，並記下體驗過程中得出來的需求點。

2.使用者反饋

每天定期檢視產品的使用者反饋後臺，自建渠道包括qq群，貼吧，社交媒體是否有使用者投訴反饋，清楚問題之後記下需求點，若是屬於bug或者急需解決的需求，立刻反映給開發解決，若是屬於不緊急的需求，則列入版本迭代規劃中。

3.使用者訪談

如果所在公司有資源，可以定期召集目標使用者群體進行訪談，如果沒有，也可以召集公司或者部門同事進行訪談，詢問他們需求點在哪裡，記錄下來。

4.資料分析

產品人需要每天或者至少一週對產品進行全面的資料分析，輸出資料日報或者資料週報，總結產品遇到的問題，得出需求點，記錄下來。

需求管理表

產品版本迭代規劃

每個特定的時間都需要對產品的現狀進行一番梳理和總結，理清楚產品上線後的效果是怎麼樣的，接下來的方向應該怎麼走。

做產品一定不能盲目地去加各種各樣的需求，或者毫無目的地去做版本迭代。每個版本的需求一定都是基於產品目前的現狀，市場的情況，最後基於產品發展的目的而去做的。

產品規劃包括以下兩點內容

1.月度資料分析

先對本月產品的資料情況進行分析總結，得出問題點，輸出資料月報

2.需求彙總分析

在上文已經提到，我們每天都通過四種方式去採集各種各樣的需求，現在就是運用它們的時候了。

我們就需要把之前收集到的所有的需求點以及資料月報得出來的需求點進行打包，結合資料月報得出來的結論進行綜合分析，然後思考接下來半年的版本迭代規劃。

例如我們接下來半年需要分為幾個版本去迭代，每個版本分別要花多少時間開發，以及每個版本應該做哪些需求。

當然，有一些需求是無法確定什麼時候做的或者是半年以後才有可能去做的，那麼就把這些需求列入到“待定版本需求”中去。

版本迭代計劃表（產品規劃表）

做完產品版本規劃之後，我們就已經把之前收集到的所有需求都封裝到上面那幾個表格中去了。

接下來我們依然需要每天進行需求的收集，但是收集到的需求不能馬上新增到這幾個表格中，而是仍然需要等下一個時間點來了之後，再次重複上文所說的產品版本迭代規劃之後，再將收集到的需求新增到表格中去。

原型設計

半年的版本迭代規劃做完後，對接下來新版本要做什麼需求就非常清晰了，所以接下來就需要將新版本規劃好的需求進行落地了。這一點就不需要我多說了，原型階段應該是最簡單的，每一個入門級的產品經理必經的階段。這個時候的原型不需要做得很細，只要能夠理清需求的邏輯就可以了，因為原型主要是用來和技術對接的，把需求講清楚就可以了，更細節的產品邏輯需要通過完整的需求文件來描述。

技術對接

完成新版本的原型設計之後，此時上一版本的需求技術估計也差不多開發完了，那麼接下來就是召開技術的對接會議，當然，撕逼是免不了的啦，你之前規劃好的版本迭代計劃一定會因為各種技術實現原因而大動刀子。

經過技術對接會議之後，我們需要將產品的需求點以及需求原型通過郵件傳送給技術，讓技術評估需求的問題點以及實現難度。評估結果出來之後，產品部門內部需要進一步地討論，此時我們要做的就是去調整版本規劃表的需求劃分，例如有些需求這個版本不能實現的，就下移到下一個版本，有些需求壓根不能實現的，就直接刪除，有些需求實現難度太大的，就可以直接放到待定版本需求裡面去。

需求文件

經過技術的評估，產品部門內部討論之後，新版本的需求和原型基本就定下來了，此時並不能馬上就把需求和原型遞交給技術就完事了，因為原型畢竟是通過原型軟體畫出來的，不是通過文件寫的，很多產品的細節邏輯無法很清晰地通過大量的文字寫出來，這樣會導致技術需求理解不清楚，這樣後面就會導致各種各樣的問題，不僅如此，在產品開發的過程中一定會遇到各種需求變更的情況，每一次對需求的修改都需要做一次記錄，這樣方便專案組檢視，也有利於後續對需求變更記錄的追蹤。所以，總體來說，詳細的產品需求文件是必不可少的。

專案跟進

專案跟進之前，產品人需要和技術去溝通需求實現的時間節點，例如前端的哪些需求在哪個時間點能完成，後端的哪些需求在哪個時間點能完成，將溝通後的結果輸出成專案里程碑，產品人要做的就是盯著技術是否按照專案里程碑上面的時間節點完成需求的開發，如果不行，該趕就得趕，該撕逼還得撕逼，隨時準備為專案順利上線犧牲。