從業務運維轉到產品經理，我摸爬滾打的產品之路

作者分享了自己如何從業務運維轉崗至產品崗，以及在此之後對工作的一些總結與思考，希望本文能夠對新晉的PM帶來幫助。

寫這篇文章的初衷是想總結下自己從業務運維崗轉到產品經理崗后，大半年來如何從「零」開始摸爬滾打過來的經歷，同時作為一個新入行的產品同學對產品經理這個崗位與如何做2B產品的一些理解和思考！ 如果把這篇文章當做一個產品需求的話，那麼這個需求中的角色與場景是什麼呢？

• 對自己這個新產品同學大半年的一個梳理與總結
• 已有若干年工作經驗積累想轉產品崗的非產品崗同學（例如PM、開發、運維）。您可以從本文中獲知產品經理是幹什麼的？需要那些能力？ 產品經理這個活要怎麼干？（建議全文閱讀）
• 0-1歲的產品新同學，我們相互印證、借鑒、交流、提高。您可以從本文中獲知一個新入行的產品經理在沒人帶的情況下這一路的成長路徑與踩過的坑，說不定也可以幫您繞過這些坑！（建議閱讀起點與在路上這兩個章節）
• 有c端產品經理經驗，剛進入2B端產品的同學。您可以從本文中獲知同樣一個作為新入行的2B產品經理，對2B產品的小理解，說不定這些小觀點可以幫助到您！(建議閱讀一起修鍊2B吧這個章節)

起點

先做一個簡單的自我介紹，加入騰訊后，一直是在手Q的業務運維崗位，負責手Q的產品運維，話說這個崗位和產品打交道最多的場景，那應該就是因為活動與產品功能導致的資源需求問題與產品經理PK了。

在轉崗之前自己對產品經理這個崗位的理解其實也是很懵懂的，去年下半年中心試水成立做對外運維產品的團隊，目標是讓我們內部多年打磨的DevOps最佳實踐平台織雲走出去（團隊的全體成員都是業務運維崗位出身），就搖身一變成了產品狗。 當時想著沒吃過豬肉，還沒有見過豬跑了，畢竟也帶過內部運營系統的規劃與熟悉運維所使用的運營系統，後面的經歷充分驗證了一句話無知者無畏！

1. 這裡先按序理清一些基本概念

• 產品是什麼？
• 產品經理是個什麼鬼？
• 2B產品經理的價值是什麼？
• 產品經理的工作內容包括哪些？
• 產品經理需要那些能力？
• 產品團隊有哪些角色構成？

2. 產品是什麼？

產品是指能夠提供給市場，被人們使用和消費，並能滿足人們某種需求的任何東西，包括有形的物品、無形的服務、組織、觀念或它們的組合。

是不是覺的有點小抽象？這句話的關鍵詞是 市場、使用、消費、需求。生活化來說每天在路邊買的熱乾麵是產品、騰大12樓的包子也是產品，它們同樣都滿足了我們要吃飽的需求。同樣手機QQ與微信也是產品，滿足我們溝通與連接的需求。

3. 產品經理是個什麼鬼？（Product Manager）

產品經理這個詞其實是一個比較寬泛的且帶有一定的行業屬性的辭彙，這裡所描述的產品經理的定義是特指IT行業或者互聯網行業中的一種職能，負責IT（互聯網）產品的規劃和設計，以及生命周期的管理。 這句話的關鍵詞是 規劃、設計與管理 。

在《啟示錄：打造用戶喜愛的產品》這本書中是這樣介紹的 產品經理的主要任務是探索產品的價值、可用性、可行性。以前看到這句話的時候是有些似懂非懂的，但是現在回頭來看，是非常認同的。

這裡多說兩句，產品經理這個崗位是自帶矛盾屬性的，而且帶上經理這兩個字，感覺應該是有權利的，其實毛線權利都沒有！

• 入行門檻低，相對於業務運維崗位來說，這個崗位並沒有帶很多硬性的技能指標，但是真正入門與做好感覺蠻難的，之前和同行交流新同學入行后基本會有三座大山，產品化思維、做產品的能力、行業產品的感覺，其中做產品的能力還相對是可量化的一些指標，而產品思維與感覺就有點不好量化了（每個人的解讀可能都不同）
• 也有說每個產品經理都是一個潛在的CEO(喬幫主、pony、雷軍等等行業大神)，但是同時也是一個全能的背鍋俠，而且是360度無死角的背鍋。

