上次回家遇到同學，說起以前他校招給我投產品經理的簡歷被我刷掉的事情。我於是便問他：你究竟為什麼想要做產品？我那個同學回答我：”我學長告訴我，產品經理入門簡單，啥都不會就可以幹，而且工資很高啊！”

我忍不住罵了句：”我日啊！”

今天又在知乎上看到一個問題：“產品經理究竟是幹嘛的？“，看到一個個自說自話的回答實在是受不了，就想寫一下，我所理解的產品經理的主要工作究竟是什麼。

簡單來說，產品經理主要的工作就是：規劃、設計產品，對產品研發過程的控制，最終把產品賣出去的一個過程。而產品經理，基於服務的物件不同，主要分為兩種：to b (針對企業)和to c(針對使用者)，雖然兩者的側重點有些不同，但是他們基本的工作方式還是很類似的。

初入門的產品總會有這樣誤區，就是總覺得產品經理的主要工作是繪製介面原型。曾經面試過一個應聘產品助理的妹子，我在考驗她邏輯思維能力的時候，她對我的問題表示出了不屑，不停的跟我強調自己會使用各種繪圖和設計軟體。其實，學習能力，思維的邏輯性，比單純的使用一個軟體的技能要更重要。而且，產品的原型的設計只是產品經理眾多工作輸出偏向於後期的一種。

在此之前，是需要進行非常多準備工作的，最後到了原型階段，只要表達出想要表達的意思，設計和研發能看懂就可。但是如果前期準備不到位，產品的設計有問題，那麼，原型做的再好看，屁用都沒有。因為，根本沒有人會用它。

具體來說，按照流程先後來分，產品經理的工作主要包括如下幾個方面：

• 產品定義
• 需求調研
• 業務建模
• 產品驗收
• 線上運營

注意：這些工作過程並不是每個產品都必須有的，僅僅是做完一個產品的常規過程，有些過程很多時候是被略過的，僅此而已。

以下我來分條說明一下。

產品定義

簡單來說，產品定義的過程，就是明確這個產品是做什麼的一個過程。這個過程需要明確如下幾個要素：

1、產品業務的邊界：即這個產品要解決什麼問題？這個產品不解決什麼問題？

一個個網際網路產品可以看做是一系列事情的解決方案的集合，而不管解決什麼問題，都得付出資源。無論是任何公司，哪怕是BAT，資源永遠都是不夠的，所以解決方案還需要聚焦到一兩個點去展開，才能儘快建立起自己的領先優勢。比如早期的陌陌，就專注於陌生人社交這個問題，最初的小米專注於解決窮人如何擁有一款智慧機的問題，最初的百度也就解決如何有效的搜尋到自己想要資訊的問題。你永遠無法用一個產品解決所有問題。就像你永遠無法用一個答案答對所有題目一樣。這個時候，產品業務的邊界就非常重要，定位一定要非常清晰，絕對不能模糊。

2、使用價值：這個產品使用的價值在哪？別人為什麼要用你的產品？

我覺得美國著名的電影《教父》裡面的維多·克里昂是最成功的產品經理之一，因為他曾經說過這樣一句話：”I’m gonna make him an offer he can’t refuse ” (我將給他一個無法他無法拒絕的理由)，然後他做到了。我們可能沒有教父那麼牛，但是我們可以做的是：我們究竟能不能，敢不敢說出這句話？

這個時候，我們就要思考，使用者無法拒絕你的理由究竟是什麼？這個問題說的更直白點就是：別人為什麼要用你的產品？你的產品和別人的產品有什麼區別？你的產品能不能更好的比別人解決使用者的問題？

3、商業模式：這個產品究竟應該怎麼掙錢？

對於一個公司來說，賺錢就是它的商業倫理，產品是為公司服務的，如果賺不到錢，就是違背其商業倫理。而一個產品如果既賺不到錢又沒有使用者，那麼這個產品就是失敗的，它就是一坨屎。即使再用情懷，用理想來包裝自己，包裝的再華麗，也只是一坨華麗的屎。

商業模式其實可以大體可以分為兩種：賺錢的和不賺錢的（或者可以說是以後賺錢的）之所以說商業模式分為賺錢和不賺錢兩種，是因為網際網路行業的特殊情況來定的（即商業模式不清晰的情況下，只要有大量使用者，遲早會有辦法掙到錢）所以往往也能夠吸引大量使用者的產品也能得到資本市場的青睞，比如說美團。

