如何做好B端產品規劃?這“一攬子工具”幫到你!

語言: CN / TW / HK

產品規劃一定程度上可以幫助產品經理更有邏輯地建設產品,提升產品後續迭代時的靈活性。那麼,產品規劃怎麼做,才可以更加清晰明瞭、並實際性地助推業務?本篇文章裡,作者總結了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。這種戰略判斷能力和常規的產品規劃能力是平行的兩個能力,以後專門開篇講。

本文由 @彬哲 原創釋出於人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基於CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

給作者打賞,鼓勵TA抓緊創作!