從產品小白到產品經理，這是你的必備知識點

更新時間:2018-05-04 來源:黑馬程序員瀏覽量:

“你覺得作為產品經理最重要的三個能力是什么?”作為一名2歲的PM，我的答案是：學習能力、分析能力、執(zhí)行能力。你問一名產品總監(jiān)或者CEO，他可能會說，“產品感覺、管理能力，商業(yè)思維，等等?！? 不同的階段對產品經理的能力要求必然不同，作為一名產品小白，首先你要有很強的學習能力來符合這個崗位對你的要求。

產品經理的整個工作流：市場分析、競品分析、用戶研究、需求分析、產品策劃、產品推進、產品管理，每一步都有一套有效的方法論，學習并掌握這套方法論，形成自己工作中的知識體系，工作起來才能少走彎路、得心應手。

1.市場分析

1.1SWOT分析

內部環(huán)境：優(yōu)勢(strength)，劣勢(weakness);

外部環(huán)境：機會(opportunity)，威脅(threat)。

優(yōu)勢：公司內部充足的資源，而競爭對手不足;

劣勢：公司內部缺乏的資源，而競爭對手充足;

機會：用戶存在的需求還沒有被滿足，公司有資源滿足用戶的需求并且能盈利;

威脅：影響公司產品盈利的因素。

1.2商業(yè)模式

對產品的內外部環(huán)境進行分析之后，下一步就需要考慮產品的商業(yè)模式，即盈利模式?；ヂ摼W產品的商業(yè)模式大致可分為以下幾種：

1.3商業(yè)模式畫布

商業(yè)模式畫布是一張可以直觀展示產品商業(yè)模式的圖表

作為一名產品經理，尤其是大公司的、產品已進入成熟期的產品經理，很少有機會參與到公司對市場的決策中去，但是對產品的市場分析可以幫助我們更透徹的理解產品的定位和市場走向。

2.競品分析

2.1如何選擇競品

A.產品經理做競品分析的能力可以分為以下三個等級：

1)初級：能找到同類產品的競品，照貓畫虎的抄襲競品的功能;

2)中級：能看到競品做的動機和原因，并根據項目和公司所處的階段來選擇不同的競品或競品的不同階段;

3)高級：沒有競品的時候，能夠從橫向和縱向對比來發(fā)現競品。

B.選擇分析的競品可以分為三個類型：

1)核心競品：同目標用戶、同使用場景、同用戶需求的第一梯隊產品;

2)重要競品：目標用戶、使用場景、用戶需求有一個不同，在其細分領域的第一梯隊產品;

3)潛在競品：目標用戶、使用場景、用戶需求不盡相同，但可借鑒性強的第一梯隊產品。

2.2競品分析的維度

競品分析一般先分析產品的業(yè)務層、其次是功能層，最后是表現層。具體的分類如下：

市場：政策、容量、階段、商業(yè)模式、占有率等;

資源：團隊、投資方、合作方、供應鏈、渠道、現金流等;

數據：月活、UV、營業(yè)收入等;

運營：活動時間、活動成本、內容建設、轉化率等;

功能：核心功能、非核心功能等;

用戶：畫像、行為等;

UE、UI：流程、主色調等。

2.3如何獲取信息

1)公開信息：靠關鍵詞在網上能搜索到的信息

例：百度/谷歌、app annie、公司財報、36kr、艾瑞/易觀、微博/微信;

2)半公開信息：需要一定的統(tǒng)計、檢測和合理的估算才能得到的信息

例：親自體驗、Excel、爬蟲;

3)內幕信息：需要通過謹慎推理以及特殊方法才能得到的信息

例：沙盤推演、人際情報、黑客。

3.用戶研究

3.1定性研究

定性研究的主觀性偏強、科學性較差，一般樣本量較小，用于直接收集用戶對產品的使用習慣。

1)用戶訪談

訪問者提出一系列的問題，從受訪者的回答中搜集用戶需求，從肢體語言中洞察他們對產品的使用體驗。

2)情景訪談

訪問者在用戶的實際工作或生活環(huán)境中與受訪者進行交流，以確定受訪者的使用習慣、需求和痛點。

3.2定量研究

