前言：可能有一些產品新人在面試的時候經常被問產品經理工作內容，在這裡不談那些高階產品經理的工作內容（產品戰略、需求發掘、專案管理…）只談談初級產品經理的工作內容，因為我作為一名產品新人，暫時接觸的一些具體工作而已。

一、使用者調研

使用者調研分為定性分析和定量分析。定性分析是指使用者訪談，定量分析是指調查問卷。
使用者訪談。當然訪談需要一定的技巧，更多的傾聽為主，以瞭解使用者的內心想法為主。訪談時對使用者的初步回答反覆追問“為什麼”，引導使用者從表面的行為開始思索，清理出行為背後的動機、需求乃至價值和文化觀念。
調查問卷。問卷調查是一項有目的的研究實踐活動，設計的問卷是為你的特定研究目的服務的，這是設計問卷之前必須植根於腦海中的一個觀念。既然問卷調查是一項有目的的研究實踐活動，那麼從理論指導實踐的角度出發，在設計問卷前必須要做好充足的理論準備，巨集觀層面上應做到以下兩點：

1.明確你們研究的主題是什麼？

2.明確你們想通過問卷調查獲取的資訊有那些。通過調研問卷你可以定量的驗證你提出的需求。

二、需求的收集，建立自己的需求池

收集各個部門的需求，建立自己的需求池。並定期對需求池進行整理。你的需求池裡面有不同人提出 的需求。
需求來源：需求池裡面有可能包含老闆提出的戰略性需求、客服反饋的需求、使用者訪談得來的需求、調查問卷得來的需求、資料分析得來的需求。記錄好每個人提出的需求，這樣當你在做需求分析的時候如果不知道需求後面的本質需求， 你可以找到那個人進行了解,這樣有助於你把握需求的本質。
定期對需求池做一定的梳理。產品部門定期讀需求池進行整理，那些需求是下一步要做的，那些需求是是可以暫緩的，那些需求是不做的，對需求池進行梳理和分類。

不同終端的需求要分開。分為APP、PC、微官網、前臺、控臺這些。

這裡提供一份模版：

三、產品迭代前寫一份立項報告

通過對需求池的整理以後，你決定要做那些不做那些。需要出一份立項報告和技術部門過一下，這樣技術 可以安排開發週期。技術也可以從技術的角度給一些意見說那些可以做，那些可以暫時不做，這樣技術在開發之前有一個心理預期，這樣在你開原型評審會的時候阻力會小很多。這裡教給大家一個小技巧：做立項報告的時候可以多寫一些需求，這樣多一些的需求可以給技術砍掉。

四、競品分析

俗話說知己知彼，百戰不殆。你做的東西別人也在做，買東西都還需要貨比三家呢。做競品分析有兩個目 的，第一、揚長避短。吸引別人做的長處，發現別人做的不足的地方。第二、驗證與測試。別人上的這個功 能市場反饋怎麼樣，有沒有遇到啥問題，通過競品確定市場機會點。
競品分析有一定的流程。可以從“戰略層-範圍層-結構層-框架層-表現層”這幾個層面進行分析。

(1).戰略層：確定競品的商業模式、產品定位、市場狀況、盈利情況等，目的是確定方向，瞭解市場。

(2).範圍層：競品的目標人群，滿足了什麼需求，使用者的滿意度如何，目的是參考競品的目標人群以及需求的重要度。

(3).結構層：競品的主要功能架構、特色功能、發展模式，優缺點總結，目的是尋求差一點。

(4).框架層：競品主要任務流程的順暢，互動的細節，邏輯的準確，頁面的框架，目的是優化流程，提高使用者體驗。

(5).表現層：競品是視覺風格，顏色層級，文案的運用等，目的是維持使用者對這類產品的傳統認知的基礎上打造產品獨特性。

五、原型評審和PRD文件製作

競品分析做完以後，開始根據競品分析的結果。開始自己的功能設計，流程的繪製，在原型上加一些功能的註釋，這樣在敏捷開發的時候可以節省PRD文件的製作，也可以在和技術開會的時候不會遺漏自己想講的東西。
原型評審的時候技術人員的有效意見一定要虛心接受，不要覺得自己是產品就高高在上，涉及到原則問題堅 持。別人提的有益意見也要虛心接受，只有這樣你才能避免死逼，專案才能儘快落地。至於PRD文件的制 作。有時間的話可以寫word文件，沒時間的話可以直接在原型中製作文件。
但文件必須包含的部分有：

