產品經理是作什麼的？

 簡單來講，產品經理主要的工做就是：規劃、設計產品，對產品研發過程的控制，最終把產品賣出去的一個過程。而產品經理，基於服務的對象不一樣，主要分爲兩種：to b (針對企業)和to c(針對用戶)，雖然二者的側重點有些不一樣，可是他們基本的工做方式仍是很相似的。

初入門的產品總會有這樣誤區，就是總以爲產品經理的主要工做是繪製界面原型。其實，學習能力，思惟的邏輯性，比單純的使用一個軟件的技能要更重要。並且，產品的原型的設計只是產品經理衆多工做輸出偏向於後期的一種。

在此以前，是須要進行很是多準備工做的，最後到了原型階段，只要表達出想要表達的意思，設計和研發能看懂就可。可是若是前期準備不到位，產品的設計有問題，那麼，原型作的再好看，也沒有用。由於，根本沒有人會用它。

具體來講，按照流程前後來分，產品經理的工做主要包括以下幾個方面：

• 產品定義

• 需求調研

• 業務建模

• 產品驗收

• 線上運營

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

如下我來分條說明一下。

產品定義

  簡單來講，產品定義的過程，就是明確這個產品是作什麼的一個過程。這個過程須要明確以下幾個要素：

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

一個個互聯網產品能夠看作是一系列事情的解決方案的集合，而無論解決什麼問題，都得付出資源。不管是任何公司，哪怕是BAT，資源永遠都是不夠的，因此解決方案還須要聚焦到一兩個點去展開，才能儘快創建起本身的領先優點。好比早期的陌陌，就專一於陌生人社交這個問題，最初的小米專一於解決窮人如何擁有一款智能機的問題，最初的百度也就解決如何有效的搜索到本身想要信息的問題。你永遠沒法用一個產品解決全部問題。就像你永遠沒法用一個答案答對全部題目同樣。這個時候，產品業務的邊界就很是重要，定位必定要很是清晰，絕對不能模糊。

二、使用價值：這個產品使用的價值在哪？別人爲何要用你的產品？

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

這個時候，咱們就要思考，用戶沒法拒絕你的理由到底是什麼？這個問題說的更直白點就是：別人爲何要用你的產品？你的產品和別人的產品有什麼區別？你的產品能不能更好的比別人解決用戶的問題？

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

對於一個公司來講，賺錢就是它的商業倫理，產品是爲公司服務的，若是賺不到錢，就是違背其商業倫理。而一個產品若是既賺不到錢又沒有用戶，那麼這個產品就是失敗的。

商業模式其實能夠大致能夠分爲兩種：賺錢的和不賺錢的（或者能夠說是之後賺錢的）之因此說商業模式分爲賺錢和不賺錢兩種，是由於互聯網行業的特殊狀況來定的（即商業模式不清晰的狀況下，只要有大量用戶，早晚會有辦法掙到錢）因此每每也可以吸引大量用戶的產品也能獲得資本市場的青睞，好比說美團。

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

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

需求調研

思惟的過程是這樣：思考問題得由大到小，由淺入深。解決了產品定義問題之後，咱們就須要解決另一個問題，我怎麼驗證本身的想法是正確的？我該怎麼樣才能知道真正的用戶是怎麼想的？這個過程又分爲以下的幾個方法：

問卷調查

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

面談

問卷調查之後，面談能夠做爲問卷調查的一種補充。面談的好處是你能夠更好的瞭解到用戶在想什麼，主要就是去了解用戶的痛點，而後對於這個痛點他是如何解決的？但爲了不對用戶的面談結果進行影響，其實仍是有一些技巧可言的，和問卷調查有點相似，簡單的總結一下：

• 不要使用確定或者否認式提問

• 儘可能使用用戶可以接收的方式來詢問

• 儘可能讓用戶陳述事實，而不是觀點

沉浸在用戶環境內

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

競品的分析

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

看別人產品，不該該只看對方體驗，而是應該看他的根，他的道理。他的公式是什麼，這個公式因何成立？若是作一樣的事情，對你的項目是否成立？

