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

1、用戶調研

用戶調研分為定性分析和定量分析。定性分析是指用戶訪談，定量分析是指調查問卷。
用戶訪談。固然訪談需要1定的技能，更多的聆聽為主，以了解用戶的內心想法為主。訪談時對用戶的初步回答反復追問“為何”，引導用戶從表面的行動開始思索，清算出行動背后的動機、需求乃至價值和文化觀念。
調查問卷。問卷調查是1項有目的的研究實踐活動，設計的問卷是為你的特定研究目的服務的，這是設計問卷之前必須植根于腦海中的1個觀念。既然問卷調查是1項有目的的研究實踐活動，那末從理論指點實踐的角度動身，在設計問卷前必須要做好充足的理論準備，宏觀層面上應做到以下兩點：

1.明確你們研究的主題是甚么？

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

2、需求的搜集，建立自己的需求池

搜集各個部門的需求，建立自己的需求池。并定期對需求池進行整理。你的需求池里面有不同人提出 的需求。
需求來源：需求池里面有可能包括老板提出的戰略性需求、客服反饋的需求、用戶訪談得來的需求、調查問卷得來的需求、數據分析得來的需求。記錄好每一個人提出的需求，這樣當你在做需求分析的時候如果不知道需求后面的本質需求， 你可以找到那個人進行了解,這樣有助于你掌控需求的本質。
定期對需求池做1定的梳理。產品部門定期讀需求池進行整理，那些需求是下1步要做的，那些需求是是可以暫緩的，那些需求是不做的，對需求池進行梳理和分類。

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

這里提供1份模版：

3、產品迭代前寫1份立項報告

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

4、競品分析

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

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

(2).范圍層：競品的目標人群，滿足了甚么需求，用戶的滿意度如何，目的是參考競品的目標人群和需求的重要度。

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

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

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

5、原型評審和PRD文檔制作

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

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

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

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

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

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

6、項目管理

項目進度表。文檔交給技術開發以后，就需要制定1個項目時間表，并向領導匯報。首先要全面地搜集他們在聽完需求文檔評審后對產品本身的意見與建議，然后逐項予以公道的解釋，以保證程序員哥哥們打心底里認同這個產品，認同這個產品的每個需求。另外作為1個PM，也應當要對基本的開發流程有所了解在制定每一個需求的開發周期時提出正確的建議，保證終究的項目開發時間表既不會拖慢全部項目的進度，也沒有超越程序員哥哥們每天正常的工作量，保證他們不會感到過大的開發壓力。
進度跟蹤。對項目進度要做到心中有數，每天更新項目進度表，并幫助技術解決他們在開發進程中遇到的問題，并將自己看到的潛伏問題盡可能抹殺在萌芽中。固然，跟進其實不是每天問工程師進度，需要給他們鼓勵打氣，并描寫產品的未來前景，讓團隊中的每個人都感遭到自己的重擔并愿意承當。可能有些團隊里面是CTO擔負項目經理，這也無可厚非，畢竟在項目成員中程序員占了大半資源，固然產品經理要盡可能參與這個進程當中。不能當局外人。

7、產品上線前協助測試

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

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

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

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

8、產品培訓和推行

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

9、數據分析

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

10、總結

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