產品新人想要快速地成長，不僅需要時間和經驗的積累，還需要主動地沉淀，形成自己得框架。

入產品坑已1年有余，是該有寫一點東西的必要了。真的該有寫一點東西的必要了（借用一下魯迅先生的手法~）在不斷的practice后，總結下來，大致總是以下這4個方面的事情：

一、需求管理

據我這1年多近2年的臨床經驗，雖說資歷不夠，但不多不少，還學到點東西~

相信所有的產品新人剛入行時，接觸的最多的行業概念都是“需求”吧，當然我也不例外，也是從需求開始做起，到現在帶小組做項目，自己經手產品從0開始到上線的方方面面。

1. 需求收集

其實一開始上司大多會讓你去跟進一些功能優化的需求，因為這只需要在了解業務的基礎上，對功能優化點進行跟進即可，幾乎沒有難度。這階段還不知道怎么去挖掘需求。

當你跟需求有一段時間后，你的疑問就來了，為什么要這樣優化？是誰提的要優化？做了這個優化對什么東西造成什么影響…… 也就是產品人常常掛在嘴邊的需求分析的5W+1H原則了。

跨過了這個階段后，就到了收集需求階段。需求收集無外乎3個來源，3個途徑：

需求來源

• 公司相關業務部門（市場、運營、銷售、客服等）
• 用戶/客戶
• 產品經理/老板創造需求（這需要產品經理本身具備很高的產品素質）

PS：喬老爺子曾經說過：People don’t know what they want until you show it to them”（在你把東西拿出來之前，用戶根本不知道想要什么）。前人留話了，有時候，我們需要去創造需求。但世界只有一個喬布斯，因此我們還是腳踏實地，仰望大佬吧~

收集方式

• 用戶調研/ 反饋：問卷調查、用戶訪談、信息采集（包括工作人員在內）
• 來自boss的idea（boss根據他對市場的敏銳度做出的決策）
• 產品數據分析：功能數據、市場數據、競品分析數據

產品從無到有階段，需求來源多半是由產品經理/老板用數據分析的方式獲得需求。項目落地實施階段，需求來源大多是從用戶調研/反饋得之。項目運行數月后，用戶反饋、數據分析則變成了主要的收集方式。

2. 需求分析

需求分析，用哲學上的一句經典名言來說：從哪里來？要到哪里去？這句話用在需求分析上再合適不過。延伸一下，就是需求分析的5W+1H原則了：

• what：需求是什么？
• who：誰提出來的？
• why：為什么要做這個需求？
• where：什么場景下有這個需求?
• when：該場景下的什么時候需要用到這個需求？
• how：怎么做這個需求？

有時候，用戶的需求并不會很直接的告訴你。好比女生在和男生交往的過程中，某天拿著美妝博主的試色圖片和對方說：你看她涂這個顏色真的好好看哦。這時鋼鐵直男和情圣的反應就完全不一樣了。

直男：我覺得都一樣啊，都是紅色，并附帶黑人問號臉；情圣：確實好看，也很適合你哦(過兩天約會的適合用精美的禮盒包好送到女生手里)。同樣的話，不同的答案造成的心里落差，可謂千差萬別??！

有時候，或者說用戶根本不知道自己要什么（前面提到過）。你需要去引導，或者去思考用戶言語背后的真實需求。

共享單車出來之前，我想大家都有最后1公里的困擾。但那時候，如果你跟別人說，公司去地鐵站好遠啊，坐公交很堵，走路又太慢，那對方對半會跟你說：買電動車吧，騎車去公司；買個代步車吧等等。

直到摩拜單車出現在大眾視野，我們才知道，自己不過是想要解決最后1公里的困擾（想給共享單車的發明者加雞腿）。其實這樣的例子很多，只要仔細留心身邊的一切。

3. 需求跟進

據我這1年多的“臨床經驗”，一個需求的完整生命周期可以劃分為6個部分：

1. 需求確認階段：該階段需要將收集到的需求加以確認，再根據需求的重要程度進行優先級排序。一般是在月初，因此一般會定下本月要做的需求（這個視團隊習慣而定）。
2. 需求設計階段：這階段產品們會將需求轉換成原型圖，并且將初版的prd輸出，發送到團隊群內。供研發團隊進行一個初步的技術評估。
3. 需求再確認&開發排期：開發和產品們會就第二階段產品輸出的原型及prd進行一次頭腦風暴及需求確認，確保雙方的理解一致，減少后期因為理解偏差造成的影響。
4. 需求跟進階段：產品會根據上一階段的開會結果，重新整理prd，發到團隊的協作平臺上，并及時更新。協作平臺的內容包括各個系統的需求池，以及問題記錄。當然，產品還會實時跟進開發進度，處理開發在開發過程中遇到的各種疑難雜癥。
5. 測試驗收階段：以PRD文檔為準進行測試驗收(PS：小公司有可能根本沒有測試，因此產品還要承擔測試的工作)。開發根據測試結果進行問題修復，全部修復完成后，提交代碼，發布上線。
6. 運維階段：需求上線，并不是需求的終點，而是產品投入市場的起點。需要產品人通過跟進用戶反饋，對正式數據進行對比分析，驗證是否真的滿足用戶需求。然后不斷的更新迭代~

