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

首先談一談為什么要做產(chǎn)品規(guī)劃。

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

產(chǎn)品規(guī)劃的作用有以下幾點，在未來一段時間：

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

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

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

一、第一步：產(chǎn)品定位

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

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

下面展開講一講我對B端產(chǎn)品的一些理解。

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

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

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

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

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

DevOps是已經(jīng)存在了幾十年，并且市面上已經(jīng)有開源解決方案，即便沒有DevOps，在研發(fā)的各個環(huán)節(jié)也有相應的工具來解決問題，只是DevOps更強調(diào)整個各環(huán)節(jié)流水線作業(yè)。

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

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

只有一種情況例外，就是在出現(xiàn)技術(shù)革命的時侯，解決同一個問題的手段發(fā)生了本質(zhì)性變化，那么會出現(xiàn)一個市場上沒有的產(chǎn)品。

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

產(chǎn)品定位最后輸出的內(nèi)容很簡單：

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

產(chǎn)品定位環(huán)節(jié)是最難的最耗時的，后面環(huán)節(jié)相對都好做。

二、第二步：設(shè)計架構(gòu)

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

以下用兩種方式展示了API網(wǎng)關(guān)的產(chǎn)品架構(gòu)。

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

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

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

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

三、第三步：列舉能力

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

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

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

四、第四步：能力地圖

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

五、第五步：版本規(guī)劃

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

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

做版本規(guī)劃的時候有一個點需要注意，研發(fā)盡量從一開始就要按產(chǎn)品架構(gòu)來搭系統(tǒng)架構(gòu)，拿2~4周去打好底子，才能做到未來幾年內(nèi)保持快速迭代，而不是一味要求研發(fā)堆功能。

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

六、關(guān)于用戶體驗

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

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

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

七、總結(jié)

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

當然產(chǎn)品規(guī)劃中其實還涉及一些戰(zhàn)略選擇的問題，歸屬于產(chǎn)品定位環(huán)節(jié)，例如同樣做CRM，我是要做普適的CRM，還是要做醫(yī)藥領(lǐng)域?qū)Ｓ玫腃RM。這種戰(zhàn)略判斷能力和常規(guī)的產(chǎn)品規(guī)劃能力是平行的兩個能力，以后專門開篇講。