4. 2B產品經理的價值是什麼？

一般談到價值就會有各種大詞出現，這裡不說大詞，用一種接地氣的方式描述。筆者認為產品經理的價值用一句話就能說的明白。

幫助自己所服務的團隊(公司)，設計(演化)出能滿足用戶需求的正確的產品，並且能直接或者輔助的真金白銀的把錢賺回來。

是不是覺的有些俗氣？不過產品就是這樣，一個設計且落地的產品如果不能直接或者間接輔助的把錢賺回來。那這個產品其實失敗的，做好的包子賣不出去都是庫存，那麼這些包子也都沒有創造應有的價值？ 這句話的關鍵詞是 設計(演化)、 滿足、需求、正確、賺錢。

5. 產品經理的工作內容包括哪些？

基於我對產品經理崗位理解與這大半年的主要工作，我總結的產品經理具體工作內容如下，其實也就是一個產品落地的主要步驟（線性順序）。

• 市場調研分析：主要是調研分析大的商業環境怎麼樣？蛋糕夠不夠大？這個額度的蛋糕能持續吃多久？蛋糕還能不能增大？行業內現有哪些重量級的玩家？有哪些成熟的商業化的競品？我們的客戶有哪些？這些客戶擁有哪些共性、細分、潛在的需求等。 這部分其實對剛入行的產品經理來說是蠻難的部分，感覺就是無從下手，我印象我們那會也是套用兄弟部門成熟團隊給老大們做的彙報PPT，然後照葫蘆畫瓢拆解著做。特別是大環境分析相關，如果沒有BI團隊的介入，基本搞不定，就算可以參照一些行業數據，也無法保證其有效性和準確性。
• 產品規劃：規劃產品的定位，確定用戶群體分類(是誰用)？與怎麼用？(場景)，在這部分一般都是輸出產品功能地圖(思維導圖)，能說明白講清楚就可以了。
• 產品設計：定義產品體驗和價值、設計產品結構和功能。 在這部分就要輸出整個產品(功能)的原型設計了，整體產品體驗與功能點的框架在這裡都通過原型展示。建議盡量輸出帶基本交互的產品高保真原型，這樣一是內部評審時更加清晰，而且也可以減少後期後期與開發兄弟的溝通成本。
• 需求文檔：配合原型一起講述組成功能集的明細需求的文檔(TAPD)可以讓開發兄弟提供他們認為最便於他們理解的結構，產品經理填充內容即可。
• 需求實現：與開發同學一起緊密配合與溝通，共同完成需求的開發與上線。
• 產品驗收：開發完成與自測后，產品經理來做主體功能的驗收，這裡主要是驗收業務邏輯是否符合產品經理的設計。至於產品質量暫時不在這裡考慮，那個層面主要是測試和開發一起來保證的。
• 用戶手冊與場景描述視頻：用戶的幫助說明文檔。 用戶文檔這部分其實也可以分為產品手冊與典型場景文檔，典型場景文檔是產品手冊的一個子集。 不過通過後續的交付來看，用戶基本都是不怎麼看文檔的，所以我們同時也錄製了場景使用視頻更方便用戶使用。
• 迭代優化：收集分析用戶的反饋，挖掘優化點與新需求。對產品進行迭代和優化升級。

6. 產品經理需要那些能力？

基於上文的產品經理主要工作內容，我們就已經基本可以勾勒出一個產品經理需要那些能力，3+N能力模型 3個核心能力+N個基礎能力。

會用工具

• Axure RP（產品原型繪製）
• Xmind(思維導圖)
• Visio(畫業務邏輯流程圖)

思維能力

• 抽象思維能力
• 結構思考能力(邏輯思維能力)
• 邏輯能自洽

能說會寫

• 能和在產品整個設計與落地過程中和不同的人不同的角色把事聊明白聊透。
• 面對用戶介紹的時候能講用戶故事並且能把用戶故事講圓。
• 能寫出來你的團隊成員和用戶能看明白的文檔。

懂點設計和交互

• 避免設計出反人類的交互流程
• 頁面更好的布局

懂點技術

• 這裡並不是說要很懂，畢竟不是具體的開發同學，而是說有一定的技術背景和開發能聊到一起。