科幻小說《基地》裡面講的是，一代宗師哈里·謝頓對未來三萬年的預測和推演，並通過自己的推演來重新建立人類文明的故事。雖然做不到像哈里·謝頓那樣，商業模式能否盈利，的確是需要進行市場調研和沙盤推演的。因為往往市場的情況就決定了，一開始，這個產品未來的發展和走向。我們通過市場主要影響因素的估算，算出分幾個階段做這個產品，制定出產品的RoadMap(關鍵節點)，以及多長時間能夠盈利。最後產出的就是要給VC（風險投資者）看的BP（商業計劃書）。

但市場情況風雲突變，很少可以按照計劃來執行，寫BP主要是還是為了融資和沙盤推演看這件事情究竟是否可行。

商業模式的產品定義這一塊得考慮相當多的內容，不光得深入到行業，還得深入瞭解經濟趨勢，政策風險等，才能較為準確的對產品有所瞭解。而商業模式在未得到驗證的情況下，是不能進行快速批量投入的。得先小批量驗證，驗證無誤，解決了批量推廣的瓶頸以後，然後再花大力氣去推。

所以我們總是說創新是一件很難的事情，更好的一種方式是直接抄襲然後修改。COC (copy to china)就是這樣，在國外得到驗證過的商業模式，直接抄到國內來。這些成功的例子有很多啦，比如大家痛斥的騰訊，又比如我前老闆王興，我稱之為火影忍者卡卡西（複製忍術），雖然王興幾乎所有的創業專案都是照搬國外現成商業模式的，但他都快成大佬了，充分說明這種流氓式抄襲過來修改的方式還是挺管用的（雖然很沒節操）。

需求調研

思維的過程是這樣：思考問題得由大到小，由淺入深。解決了產品定義問題以後，我們就需要解決另外一個問題，我怎麼驗證自己的想法是正確的？我該怎麼樣才能知道真正的使用者是怎麼想的？這個過程又分為如下的幾個方法：

問卷調查

總的來說，問卷調查會有很多問題，比如如何去獲得有效問卷？如何去找到你的目標使用者？也是一個非常有趣的討論話題。
關於問卷調查，我曾經簡單的寫過一篇相關的文章，大家可以去看看，這裡就不多闡述了。問卷調查的好處在於，可以獲得大量使用者反饋的資訊，獲取資訊的效率更高，雖然準確度可能不太好控制。

面談

問卷調查以後，面談可以作為問卷調查的一種補充。面談的好處是你可以更好的瞭解到使用者在想什麼，主要就是去了解使用者的痛點，然後對於這個痛點他是如何解決的？但為了避免對使用者的面談結果進行影響，其實還是有一些技巧可言的，和問卷調查有點類似，簡單的總結一下：

• 不要使用肯定或者否定式提問
• 儘量使用使用者能夠接收的方式來詢問
• 儘量讓使用者陳述事實，而不是觀點

沉浸在使用者環境內

親身經歷一個事情帶來的情緒記憶要比看著或聽說別人這個事件所感受到的強烈得多，形成感受的反射也遠遠要更持久。而且，比較傳統的使用者，很多時候，並不會對你說實話。去到使用者的環境裡，不但可以切身體會到使用者的感受，而且還能從側面去觀察這個行業，總之，好處很多。所以我做之前影視專案的時候，就去片場呆了將近一個月的時間，吃劇組飯，也客串了幾把演員，我也因此弄明白了影視行業的潛規則和一些行業訊息，發現很多使用者的痛點是沒法說，或者不願意說出來的。

競品的分析

競品分析可以更好的讓你瞭解到這個行業，這個產品的市場，別人在做什麼。具體如何去做，網上資料一大堆，都是可以查到的，做這種東西最重要的不是格式，而是從產品設計的角度出發，去探索每個產品設計背後的原因，請記住一句話：『別的產品經理不是傻瓜』
產品經理郝原在知乎上分享過自己在做鳳凰新聞客戶端的經驗，他做鳳凰客戶端的時候，參考了reddit，豌豆莢，豆瓣小組，網易，貼吧，微社群，抽屜等各個平臺的UGC產品的微社群功能，很辛苦的做了一個微社群，怎麼推都沒有推起來，最終失敗了。原因是因為他沒有搞懂別人做微社群的原因的情況下簡單一味的模仿，導致了產品的失敗，最後他總結到：