定性研究是探索性研究，用于定性的確定用戶需求，最后還需用定量研究的方法來完善和測試。

1)問卷調查

問卷調查不必解釋了，需要注意的是問題的設計多而雜不如少而精，調查的用戶樣本量要盡可能的大。

2)數據分析

當你與領導或同事對于某個決策有爭議時，用數據說話是最簡單直接的解決辦法。PC端用百度統(tǒng)計、移動端一般用友盟，可以很方便的查看網站的PU、UV、平均訪問時間、數據漏斗等關鍵性指標。

3)A/B測試

A/B測試用于比較兩個相似的版本，除了一個影響用戶行為的變量之外，其他的條件要相同。當樣本量很大時，A/B測試的效果會非常顯著。

比如向用戶推薦福利的時候，是用“殘忍拒絕”還是用“有錢任性”的文案作為關閉按鈕時，對比一下就能看到點擊率的區(qū)別。

4.需求分析

4.1需求來源

A.被動告知需求

1)主要業(yè)務部門：包括市場、運營、管理層等主要業(yè)務部門，可能是一個新的業(yè)務、活動或者機制的更改;

2)客服：當用戶頻繁咨詢或投訴一個問題時，客服會將問題提交給產品經理評估;

3)用戶意見反饋：用戶通過挑錯建議等方式反饋的問題，需主動收集，評估并及時處理。

B.主動收集或挖掘需求

1)競品分析

競品分析的方法在前面已經說過了，通過競品分析我們可以挖掘部分本產品未解決的用戶需求。

2)用戶研究

作為產品經理，前期的競品分析、用戶研究都是在挖掘用戶需求。另外，在挖掘用戶需求的時候，我經常會用畫腦圖窮舉法用來做最后的需求梳理?！坝龅降膯栴}”即用戶需求，“解決辦法”即相應的功能。

4.2需求類型

對于已上線的產品，在做產品迭代的時候，可以對需求池的產品進行分類，以幫助我們來確定需求的優(yōu)先級。主要的需求類型有：新增功能、功能改進、體驗優(yōu)化、BUG修復等。

4.3需求優(yōu)先級分析

我常常會用兩個四象限分析法來綜合評估需求的優(yōu)先級，這里建議一個團隊的產品經理以來做這一項評估。很多時候我們會遇到很多需求都在一個象限里，所以這里推薦兩個四象限分析法，可以綜合評估。

1)“用戶量-使用頻率”四象限

2)“見效快慢-開發(fā)難度”四象限

經過分析和評審之后基本可以決定全部需求的優(yōu)先級了，優(yōu)先級最高的需求在第一期的MVP(最小可行性產品)中實現，優(yōu)先級較低的需求放在下一版或下幾版的產品規(guī)劃中分批實現。【推薦了解：黑馬程序員產品經理課程】

5.產品策劃

5.1業(yè)務流程圖

A.什么是業(yè)務流程圖?

描述具體某個業(yè)務實際處理步驟和過程的流程圖。

B.為什么要畫業(yè)務流程圖

1)了解業(yè)務：幫助整個團隊了解產品的業(yè)務是如何運轉的，并且對業(yè)務流程中不合理的地方進行優(yōu)化;

2)梳理需求：幫助產品經理梳理業(yè)務需求在產品線的各個階段中功能模塊之間的關系;

3)傳達需求：研發(fā)工程師構建技術架構和明確技術分工會主要參考業(yè)務流程圖。

C.怎樣畫業(yè)務流程圖?

1)確定范圍

確定業(yè)務流程的起點和終點，是截取某一段業(yè)務進行詳細描述，還是整體業(yè)務模塊進行描述。

2)確定要素

誰，在什么情況下，做了什么事，這個事需要什么前置條件，又輸出了什么，是在哪里完成的?搞明白這幾個問題，我們的要素就確定了。

2)梳理呈現

怎么畫流程圖這里不贅述了，用什么工具、怎樣更精美都是不重點，重點是關鍵要素的搜集和確認。泳道圖是常用的一種表現形式，一般橫向代表用戶角色，縱向代表各階段。

4)評審確認

a.讓涉眾參與評審：業(yè)務流程圖中涉及到的用戶角色或部門要盡可能讓他們參與到評審中來，切忌自己YY;