行業業務能力

例如我是做業務運維出身的，那我就明白運維是做什麼的？運維要怎麼做？運維需要什麼樣的工具平台。

懂點數據分析

• 知道自己需要什麼樣的運營數據去作為後續迭代優化的基準。

懂點項目管理

• 思維能力、能說會寫、行業業務能力 這三個是核心能力，其餘是基礎能力

7. 產品團隊由那些角色構成？

一個完整的產品團隊會有以下角色構成：

• 產品經理
• 設計(視覺與交互)
• 技術(前台、後台、測試、售前、售後)
• 運營
• 市場
• 商務
• PM

我們這個團隊在剛開始的時候，就只有我和另外一個同學兩個產品經理，兩個人共同負責織雲自動化平台產品線的設計與落地，其餘均是部門內的運營開發同學。那會開玩笑說，我們和創業公司的唯一的區別就是我們不會破產，不用擔心發不出來工資，其餘都是和初創公司都是一樣一樣的。不過這麼一路走過來看，在國中期其實只要有三個角色（產品、開發、設計）就基本可以跑起來了，團隊小了最大的好處是溝通成本極低，就這些槍沒有什麼問題不是站立在白板前討論不清楚的，然後就直接do，遇到問題在討論！

通過上文，想轉崗的同學與產品新同學已經可以比較清晰的知道產品經理具體是幹麼的？與一個產品落地的主要步驟有哪些？

在路上

其實做產品與當產品經理和打遊戲一樣，一路也是升級打怪，層層升級的過程。下面講講我這大半年的收穫與踩過的坑。一般來說成熟的團隊會有導師帶你走，但因為我們是初創團隊,團隊裡面沒有真正的產品經理，大家都是邊做邊學，所以更多的就是靠自己了悟了。可能我的經驗更適合自己走的同學。

一、國小：找入門的路（畫看讀動拆跟）

該階段是剛入行，對於整體商業化產品落地的流程不熟悉，基本是兩眼一抹黑。在找尋入門的路時，我自己有哪些優勢和劣勢呢？

1. 優勢：

• 熟悉運維是怎麼做的？知道運維的痛點（因為團隊輸出的是運維平台產品）
• 主導過運營系統建設，了解一些系統&功能落地的基本套路
• 自己看過與用過不少運營系統
• 和開發打了多年交道，知道如何與開發溝通
• 懂點項目管理

2. 劣勢

• 沒有完整的經歷過一個商業化產品從0到1的完整流程
• 不會畫原形
• 不會寫PRD
• 不會競品分析

3. 該階段的重點

• 畫：熟悉Axure RP，臨摹別人的系統，對著畫原型。那會有時間的時候，就會對著公司級平台系統畫，這個收穫不小。畫是理清思路和熟悉基本頁面交互的好方法。
• 看：多看些老外的產品，看看老外是怎麼做的。有些看了當時的段位是理解不了的，不過沒有關係，有印象就好，後面總會有機會在去印證的。
• 讀：多看看書，看方法論的書＋具體指導的書
• 動：開始著手試著做競品分析，哪怕分析的很稚嫩，多來幾遍，自己就會漸漸的有感覺了。
• 拆：在當時手上已經有要完成的功能模塊了，在具體開始前先對照內部的平台，去嘗試的拆解業務邏輯，想想為什麼要這樣做？這樣做覆蓋了那些場景？不這樣做會有什麼樣的影響？
• 跟：跟需求，保證需求如期並符合設計的落地。

4. 當時踩過的坑

• 認為做內部運營系統就是做商業化產品的基礎，其實差別很大
  • 內部運營系統有人用，不代表是你做的好，而可能僅僅是你的目標用戶沒有的選擇，只能用這個。
  • 內部運營系統缺少版本化規劃（產品路線圖）、運營與硬性質量指標要求。
  • 內部運營系統多數只是在做需求而不是在做產品，需求的加法在內部運營系統上體現比較深，而產品是要減法多過加法（聚焦、延伸、擴展、投入產出比等）
• 剛學著入門的時候，沒有能力去分辨自己所了解的方法論與流程是否適用與自己工作的場景，給後面的路埋下雷。

二、中學：練手&熟悉（負責功能模塊）

通過第一階段的打基礎，可以說已經基本了解了些做產品的基本套路，也摸過一些小需求了。可以開始逐步上手完整的功能模塊規劃與落地了。