用戶故事的編撰

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

• 角色（誰）

• 活動（作什麼）

• 商業價值（目標是？）

拿QQ裏面的一個經常使用的故事來舉例子，好比給同事傳文件就能夠寫成這樣：我（誰），想（找同事傳word文件）以便於（協同寫做）。固然，用戶故事是不止一個的，一個產品會有不少的用戶故事，當用戶故事收集完成之後，咱們就能夠開始作產品的下一步的工做：業務建模

業務建模

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

業務流程圖的繪製

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

這個時候，咱們就須要根據用戶故事來繪製業務流程圖了。基本上就是用泳道圖的方式把業務串起來，造成一個完整業務的過程。由於線上產品的製做，本質上，仍是把線下的過程給搬到線上進行放大和優化的過程。

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

用例圖的繪製

根據上面所說的線上業務流程圖，咱們會作出一個比用戶故事更簡單的圖。這個圖很是簡單，你只須要繪製一個個角色，把這些個角色要實現的功能給列舉出來便可。這樣可讓角色和功能的展示的更清晰，避免功能實現文檔出現遺漏或者重複的狀況

功能節點的繪製

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

• 基本的功能必需要覆蓋

• 主要的場景必需要覆蓋

• 次要的場景次要覆蓋

• 用戶價值越高就越須要關注

原型的繪製

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

通常繪製完了之後，會再按照上面的過程本身過一遍，思考下本身遺漏和重複的作了哪些沒必要要的設計，是否是有邏輯不正確的地方，跳轉是否是有問題。

評審和研發排期

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

產品測試驗收

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

產品測試的用例須要有以下三個要素

• 執行過程：執行過程必需要是無腦的腳本，就是看到這個過程就知道不須要動腦，直接按照執行過程的說明來進行操做，這樣的好處是執行起來很是快，不須要邊作邊想，在作的時候動腦。

• 預期結果：任何一個測試用例必需要有一個預期，即若是系統正常的狀況下，系統反饋出來的結果究竟應該是什麼樣的。

• 實際結果：即在測試事後，系統實際展現給你的現狀。若是實際結果知足預期結果，那麼，這個功能就是能夠交付的。若是有功能的問題，那麼就是須要提交工單給研發，研發從新修改最後再上線。通常一輪測試完成之後，須要跑一遍迴歸測試。迴歸測試，就是把驗證已經經過的測試用例再走一遍，看看是否可以再跑通，確認修改問題的同時，有沒有引入新的問題。

固然，我在這裏寫的都是最簡單的測試過程，實際的測試過程比我所寫的要複雜。實際可能會測試的還會有：數據的惟一性，數據接口的穩定性等等。測試方法也不一而足，就不一一介紹了。

線上運營

在測試完成之後，就要開始準備上線了，這個時候咱們就須要考慮一個問題：咱們最初始的用戶從哪兒來？尤爲是創業公司，獲取初始用戶完成冷啓動的過程是如此的重要，以致於一旦錯過了時間節點，每每公司就黃了。

通常來講拉取用戶最有效的方式簡單粗暴，就是拼爹和砸錢，你們去北京的各個街道小區轉一轉就知道，爲何會有以專門幫人作地推賺錢的人。但是並非每一個初創團隊，都有這麼多錢能夠玩的，並且，即便有不少錢，也不是能夠亂花的，那怎麼辦？

到用戶羣體去發帖，去作SEO，去作市場活動，靠別人推薦，這些都是常規的運營方法，然而，作運營不是天天重複的發帖，作活動就行的，還須要制定運營的策略，來規範化這個過程。因此咱們運營的策略就須要考慮以下幾個問題。

• 常規的運營策略有哪些是能夠用的？

• 這些策略須要的資源有多少（資源包括：人力，金錢）?

• 各個策略分別可以使我得到多少收益？他們的轉化率是什麼樣的？如何提升策略的轉化率。

• 各個策略適用於哪些時間？適用於哪一個階段？

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

--------------------------------------------------------------------------------------------------------

更多內容請關注微信公衆號：