看別人產品，不應該只看對方體驗，而是應該看他的根，他的道理。他的公式是什麼，這個公式因何成立？如果做同樣的事情，對你的專案是否成立？

使用者故事的編撰

以上的步驟做完了，就是去編寫使用者故事和使用場景了。使用者故事，指的是從使用者的角度去描述他完成業務過程的操作，它包含三個要素：

• 角色（誰）
• 活動（做什麼）
• 商業價值（目標是？）

拿QQ裡面的一個常用的故事來舉例子，比如給同事傳檔案就可以寫成這樣：我（誰），想（找同事傳word檔案）以便於（協同寫作）。當然，使用者故事是不止一個的，一個產品會有很多的使用者故事，當用戶故事收集完成以後，我們就可以開始做產品的下一步的工作：業務建模

業務建模

以上，基本的準備工作都已經做完，這就進入到產品設計的環節了。這個過程，是很多人看得到的產品的顯性工作，大多數人都會把時間放到這個上面。雖然說這個過程非常重要，但是，如果前面的工作沒有做好，這一步，就是在生產垃圾。這一過程主要分五個階段：

業務流程圖的繪製

一個產品的設計，有顯性的地方也有隱性的地方。比如說在京東上，你能看到的，是商品的買賣這是顯性的地方。你看不到的，比如說網站客服的支撐體系，物流的支撐體系，公司的財務體系等……都是隱性的部分，業務就好比一塊冰山，線上業務是冰山上展露的頭。

這個時候，我們就需要根據使用者故事來繪製業務流程圖了。基本上就是用泳道圖的方式把業務串起來，形成一個完整業務的過程。因為線上產品的製作，本質上，還是把線下的過程給搬到線上進行放大和優化的過程。

但我們在設計業務過程的時候，就不能一葉障目，只繪製顯性的業務，還是得把整個業務過程給拉取出來，先抽取主要的過程，再加上分支的過程。還拿電商舉例，完整的業務過程應該是：商品的產生、商品的庫存，商品的線上營銷、商品的配送、商品的售後。區分一下，哪些業務是在線上完成，哪些業務是線上下完成的。區分是在線上還是線下完成，一方面要考慮本來業務的屬性，比如配送，這個業務的屬性決定了它主要業務過程線上下完成。另外一方面還是取決於開發的成本和優先順序。比如如果系統內涉及了交易就肯定有結算的功能，但是如果交易又不是主要使用者的使用場景而又趕著上線的時候，就可以讓這個環節放到線下去結算（當然不是一個好選擇，只是舉個例子）。因為做產品設計，本質上還是一個投入產出比的遊戲。

用例圖的繪製

根據上面所說的線上業務流程圖，我們會做出一個比使用者故事更簡單的圖。這個圖非常簡單，你只需要繪製一個個角色，把這些個角色要實現的功能給列舉出來即可。這樣可以讓角色和功能的展現的更清晰，避免功能實現文件出現遺漏或者重複的情況

功能節點的繪製

對用例內的角色和功能合併以後，我們就能得出這個系統需要完成哪些功能，以及哪些功能是主要功能的判斷，這個時候我們就可以拉出一個包含著有功能優先順序內容的表格了。關於優先順序的判定主要考慮如下幾點

• 基本的功能必須要覆蓋
• 主要的場景必須要覆蓋
• 次要的場景次要覆蓋
• 使用者價值越高就越需要關注

原型的繪製

繪製原型的時候，只需要畫草圖，說明清楚互動，約束就好，不需要在細節上做的太過（當然我指的是初始階段），需要知道，使用者體驗包括三個層面：能用—》用的舒服—》用的舒服且介面漂亮，做產品得有先後順序之分，細節是最後打磨的時候用的。某些一開始就打磨細節，而產品功能有問題的手機廠商，估計是因為他們還不知道怎麼打磨產品吧。

一般繪製完了以後，會再按照上面的過程自己過一遍，思考下自己遺漏和重複的做了哪些不必要的設計，是不是有邏輯不正確的地方，跳轉是不是有問題。

評審和研發排期

