可能有一些產品新人在面試的時候經常被問產品經理工作內容，在這里不談那些高級產品經理的工作內容（產品戰略、需求發掘、項目管理…）只談談初級產品經理的工作內容
一、用戶調研
? ? ? 用戶調研分為定性分析和定量分析。定性分析是指用戶訪談，定量分析是指調查問卷。
用戶訪談。當然訪談需要一定的技巧，更多的傾聽為主，以了解用戶的內心想法為主。訪談時對用戶的初步回答反復追問“為什么”，引導用戶從表面的行為開始思索，清理出行為背后的動機、需求乃至價值和文化觀念。
調查問卷。問卷調查是一項有目的的研究實踐活動，設計的問卷是為你的特定研究目的服務的，這是設計問卷之前必須植根于腦海中的一個觀念。既然問卷調查是一項有目的的研究實踐活動，那么從理論指導實踐的角度出發，在設計問卷前必須要做好充足的理論準備，宏觀層面上應做到以下兩點：1.明確你們研究的主題是什么 2.明確你們想通過問卷調查獲取的信息有那些。通過調研問卷你可以定量的驗證你提出的需求。
二、需求的收集，建立自己的需求池
? ? ? 收集各個部門的需求，建立自己的需求池。并定期對需求池進行整理。你的需求池里面有不同人提出? ? ? ? ? 的需求。
需求來源：需求池里面有可能包含老板提出的戰略性需求、客服反饋的需求、用戶訪談得來的需求、調查問卷得來的需求、數據分析得來的需求。記錄好每個人提出的需求，這樣當你在做需求分析的時候如果不知道需求后面的本質需求， 你可以找到那個人進行了解,這樣有助于你把握需求的本質。
定期對需求池做一定的梳理。產品部門定期讀需求池進行整理，那些需求是下一步要做的，那些需求是是可以暫緩的，那些需求是不做的，對需求池進行梳理和分類。
不同終端的需求要分開。分為APP、PC、微官網、前臺、控臺這些。
? ? ? 這里提供一份模版：
三、產品迭代前寫一份立項報告
通過對需求池的整理以后，你決定要做那些不做那些。需要出一份立項報告和技術部門過一下，這樣技術? ? 可以安排開發周期。技術也可以從技術的角度給一些意見說那些可以做，那些可以暫時不做，這樣技術在開發之前有一個心理預期，這樣在你開原型評審會的時候阻力會小很多。這里教給大家一個小技巧：做立項報告的時候可以多寫一些需求，這樣多一些的需求可以給技術砍。
四、競品分析
? 俗話說知己知彼，百戰不殆。你做的東西別人也在做，買東西都還需要貨比三家呢。做競品分析有兩個目? ? 的，第一、揚長避短。吸引別人做的長處，發現別人做的不足的地方。第二、驗證與測試。別人上的這個功能市場反饋怎么樣，有沒有遇到啥問題，通過競品確定市場機會點。
競品分析有一定的流程?？梢詮摹皯鹇詫?范圍層-結構層-框架層-表現層”這幾個層面進行分析。
戰略層：確定競品的商業模式、產品定位、市場狀況、盈利情況等，目的是確定方向，了解市場。
范圍層：競品的目標人群，滿足了什么需求，用戶的滿意度如何，目的是參考競品的目標人群以及需求的重要度。
結構層：競品的主要功能架構、特色功能、發展模式，優缺點總結，目的是尋求差一點。
框架層：競品主要任務流程的順暢，交互的細節，邏輯的準確，頁面的框架，目的是優化流程，提高用戶體驗。
表現層：競品是視覺風格，顏色層級，文案的運用等，目的是維持用戶對這類產品的傳統認知的基礎上打造產品獨特性。
五、原型評審和PRD文檔制作
? 競品分析做完以后，開始根據競品分析的結果。開始自己的功能設計，流程的繪制，在原型上加一些功能的注釋，這樣在敏捷開發的時候可以節省PRD文檔的制作，也可以在和技術開會的時候不會遺漏自己想講的東西。
原型評審的時候技術人員的有效意見一定要虛心接受，不要覺得自己是產品就高高在上，涉及到原則問題堅? 持。別人提的有益意見也要虛心接受，只有這樣你才能避免死逼，項目才能盡快落地。至于PRD文檔的制? 作。有時間的話可以寫word文檔，沒時間的話可以直接在原型中制作文檔。但文檔必須包含的部分有：
1、產品版本的迭代歷史。清晰的告訴項目成員每次改變都改了那些東西。
2、需求功能清單。有需求功能清單 的時候技術人員在開發的時候才不會遺漏，測試工程師也會根據你的需求功能單來進行測試。
3、全局結構圖和重要的功能流程圖不能少。全局結構圖。產品全局結構圖相當于房子的骨架，相當于文章的目錄，別人看過你的全局結構圖就知道你的產品大概分成那幾個部分。其次，一些重要的功能流程圖需要 寫，這樣有助于開發人員思路的建立。
4、異常流程要考慮清楚。只有異常流程考慮清楚產品經理才不會挨批，技術開發起來才不會出現問題。
5、重要名詞要定義。對于首次出現的名詞需要定義，這有這樣別人在看到名字的時候才不會有疑問，再跑來找你問。
五、項目管理
項目進度表。文檔交給技術開發以后，就需要制定一個項目時間表，并向領導匯報。首先要全面地收集他們在聽完需求文檔評審后對于產品本身的意見與建議，然后逐項予以合理的解釋，以保證程序員哥哥們打心底里認同這個產品，認同這個產品的每一個需求。另外作為一個PM，也應該要對基本的開發流程有所了解在制定每個需求的開發周期時提出正確的建議，保證最終的項目開發時間表既不會拖慢整個項目的進度，也沒有超出程序員哥哥們每天正常的工作量，保證他們不會感到過大的開發壓力。
進度跟蹤。對于項目進度要做到心中有數，每天更新項目進度表，并幫助技術解決他們在開發過程中遇到的問題，并將自己看到的潛在問題盡量扼殺在萌芽中。當然，跟進并不是天天問工程師進度，需要給他們鼓勵打氣，并描述產品的未來前景，讓團隊中的每一個人都感受到自己的重任并愿意承擔?？赡苡行﹫F隊里面是CTO擔任項目經理，這也無可厚非，畢竟在項目成員中程序員占了大半資源，當然產品經理要盡量參與這個過程當中。不能當局外人。
六、產品上線前協助測試
大公司有明確的職位分工：工程師、測試、設計、運營都由不同的人負責，測試自然是測試工程師的事，而 在中小型創業公司，人員匱乏，很多團隊只有工程師和產品經理，工程師負責開發，開發以外的事情全都由產品經理承包，這 其中自然包括測試。但無論如何產品經理都要盡量參與測試工作，保證產品是按照你的預期做出來的。
1、首先與測試組溝通協作，確定產品測試排期。
2、跟進測試進度參與產品測試。
3、將測試出來的bug記錄下來，并拍好優先級，反饋給技術來發人員
功能測試是合格產品經理的必備素質，產品經理要協助測試工程師完成測試報告并敦促工程師團隊改進產品。
七、產品培訓和推廣
給業務方培訓、推廣產品。客服可能需要給用戶解答問題，所以每次迭代的內容都需要給客服培訓，好讓客服組織話術來應對客戶隨之而來的一些問題。同時也需要給市場、運營等部門培訓，讓他們知道產品到了那些階段，有那些改變，一是讓各個部門之間知道自己正在做的事情，二也好讓營銷市場部門做好宣傳與推廣。
收集產品使用反饋，為迭代做準備。產品上線后設計的好不好，有哪些用戶滿意的，有那些用戶不滿意的。都會有用戶進行反饋，收集并分析這些用戶需求，并記錄在你的需求池里面，為下一次迭代做準備。
八、數據分析
產品上線后產品設計的好壞很大程度上能從數據上體現出來。例如你設計個活動分享頁面，用戶可以通過好友分享的界面直接注冊，那么你就要統計這個頁面的點擊量、PV/UV、頁面訪問市場、訪問深度、用戶的跳出率、用戶的轉化率等來評估你設計的好壞，以及活動的效果。再比如你產品進行改版，你需要評估改版的好壞。你就需要關注30日留存率提高了還是降低了，別關注7日留存率。因為你的產品剛更新你的粉絲用戶可能會很活躍，導致7日留存率變高，這個時候你說你的改版比較成功可能沒有說服力，也許30日以后你的用戶活躍度變低了，30日留存率也變低了。
