產品規劃一定程度上可以幫助產品經理更有邏輯地建設產品，提升產品后續迭代時的靈活性。那么，產品規劃怎么做，才可以更加清晰明了、并實際性地助推業務？本篇文章里，作者總結了B端產品規劃的相關步驟，一起來看看。

最近一年我的工作主要是產品定位、年度季度目標制定、績效達成。在產品規劃方面有很多實踐經驗和感悟，在這里跟大家分享一下。

首先談一談為什么要做產品規劃。

不做產品規劃行不行？其實是可以的，業務需要什么，我們就往系統里堆功能就完了唄。但逐漸會發現系統功能多得你自己都說不全，也不會用；客服越來越多，但還是解答不過來客戶的問題；研發越來越頻繁地反饋代碼改不動了，沒辦法再加功能了；業務會說競品早都已經有這個功能了，為什么我們沒有這個功能；銷售抱怨我們的產品不如競品，不好賣。

產品規劃的作用有以下幾點，在未來一段時間：

• 有計劃地建設產品能力，在細分市場長期保持產品競爭力；
• 產品功能復雜度可控，在滿足多角色需求的同時保持簡易用，從而降低銷售成本和運維成本；
• 給研發架構設計一個參考，通過保障架構的擴展性，來提升產品迭代的靈活性，最終表現為對市場的反應速度。

整個實操分為五個步驟，逐層遞進，形成一個個迭代要建的產品能力：

1. 對標市場商業化產品做產品定位。
2. 按照支撐未來三年發展的目標設計產品架構。
3. 列出未來一年需要的產品能力，形成能力清單。
4. 將用戶關鍵行為路徑與能力清單結合起來形成能力地圖。
5. 按照MVP和業務需要來規劃產品迭代。

一、第一步：產品定位

產品定位沒有那么高大上，就是很簡單，你這個產品是用來給誰解決什么問題的。在B端產品中，一般就是用來解決企業問題的。而企業的問題在過去幾十年過程中其實并沒有實質性變化。在經營層面，企業核心問題還是市場拓展與財務健康度的問題；在運營層面，企業核心問題還是信息流資金流實物流三流合一和組織文化機制建設的問題。

做B端產品定位的時候切記不要自high，自認為造出來一個市場上沒有的產品，其實所有的企業問題在過去幾百年中都已經被明確定義過，只是不同時候的解決手段不一樣。

下面展開講一講我對B端產品的一些理解。

上圖是我在水滴產品訓練營里看到的一張PPT，覺得說得挺有道理的，大家也可以把自己在做的產品往里套一套，這是最頂層的抽象了。實操層面我還是從【給誰解決什么問題】的角度給大家講講常見的一些產品。

企業里的典型角色分為銷售、營銷、實施、產品、技術、采購、財務。把這些角色串在一起的是企業的三流（信息流資金流實物流），這些角色共同往復著【生產產品→銷售產品→回款再投入生產】的過程，為了提升這個過程的效率和質量，就會衍生出一些信息管理系統。

例如圍繞銷售這個角色，市面上定義出CRM（Customer Relationship Management，客戶關系管理），提供包括銷售線索管理、客戶信息管理、營銷資源投放、客服外呼等等能力，核心是為了提升銷售角色的效率。

做CRM最成功的公司是Salesforce，但在Salesforce之前就有傳統ERP企業在做，可以追述到上世紀80年代。近兩年CRM系統在國內甚囂塵上，但其實CRM也存在很久了，即便沒有CRM，銷售也在利用Excel作為CRM的替代產品來解決客戶信息管理的問題。

例如圍繞技術研發這個角色，市面上定義出DevOps（開發運維流水線），提供包括代碼管理、應用部署、線上運維等一系列技術研發過程中要用到的工具，核心是提升研發在系統全生命周期的工作效率。

DevOps是已經存在了幾十年，并且市面上已經有開源解決方案，即便沒有DevOps，在研發的各個環節也有相應的工具來解決問題，只是DevOps更強調整個各環節流水線作業。

很多大企業內部在做信息管理系統的時候，由于技術資源比較充沛，往往會東起一個輪子西造一個造輪子，過兩年再來個大合并，最后發現這玩意兒在市場上早就有了。

所以說做產品定位的時侯一定要看市場，千萬不要認為自己造出來一個市場上沒有的產品。

只有一種情況例外，就是在出現技術革命的時侯，解決同一個問題的手段發生了本質性變化，那么會出現一個市場上沒有的產品。

例如傳統記錄信息的方式是紙質媒介，最早計算機將信息記錄在打孔紙片上，后來磁信息存儲技術成熟，出現了磁帶、光盤等一系列革新性的產品。但大部分企業都不會走在這樣的前沿。

產品定位最后輸出的內容很簡單：

1. 一句話版總結產品解決的核心問題是什么？
2. 產品給哪些角色解決什么問題？
3. 每個角色進入到系統里的關鍵任務有哪些？
4. 為了完成這些關鍵任務需要的關鍵產品能力有哪些？