b.層次分解，重點突出：流程很復雜的，可以在一個主圖里展示主要流程，在其他圖里分別將主流程中待展開的流程進行展開。

5.2頁面流程圖

A.什么是頁面流程圖?

描述產品的全部頁面相互間關聯的流程圖。

B.為什么要畫頁面流程圖?

1)了解全局：對于整個團隊，頁面流程可以從表現層了解產品的全局;

2)梳理業(yè)務：反復研究頁面流程圖并優(yōu)化，可以使整個產品變得更加簡約;

3) 傳達需求：設計師要設計多少個頁面，前端工程師要寫多少個頁面一目了然。

C.怎樣畫頁面流程圖?

1)找出所有的頁面：找出所有物理層面的、真實存在的頁面，切忌不要像業(yè)務流程圖一樣具體到某個功能和模塊;

2)用有向線條關聯：把所有相關跳轉頁面用有向線條關聯，頁面流程圖較復雜的可以反復研究如何讓其更簡約的呈現;

3)增加條件判斷：從上一個頁面跳轉至下一個頁面的條件是什么，在頁面流程圖里體現出來，對于設計師來說非必須，但是技術來說可以了解業(yè)務。

5.3功能結構圖

A.什么是功能結構圖?

描述功能之間從屬關系的圖表。

B.為什么要畫功能結構圖?

1)梳理需求：幫助產品經理思考并清晰產品的功能模塊及其功能組成，避免在產品需求轉化為功能需求時，功能點出現缺失;

2)傳達需求：對于不確定的產品樣式問題，可以一種較為簡潔明了的方式來表達;

3)提高效率：發(fā)現功能結構不合理的地方可以快速做出調整，避免在產品設計的細節(jié)上浪費時間。

C.怎樣畫功能結構圖?

1)提煉主要功能模塊：我們可以通過業(yè)務流程中涉及到的功能需求去提煉出主要功能模塊;

2)細化功能粒度：根據自身業(yè)務，將主要功能模塊拆分到更細的粒度。

5.4信息結構圖

A.什么是信息結構圖?

從產品的實際頁面中將數據抽象出來，組成分類的圖表。

B.為什么要畫信息結構圖?

1)梳理信息：幫助產品經理梳理產品的信息組成，避免信息內容在展示過程中出現遺漏和重復;

2)傳達需求：作為技術建立數據庫的參考依據。一條信息的存儲有很多附加屬性，具體的是存成字段還是數據表，還是中間表或者關聯表，這些都需要在完成PRD之后與數據庫技術人員進行討論。

C.怎么畫信息結構圖?

1)將產品的全部信息進行羅列，建議使用腦圖;

2)將產品的信息進行梳理使其結構化。

5.5原型圖

在產品策劃階段，產品經理通過業(yè)務流程圖、頁面流程圖、功能結構圖和信息結構圖確定了產品都有哪些頁面、頁面里有哪些功能和信息、哪些操作是如何跳轉的之后，就需要通過原型圖將我們的產品直觀的表達出來。

對于設計師，原型圖是最重要的參考物，他們關心的是產品各元素之間的排版和布局;對于研發(fā)，原型圖是他們了解功能，評估功能復雜程度，邊界條件是什么，異常情況怎么處理的最直接的參照物;對于測試，他們需要通過原型圖輔助寫測試用例，以及原型圖是否窮盡各個場景;對于領導，他們的事情比較多，原型圖的易讀性也成了他們最關心的產出物。

畫原型的工具一般使用Axure，網上的教程有很多，不會的同學可以自學。這里想說一下什么樣的原型圖才算得上專業(yè)。

1)設計符合用戶的認知模型

相同屬性的功能進行分組，相近屬性的功能放在一起。例如：我的資料、我的訂單、我的收藏、我的資產會歸納放到“我的”里邊;“加入購物車”和“立即購買”經常會放在一起。

2)交互邏輯無缺失

例如：商品列表頁瀏覽前和瀏覽后的文案的顏色有無區(qū)分?商品列表頁過長時導航欄是否需要懸浮置頂?

3)異常場景不遺漏