1. 該階段的重點

• 了解與熟悉商業化產品從0到1的規劃與落地流程
• 做好競品分析，因為在第一階段競品分析都是比較淺的，這裡我總結用剝洋蔥法分析競品功能，網上也有很多做競品分析的方法論，大家也可以參照：

分析用戶群體

分析用戶場景

分析用戶故事

分析用戶功能點使用頻率

分析現有功能覆蓋面

分析所傳達的理念

• 二八原則（20%的功能能滿足用戶80%的使用場景）
• 見用戶、發現需求，並思考共性場景。
• 不能只能聽用戶的、甄別偽需求，思考用戶真正的需求是什麼？
• 確定產品功能做多少？功能優先順序是什麼？
• 做好業務邏輯構思與交互體驗

2. 當時踩過的坑

• 不擅長砍需求與合併需求，貪圖大而全，技術人員思維，總想著做全面，不要遺漏場景
• 不善於定位需求的目標、目的與需求完成後的分析
• 過分注重產品交互體驗
• 追求需求場景與表現形式的趨向完美

三、大學：全局視野與產品線規劃（重點思考如何做減法，定義產品主線）

到這個階段后，基本就可以嘗試hold住整條產品線了，這個時候更多的是要想清楚如下的問題：

• 產品線大的目標與藍圖是什麼？
• 大的用戶故事是什麼？
• 在這個階段更多的思考不是簡單的需求疊加了，而是要在產品路線圖上清楚每個功能點的價值與意義了，需要把各個零散的點串起來。
• 想清楚在每個大的時間點(版本交付時間)要做什麼？不要做什麼？做了的價值在那裡？不做會影響什麼？
• 版本與版本之間的功能閉環如何做？如何保證全局邏輯自洽？
• 版本與版本間的遞進如何勾勒？

1. 該階段的重點

• 掌握與應用MVP原則，MVP是《精益創業》里提出的概念，其實概念大家都好理解，但是落地的過程中就會有各種坑了。

要抓住核心流程，MVP是一個過程，且是一個持續的過程

MVP不是一個單一的產品形態

帶著明確的目標去做MVP

盡量多用輪子(盡量儘可能的借用現在成熟的內部模塊，跨團隊與外部友商都OK)，對於我們一個非成熟的團隊來說，尤為關鍵，不可能什麼都是自己做，都自己做只能把自己累死。

• 做取捨與平衡，不該做的一定不要做，浪費人力。 對於初創團隊，有時候就是和時間在賽跑。需求是做不完的，一定要想清楚在做。
• 版本的規劃與迭代
• 用戶故事的演化
• 產品(功能)的生命周期：

設計規劃：產品的可用性

研發生產：產品的可行性。

銷售：產品的價值。

運營

市場反饋

上面這三個階段是我個人目前的升級之路，後面的路還很長，自己也在慢慢琢磨，等以後悟到了，並能應用到實踐中，在和大家交流。

四、需求池管理

想了想還是單獨把需求管理拎出來寫，為什麼？因為需求管理其實是在後面兩個階段會一直貫穿，而且也蠻重要的。

1. 需求的來源分類

詳細的需求管理方法論大家可以閱讀《普拉姆原則》，這裡提供一下我基於這個方法論和實踐總結出來的一個需求分析模板。

• 需求提交公司優先順序是說當你有多個客戶的時候，對每個客戶重要性的定義。
• 為什麼要有客戶公司內部職務呢？因為不同職務提的需求有時候會影響打單的，例如 客戶CTO提的需求和一線員工提的需求就不能等同而看，這是現實！
• 還有一點因為不好客觀度量，所以未在表格中呈現，那就是銷售對客戶的控制度，也就是在打單的時候銷售有多少把握搞定。

5、產品經理的自我修鍊

現階段我感覺產品經理的修鍊，用6個詞就可以總結。

• 多看：多看行業，多看競品
• 多聽：多聽第一手的客戶聲音，如果不能直接和客戶交流，那麼信息來源渠道也要是高保真的，不能有過多的失真度。
• 多想：多思考用戶故事、產品價值、產品藍圖。 那些一定要做，那些一定不做，那些暫緩些做
• 多說： 多和同行們交流
• 多嘗試：有度嘗試，失敗的成本是團隊所能承受的，而不是把客戶搞丟了
• 清零：避免思維定勢