產品定位環節是最難的最耗時的，后面環節相對都好做。

二、第二步：設計架構

架構圖也并不是什么高大上的東西，架構圖就是結構化地體現第一步定義出來的關鍵能力，能有個上帝（全局）視角。結構化的思路有兩種，一種是數據流圖，通過關鍵數據在各個模塊之間的流轉來體現各功能間的關系；一種是麻將圖，通過上下來體現模塊間的支撐關系，通過左右來體現模塊間的并列關系。

以下用兩種方式展示了API網關的產品架構。

有時候我們會遇到更復雜的情況，就是這是一個多端產品，由網頁端、客戶端、服務端等端組成，這些端連起來才能解決客戶的問題。那么畫架構圖的時候，就可以畫多層級的架構圖。第一層就先要體現這個產品到底有多少端，每個端核心能力是什么，這些端是怎么相互協作的，第二層再進一步畫各個端自身的架構圖。

云計算產品就是這樣，用戶至少會接觸到資源管理端、命令行終端、API服務端。這種多層級產品架構圖同樣適用于其他復雜場景，層級也不僅限于兩層。

但架構圖有一點要求，那就是抽象能力，需要把相似的能力抽出來形成一個大的模塊，需要定義模塊里各項能力與其他模塊統一的交互方式，最終做到高內聚低耦合，有點研發模塊設計的那種意思。這個能力沒什么快速提升的方法，就是在不斷地思考不斷地設計不斷地改進過程中練出來的。

在這一步設計出來的架構圖需要能支撐業務三年的發展，怎么樣算支持住了呢，就是把業務往前推演幾步，業務需要的能力在架構圖里是不是都能找得到，在可見的將來這個功能模塊之間的關系是不是會發生實質性變化。

三、第三步：列舉能力

能力清單，顧名思義，對照著架構圖，把所有的產品功能逐層列舉成一張清單，越細越好。

這張清單的作用是讓產研以最接近實際需求的角度來認知所有的工作。之后的能力建設也基本是以這張表為準，一旦發現業務需要一個能力但沒出現在清單里，就要及時補進去。

但能力清單不用拆得事無巨細，只要能管住未來一兩個季度就行，按需拆解，不斷完善，像點亮技能樹一樣一個個地建設這些能力。

四、第四步：能力地圖

能力地圖這個事也簡單，「能力」指的就是能清單中的能力，「地圖」指的就是用戶關鍵行為路徑圖，在行為路徑上把每個環節用到的能力標出來就是能力地圖。能力地圖可以很直觀地看出來缺的能力與用戶行為的相關性，比抽象的架構圖更貼近業務和用戶。

五、第五步：版本規劃

版本規劃就是有計劃地建設能力，選擇建設哪些能力的依據是業務需求，為了解決同一個業務需求而建設的能力就可以放在一個版本里，如果相關能力太多就把MVP摘出來先做一個版本，后面再按需完善。

在能力清單后面可以加兩列（優先級和計劃上線版本），把未來一個季度業務預期目標相關的能力標記上，這樣就形成了產研團隊一個季度的版本規劃&工作清單。

做版本規劃的時候有一個點需要注意，研發盡量從一開始就要按產品架構來搭系統架構，拿2~4周去打好底子，才能做到未來幾年內保持快速迭代，而不是一味要求研發堆功能。

系統底子沒打好的話，過不久研發就會提出要重構代碼，業務高速發展的時候告訴你系統改不動了，不光是說萬元收入的研發成本越來越高，而是你的產品跟不上市場需求影響業務收入了，要是真一不小心掉隊了，哭都沒地方哭。

六、關于用戶體驗

本文沒有講類似于「微信是如何在十年內保持菜單不變」這種問題。我個人覺得這還是用戶體驗設計的范疇，一個人對產品有深刻理解，對用戶行為有深刻的洞察，再有一些基本的用戶體驗設計經驗，其實自然而然就知道該放哪幾個一級入口、如何遞進地引導用戶使用功能、哪些屬于低頻功能需要收起來，最終做到產品看起來簡單卻十分強大。

同事有些人說B端重要的是業務邏輯和業務流程，不必苛求用戶體驗，B端用戶通常會經過培訓，可以承受比較高的學習成本。但現實情況是由于B端邏輯復雜性，B端產品一不小心就會變得非常難用，百十來個菜單是常事，一般用戶根本不知道從何入手，如果用戶不用這些工具，也就不會實際產生價值。

所以我個人的觀點是B端產品不需要交互體驗如何地炫酷，最基本的交互效果就足夠，但一定要盡量幫用戶把業務流程串起來，讓用戶能用你的工具順利的完成工作。

七、總結

總的來說產品規劃不是一個特別難的事情，以上五個工具勤加練習，就能做好中短期的規劃。

當然產品規劃中其實還涉及一些戰略選擇的問題，歸屬于產品定位環節，例如同樣做CRM，我是要做普適的CRM，還是要做醫藥領域專用的CRM。這種戰略判斷能力和常規的產品規劃能力是平行的兩個能力，以后專門開篇講。