例如：頁面加載失敗時提示用戶什么?用戶從WiFi切斷到數據流量時提示用戶什么?

4)關鍵字段有規(guī)則定義

例如：發(fā)布時間的字段是顯示年/月/日還是月/日?顯示月/日的話跨年了怎么辦?發(fā)布時間在一天以內的話是顯示多少個小時前還是顯示月/日?

5)極限情況有定義

例如：用戶名最長為多少字?頁面沒有數據時展示什么?頁面數據過多是怎么展示?

6)全局組件有說明

全局組件指的是產品通用的組件，例如：斷網、操作成功、操作失敗、正在加載、空數據界面、404等。

6.產品推進

產品策劃的方案，主要是原型圖，經過部門內評審、技術可行性評審、公司高層評審(根據項目的實際情況而定)之后，就進入到了產品推進階段。這個階段你需要經歷的過程有編寫產品需求文檔(PRD)，需求對接、設計跟進、前端跟進、研發(fā)跟進、測試跟進和上線跟進。本階段涉及的專業(yè)性知識不多，但是雷區(qū)卻不少，我結合自己的工作經驗來分享一下哪些雷區(qū)是你需要避開的?

1)PRD編寫不細致

技術在開發(fā)時會按照你的PRD來執(zhí)行，如果你對需求的描述不夠細致甚至是邏輯缺失，會導致技術在開發(fā)時加入自己的理解來實現，最后達不到產品預期。其次，因為需求描述不完整導致在開發(fā)過程中新增需求，是技術最痛恨的事情。為了不增加研發(fā)工作量，PRD編寫越細致越嚴謹越好。

2)需求對接不透徹

設計師、前端、技術和測試會根據你的原型圖和PRD來開展相關工作，有時候你以為需求已經通過原型圖和PRD表達的很清楚了，但是在需求的理解上一定存在信息不對稱的情況。集體需求對接會是必不可少的，將需求的對接做到盡可能的透徹，對接會結束之后一定要給相關人員發(fā)郵件;在產品推進過程中，要及時與相關人員溝通和跟進，將需求理解不透徹導致返工的風險降到最小。

3)需求中途變更

前期的需求分析、方案評審等環(huán)節(jié)，產品經理是必不能偷工減料的，一旦對某一環(huán)節(jié)的忽略抱有僥幸心理，最后的后果就是研發(fā)過程中需求變更。如果需求中途變更，一方面會增加相關人員的工作量，另一方面會損害自己的口碑。如果中途因為一些事先沒有預料到的因素，比如領導臨時變更需求，作為產品經理要做好需求管理，實在需要變更的要盡量說服相關人員，推動大家去完成。

4)技術砍需求

一個需求有時候從技術的角度來考慮，為了減小自己的工作量或者根據他們自己對業(yè)務的理解，會出現砍需求的情況。產品經理需要做的首先是傾聽，合理的話可以討論，不合理的話要拿出我們的用戶研究、需求分析結果以及需求對接郵件據理力爭。

5)工作進度模糊

在需求對接會上，項目規(guī)劃和確認是必不可少的一環(huán)，相關人員需要根據工作量評估自己工作的時間節(jié)點，大家根據約定的時間來完成工作。如果缺失這一環(huán)節(jié)就會導致工作進度模糊，上線日期延期。其次，根據項目的需要可以考慮每日站會和階段性的產出物評估會。

7.產品管理

7.1產品發(fā)布

前面所有的工作都做完之后，最后就需要讓產品發(fā)布上線。絕大多數情況我們做的都是產品迭代更新的發(fā)布，面對版本更新，如果用戶的使用習慣發(fā)生了改變，用戶一般都是不愿接受的態(tài)度。面對這種情況，需要我們用非技術和技術的手段去規(guī)避。

A.非技術手段

1)以網站公告、app推送、短信或郵件的方式預先通知用戶;

2)嚴格控制產品的測試和驗收質量，確保更新內容的可靠性，避免上線之后又撤回的尷尬。

B.技術手段

1)A/B測試：頁面或流程設計A/B兩個版本，隨機讓比例相同的兩部分用戶使用，通過數據分析選擇效果好的版本作為正式版本發(fā)布給所有用戶。