同樣產品經理要避免的幾個坑

• 自high： 自己覺的很OK，趨向完美，其實沒人用。
• 想清楚在動手： 避免給產品埋下有明顯的邏輯缺陷或者功能與功能之間不能邏輯自洽，寧肯有時候壓節奏，也要想清楚。
• 過度堅持：除非你已經很牛了，大家公認的產品大牛，否則還是兼聽則明的好。
• 功能大而全： 多多想想MVP原則吧
• 細節是魔鬼： 當負責產品線的時候，更多的應該考慮全局方向，而不是一個個小細節。不是說細節不重要，而是細節可以通過後續的迭代完善。

一起修鍊2B吧

作為一個新入行的2B產品經理，我的工作也都是圍繞著打造織雲而展開的，織雲是金融行業企業級的運維管理平台，是一款典型的TOB產品。

1. 2B產品特徵

• 解決一個個工作中的具體的問題，或者將現有流程系統化從而提高效率
• 用戶具有一定的行業專業背景、並且在交付前會有對用戶的專業培訓
• 容錯率很低，試錯成本也高（2C端的小步快跑，快速迭代，幾天或者一周一個小版本目前感覺不太適用）
• 對產品本身的質量要求很高，如果因為平台質量而導致客戶業務失敗或者現網故障，那是絕對大事件。
• 運維平台提供的功能要齊全，該有的功能一定要應有盡有，那怕剛開始每個功能的深度都不是很深。B端用戶更看重一站式解決方案，而非多個平台混用，多平台企業整體IT成本和用戶學習成本都高。
• 相對C端B端更輕體驗與交互，剛開始挫一點丑一點問題都不大，只要交互流暢能順利完成即可，B端用戶在交互體驗的容忍度是蠻高的，原因還是平台核心還是要完成一個個具體的工作任務。

之前聽到一個銷售說的一句話，一個好的2B產品就是能幫助所使用這個產品的用戶打好他那份工，也就是說2B的產品要靠譜，非常認同這句話！

2. 2B產品設計思路

• 設計產品的業務邏輯要求高，業務流程的上下文關聯性強
• 業務規則複雜，場景更加細分
• 功能要先橫向堆面，在縱向挖掘深度，該有的功能一定要有節奏的上，大功能方向上面要能閉環
• 在多數場景下，功能的完善與質量永遠優先於交互體驗(視覺)等，這裡不是說體驗不重要，而是說2B產品優先要幫用戶把活幹完。
• 設計時要多角色，例如一個大平台從組織架構這個維度上看，基本會有三個角色，一線幹活的員工、中層管理、高層管理者，他們對於平台的視角不同，所期望的功能也不同。
• 許可權要明細，不同的崗位在平台裡面應該具備不同的許可權。
• 管理用戶預期的操作行為
• 簡化用戶的操作成本

3. 踩過的坑

• 過分重視交互體驗，耗費了不少時間與精力，我現在設計的一個基本原則是流暢的完成既定操作與操作流程設計的不是反人類即可，至於多點一下滑鼠，少點一下滑鼠與別的交互細節問題不大，而且交互本身也是要靠時間去打磨的。
• 業務邏輯不清晰，單純的功能點邏輯不能閉環。

總結

產品經理的修鍊之路很長，成長為一個優秀的產品經理也是蠻難的。想要做下去一定要保持對產品的熱愛，好奇心，多琢磨不同的產品，多思考。產品經理是個蠻有意思的崗位，特別是當你看著一個產品從無到有，在逐步的被用戶認可，這是一個很有成就感的事情。

書單

附上我閱讀過的產品經理相關書籍，並給出一點點小的建議。話說現在市面上2C的產品書籍很多，而2B的就很少了。

• 《傑出產品經理》 有幹活的指導意義，書中的一些方法論可以直接套用
• 《人人都是產品經理》現在應該是2.0了，有幹活的指導意義，書中的一些方法論可以直接套用
• 《簡約至上》 我買的時候，就已經印刷了25次了，可以讓你知道與應用交互設計的基本原則與方法論
• 《啟示錄：打造用戶喜愛的產品》 比較全面與有高度的方法論，同時也涉及到團隊打造

本文由 @李光 原創發佈於人人都是產品經理。未經許可，禁止轉載。