(1).產品版本的迭代歷史。清晰的告訴專案成員每次改變都改了那些東西。

(2).需求功能清單。有需求功能清單 的時候技術人員在開發的時候才不會遺漏，測試工程師也會根據你的需求功能單來進行測試。

(3).全域性結構圖和重要的功能流程圖不能少。全域性結構圖。產品全域性結構圖相當於房子的骨架，相當於文章的目錄，別人看過你的全域性結構圖就知道你的產品大概分成那幾個部分。其次，一些重要的功能流程圖需要 寫，這樣有助於開發人員思路的建立。

(4).異常流程要考慮清楚。只有異常流程考慮清楚產品經理才不會挨批，技術開發起來才不會出現問題。

(5).重要名詞要定義。對於首次出現的名詞需要定義，這有這樣別人在看到名字的時候才不會有疑問，再跑來找你問。

六、專案管理

專案進度表。文件交給技術開發以後，就需要制定一個專案時間表，並向領導彙報。首先要全面地收集他們在聽完需求文件評審後對於產品本身的意見與建議，然後逐項予以合理的解釋，以保證程式設計師哥哥們打心底裡認同這個產品，認同這個產品的每一個需求。另外作為一個PM，也應該要對基本的開發流程有所瞭解在制定每個需求的開發週期時提出正確的建議，保證最終的專案開發時間表既不會拖慢整個專案的進度，也沒有超出程式設計師哥哥們每天正常的工作量，保證他們不會感到過大的開發壓力。
進度跟蹤。對於專案進度要做到心中有數，每天更新專案進度表，並幫助技術解決他們在開發過程中遇到的問題，並將自己看到的潛在問題儘量扼殺在萌芽中。當然，跟進並不是天天問工程師進度，需要給他們鼓勵打氣，並描述產品的未來前景，讓團隊中的每一個人都感受到自己的重任並願意承擔。可能有些團隊裡面是CTO擔任專案經理，這也無可厚非，畢竟在專案成員中程式設計師佔了大半資源，當然產品經理要儘量參與這個過程當中。不能當局外人。

七、產品上線前協助測試

大公司有明確的職位分工：工程師、測試、設計、運營都由不同的人負責，測試自然是測試工程師的事，而 在中小型創業公司，人員匱乏，很多團隊只有工程師和產品經理，工程師負責開發，開發以外的事情全都由產品經理承包，這 其中自然包括測試。但無論如何產品經理都要儘量參與測試工作，保證產品是按照你的預期做出來的。
(1).首先與測試組溝通協作，確定產品測試排期。

(2).跟進測試進度參與產品測試。

(3).將測試出來的bug記錄下來，並拍好優先順序，反饋給技術來發人員。

功能測試是合格產品經理的必備素質，產品經理要協助測試工程師完成測試報告並敦促工程師團隊改進產品。

八、產品培訓和推廣

給業務方培訓、推廣產品。客服可能需要給使用者解答問題，所以每次迭代的內容都需要給客服培訓，好讓客服組織話術來應對客戶隨之而來的一些問題。同時也需要給市場、運營等部門培訓，讓他們知道產品到了那些階段，有那些改變，一是讓各個部門之間知道自己正在做的事情，二也好讓營銷市場部門做好宣傳與推廣。
收集產品使用反饋，為迭代做準備。產品上線後設計的好不好，有哪些使用者滿意的，有那些使用者不滿意的。都會有使用者進行反饋，收集並分析這些使用者需求，並記錄在你的需求池裡面，為下一次迭代做準備

九、資料分析

產品上線後產品設計的好壞很大程度上能從資料上體現出來。例如你設計個活動分享頁面，使用者可以通過好友分享的介面直接註冊，那麼你就要統計這個頁面的點選量、PV/UV、頁面訪問市場、訪問深度、使用者的跳出率、使用者的轉化率等來評估你設計的好壞，以及活動的效果。再比如你產品進行改版，你需要評估改版的好壞。你就需要關注30日留存率提高了還是降低了，別關注7日留存率。因為你的產品剛更新你的粉絲使用者可能會很活躍，導致7日留存率變高，這個時候你說你的改版比較成功可能沒有說服力，也許30日以後你的使用者活躍度變低了，30日留存率也變低了。

十、總結

這就是初級產品經理的日常工作流程，每個公司可能根據自己的不同情況有些流程會有增減，但基本上是這些，僅僅是個人經驗而談，歡迎大家補充指導。