PS：運營階段還有一件重要的事，在需求上線之前，一定要和各個需使用到該需求的業務部門溝通好，甚至說培訓好。否則上線后，會措手不及，甚至導致各部門之間的不愉快~

二、產品設計

清楚地記得，第一次設計的產品是一個APP的訂單列表頁面，現在看來這不是信手拈來么，但當時由于業務不熟，產品概念還未形成，以至于根本不知道從哪里下手。

幸好有巨人的肩膀可以站立，通過對其他APP的借鑒和模仿，倒也沒出什么邏輯問題，只是設計缺乏重點，如圖(大家可盡情吐槽)：

?圖2-1

1. 前端

前端也可籠統的稱為客戶端，在沒有微信小程序之前，前端有APP設計，WEB設計。

微信小程序的風刮起來后，做前端的產品還需做微信端設計。一般情況下，都是APP+微信小程序組合~

前端產品既要好看，更要實用，二者缺一不可。但非要說一個更重要的，那還得是“實用”。畢竟，解決用戶問題的產品才是好產品~

入行的時候這個觀念就已深深藏在我腦海里，因此我一直都特別注重實用~ ?差點忘記好看，所幸公司的UI設計師一定程度上彌補了我的不足。

在反復和設計師交流的過程中，了解了一些“好看”方面的知識（同設計師交流，必須多學點UI方面的知識，不然怨念很深~）

另外沒接觸過微信小程序設計的同學，做之前，請一定要先看微信小程序設計規范??！不要問為什么，等做出來四不像時，你就知道為什么了。

2. 后臺

后臺系統常見的有開放式后臺系統和非開放式后臺系統。相對來說，公司大多都還是非開放式后臺用的多些。

開放式后臺系統常見的有：微信公眾平臺、淘寶賣家平臺等；開放式的后臺在用戶體驗上會稍微注重些.

非開放式后臺不會在界面上提供注冊功能，后臺系統用戶的添加一般是擁有相關權限的管理員添加配置，最常見的是ERP系統。(這1年多，我從專門負責1個ERP后臺&APP，到現在同時兼顧2個。由于前1個系統已經非常穩定，因此大部分時間都放在維護今年3月開始的新系統上~）

后臺設計，非常注重業務邏輯的流轉，在沒有了解清楚業務的每個細節前，千萬不要輕易下手。否則后面會有無止境的修改(開發心里會罵你一百遍，就問你怕不怕)。流程圖是必須的，重要功能的時序圖也是必須的；

這是很久之前畫的比較籠統的促銷活動流程圖和時序圖（獻丑了）：

2-2-1 流程圖

2-2-2流程圖

三、數據分析（功能）

數據分析不可謂不重要，一切想法要論證是否正確，都必須通過數據說話。但剛入行根本沒有數據概念，一心埋頭苦干。

直到某次作報告，總監問到我轉化率是多少的時候，我一頭霧水……才開始關注數據。

PS：首先聲明，這里說的數據分析特指功能數據分析，不泛指行業、市場等數據的分析，這種分析可在數據分析網站上查看行業報告。就不細說，最主要是我覺得以我目前的知識面來說，不足以將這種數據看的透徹~

1. 數據來源（常用的有2種）

1. 采用基于前端頁面的數據采集工具獲取，如小程序的數據助手等可視化的數據采集產品；
2. 通過數據埋點的方式，在開發時根據設計提出的需要埋點的地方進行數據采集，需要時從數據庫導出查看即可。

2. 優缺點對比

用數據采集工具

• 優點：不用費時費力去做開發，方便快捷，一般都有載體產品，可隨時查看；
• 缺點：特定的數據無法自定義，統計數據相對概念化。

通過數據埋點可

• 優點：可自定義任何自己想要的數據，尤其能夠滿足特定場景下的特定場景的數據統計；
• 缺點：費時費力，需要人工成本較高，從前期到設計都需要耗時耗力；

PS：附一張數據埋點的表（僅供參考，請多指教）

四、項目管理

PS：由于是中型創業公司，組織機構不夠完善，并沒有項目經理的存在，因此，我們產品基本上承擔了項目經理的責任；

由于本人資歷尚淺，經驗不足，在項目管理方面，我只做到了解每一個人的性格&做事風格。

甚是幸運，這1年多與項目小組的所有開發人員都相處得十分愉快，項目進行的也很順利。大概是他們性格好，又肯配合，技術又很給力(給他們加雞腿，真的給力)！這一年，我們項目組每月的績效，半數以上都是超過100%的~

關于項目管理，過個幾年在來寫可能會不那么尷尬，現在寫有種小孩扮大人的感覺~暫時就寫這么多，謝謝大家，歡迎大家指出我的不足之處，和我交流心得體會，但不歡迎噴子~

本文由@lucky 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議