b端産品開發模型?産品規劃一定程度上可以幫助産品經理更有邏輯地建設産品，提升産品後續疊代時的靈活性那麼，産品規劃怎麼做，才可以更加清晰明了、并實際性地助推業務？本篇文章裡，作者總結了B端産品規劃的相關步驟，一起來看看，接下來我們就來聊聊關于b端産品開發模型?以下内容大家不妨參考一二希望能幫到您!

b端産品開發模型

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

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

首先談一談為什麼要做産品規劃。

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

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

有計劃地建設産品能力，在細分市場長期保持産品競争力；

産品功能複雜度可控，在滿足多角色需求的同時保持簡易用，從而降低銷售成本和運維成本；

給研發架構設計一個參考，通過保障架構的擴展性，來提升産品疊代的靈活性，最終表現為對市場的反應速度。

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

對标市場商業化産品做産品定位。

按照支撐未來三年發展的目标設計産品架構。

列出未來一年需要的産品能力，形成能力清單。

将用戶關鍵行為路徑與能力清單結合起來形成能力地圖。

按照MVP和業務需要來規劃産品疊代。

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

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

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

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

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

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

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

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

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

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

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

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

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

産品定位最後輸出的内容很簡單：

一句話版總結産品解決的核心問題是什麼？

産品給哪些角色解決什麼問題？

每個角色進入到系統裡的關鍵任務有哪些？

為了完成這些關鍵任務需要的關鍵産品能力有哪些？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文由 @彬哲 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!