原型檢查和繪製完了以後，就是和研發，設計，領導一起來評審，確定功能的可行性，交付日期等事項。產品需要保障研發能夠按計劃完成任務，所以就需要留下證據，定時溝通，確認研發的進度。具體的內容可以參考我以前寫的《交辦的技術》讀後感

產品測試驗收

研發開發功能的同時，產品就需要開始準備產品的測試用例了。測試用例的主要來源是使用者的使用場景，也就是說產品測試的最終目的是確保使用者的使用場景都能按照預期的方式來實現。

產品測試的用例需要有如下三個要素

• 執行過程：執行過程必須要是無腦的指令碼，就是看到這個過程就知道不需要動腦，直接按照執行過程的說明來進行操作，這樣的好處是執行起來非常快，不需要邊做邊想，在做的時候動腦。
• 預期結果：任何一個測試用例必須要有一個預期，即如果系統正常的情況下，系統反饋出來的結果究竟應該是什麼樣的。
• 實際結果：即在測試過後，系統實際展示給你的現狀。如果實際結果滿足預期結果，那麼，這個功能就是可以交付的。如果有功能的問題，那麼就是需要提交工單給研發，研發重新修改最後再上線。一般一輪測試完成以後，需要跑一遍迴歸測試。迴歸測試，就是把驗證已經通過的測試用例再走一遍，看看是否能夠再跑通，確認修改問題的同時，有沒有引入新的問題。

當然，我在這裡寫的都是最簡單的測試過程，實際的測試過程比我所寫的要複雜。實際可能會測試的還會有：資料的唯一性，資料介面的穩定性等等。測試方法也不一而足，就不一一介紹了。

線上運營

在測試完成以後，就要開始準備上線了，這個時候我們就需要考慮一個問題：我們最初始的使用者從哪兒來？尤其是創業公司，獲取初始使用者完成冷啟動的過程是如此的重要，以至於一旦錯過了時間節點，往往公司就黃了。

一般來說拉取使用者最有效的方式簡單粗暴，就是拼爹和砸錢，大家去北京的各個街道小區轉一轉就知道，為什麼會有以專門幫人做地推賺錢的人。可是並不是每個初創團隊，都有這麼多錢可以玩的，而且，即使有很多錢，也不是可以亂花的，那怎麼辦？

到使用者群體去發帖，去做SEO，去做市場活動，靠別人推薦，這些都是常規的運營方法，然而，做運營不是每天重複的發帖，做活動就行的，還需要制定運營的策略，來規範化這個過程。所以我們運營的策略就需要考慮如下幾個問題。

• 常規的運營策略有哪些是可以用的？
• 這些策略需要的資源有多少（資源包括：人力，金錢）?
• 各個策略分別能夠使我獲得多少收益？他們的轉化率是什麼樣的？如何提高策略的轉化率。
• 各個策略適用於哪些時間？適用於哪個階段？

由此，制定出來的策略才有可能是有效的策略。當然，如果沒有太多運營的經驗，那麼就只能每個都嘗試一下，在嘗試的過程中進行計算和總結，逐步迭代出適合於自己產品的運營策略。產品上線以後，運營的策略也會不停的變化，而且通過不斷的運營和資料的積累，產品不斷的迭代下去，直到這個產品完成了它固有的生命週期，最後產品下架，產品經理的使命就此結束。

相信諸位看完了以上我寫的內容，應該會對產品經理究竟是幹嘛的有了一些粗淺的瞭解和認識。在此，我並不是想借拔高產品經理的角色來擡高自己，只是想說明一個事情，就是產品思維雖然是人人都可以有的，但是正經的產品經理的工作，還是需要非常專業的知識和寬廣的知識面作為支撐才能夠勝任的。

從長遠來看，任何崗位，都不可能是非常容易就能夠拿到高薪的，因為如果產品經理容易拿到高薪，那麼所有人都會一擁而上，這個職位瞬間就不值錢了。雖然產品經理這個職位的平均薪酬在逐漸降低，但是我所認識的，稱得上是產品經理的同學的薪資卻一直都在穩步上升。我因此得出來的一個結論就是，不是能幹這些活的人的薪資水平在下降，而是被稱之為產品經理的人正在變多。

產品經理的名稱正在逐漸貶值，而從趨勢來看，從業者的平均技能卻沒有得到太大的提升。從長期的趨勢來看，好的產品，還是很難得。大多數人，都會如我一般，只能從坑人的產品經理做起，不過那又如何呢？