編輯導語：B端產品即為組織提供商業(yè)價值的產品或服務，B端產品設計能力是產品經理需要具備的能力之一。本文作者通過正在規(guī)劃的戰(zhàn)略項目，總結B端產品設計的方法論，分享一些能夠指導B端產品經理具體工作的方法，希望對你有所幫助。

最近我們正在規(guī)劃設計一個部門的戰(zhàn)略項目，目標是搭建一套可支持對外商業(yè)化的零售SaaS系統，過程中涉及到一些B端產品設計的方法論，我覺得有必要總結分享一下。

總體來看把過程分為以下三個階段：

1. 背景分析
2. 需求調研及分析
3. 系統搭建

具體每個階段又分為若干步驟，這些可以指導B端產品經理的具體工作，純干貨分享。

一、背景分析

做背景分析第一步先看需求來源，這決定了項目的重要性和緊急性，通常有以下幾種：

1. 客戶需求-合同、招標書

對于靠為大公司做定制開發(fā)軟件的企業(yè)來說，這是常規(guī)操作，拿到合同或招標書后開始啟動，有明確的deadline，時間要求比較緊迫。

2. 戰(zhàn)略需求-老板

做過C端產品經理的朋友都經歷過老板基于個人喜好、同理心，對人的理解，突然提一些奇思妙想，希望團隊盡快落地。

而B端產品的服務對象是企業(yè)，需要基于業(yè)務的系統性邏輯思考，天馬行空的成分會低很多，老板通常是基于一定的洞察力發(fā)現未來可能會出現的機會和變化，結合目前策略上的差距，指出戰(zhàn)略方向，但具體怎么做仍需要專業(yè)團隊的分析輸出。

由于看的是未來戰(zhàn)略，老板相對會有耐心，會給團隊足夠的時間分析準備，屬于重要但不緊急的項目，但會階段性檢查成果，通常半年或1年是一個節(jié)點。

3. 日常需求-產品經理

通常是自發(fā)的，基于對產品體驗的優(yōu)化、競品的對標、客戶的反饋，圍繞戰(zhàn)略需求有針對性的打造，重要性上不如戰(zhàn)略需求，緊急性上不如客戶需求。

作為一家致力于打造SaaS產品的企業(yè)來說，第2和第3種需求將會是主旋律。當然也不排除第1種需求，但比例應控制在10%-20%，傳統的軟件公司就完全是第1種需求驅動。

如果按照凱勒&帕帕森的《最重要的事，只有一件》理論，那么對要吃SaaS商業(yè)化這碗飯的企業(yè)來說，當前階段這個戰(zhàn)略項目的規(guī)劃和落地就是唯一，至少應該保證有一個全職團隊要不遺余力的做這一件事，其他事情都靠邊。

背景分析的第二步是“戰(zhàn)略五看”，分別是：

1. 看環(huán)境
2. 看行業(yè)
3. 看客戶
4. 看競爭
5. 看自己

從長期視角洞見行業(yè)終局， 從全局視角觀察領先格局，從動態(tài)視角把握趨勢，再回到行業(yè)的本質，看看哪些東西是不變的。

知己知彼，從環(huán)境、行業(yè)、客戶分析得出的行業(yè)機會點，結合從競爭、自己得出的戰(zhàn)略控制點，可以識別出未來的戰(zhàn)略機會，最終推導出where to go，既確定產品的目標和范圍。

每個產品都有特定的用戶群體，確定產品目標和范圍實際上就是輸出如下這段話：

我們的目標客戶是一家 XXX 企業(yè)，目前他們的工作方式是：XXX ，面臨了 XXX 的痛點，我們可以通過提供 XXX 產品解決，可以達到 XXX 的效果。

把這段話中的XXX補齊，輸出的就是我們的目標客戶和產品，多段這樣的話就組成了我們的目標客戶群和產品范圍。

4. 以零售行業(yè)為例，輸出“戰(zhàn)略五看”

4.1 行業(yè)終局

如我在《三維零售-我的最終幻想》一文中所分析，未來零售行業(yè)的終局可以用“商品-時間-價格”的三維坐標來表示，原點就是“你在腦子里想象某個東西，不論是你曾經見過、用過，或者僅僅是一個設想時，都能以一個最合適的價格立馬獲得，并且瞬間出現在面前”。

那么為了達到這個目標，企業(yè)首先會通過全渠道零售構造一條價格和時間的曲線，然后通過供應鏈C2B能力打造一個曲面，最后將這個曲面逐步向原點趨近，越趨近于原點的企業(yè)競爭力越強。

換個角度，誰能夠有效幫助零售企業(yè)趨近這個終局，誰就可以在企業(yè)服務市場中分得一杯羹。

4.2 領先格局

通過對20多家零售企業(yè)服務商的調研，我們發(fā)現邏輯簡單、價格便宜的管家婆，備受傳統中小企業(yè)青睞，滿足日常經營80%場景，橫跨7大品類服務50萬家企業(yè)：

我們發(fā)現營銷玩法多樣、體驗好、平臺服務豐富、緊跟微信生態(tài)的有贊，備受中小型數字化轉型企業(yè)的喜愛，滿足多種業(yè)態(tài)服務于8萬商家；

我們發(fā)現深耕多年商超、連鎖、便利店業(yè)態(tài)的海鼎，具有強大的配置能力，豐富的報表，全面細致的功能，能滿足大型企業(yè)的精細化運營需要，在深耕行業(yè)有很強的影響力；

我們發(fā)現具有豐富產品線、強大的財務管理模塊、復雜的組織管理能力，正在向SaaS轉型的傳統軟件廠商用友、金蝶，具有大量高端客群，行業(yè)案例豐富，對大型集團公司有很強吸引力。

4.3 趨勢

2020年兩會三番五次提到產業(yè)數字化、新基建、互聯網+等等概念，已上升到國家戰(zhàn)略，企業(yè)在數字化轉型，降本增效上有迫切需求。

尤其是這次新冠疫情席卷中國之后，很多企業(yè)用5個月完成了過去5年都沒有下決心做的事，是一次難得的歷史機遇。

而社零數據中網上實物零售的比重也從2019年同期的18%增長到25%，交易上行的大勢已不可阻擋。

就連打造平臺生態(tài)的微信，也于7月10日正式宣布將推出“微信小商店”，一套免開發(fā)0費用的賣貨小程序，裁判員也脫光膀子下場當起運動員。

4.4 行業(yè)本質

無論是阿里新零售、京東無界零售、騰訊智慧零售，也無論是重構人、貨、場、還是流量、轉化、客單、復購、裂變的新零售公式，企業(yè)追求的永遠是降本增效，成本、效率、體驗的優(yōu)化。

二、需求調研和分析

最傻的需求調研方法恐怕就是直接跑過去問客戶：你要的是什么？你有什么需求？

因為這樣你壓根得不到想要的結果，或客戶根本提不出需求，或覺得客戶提出的都是不痛不癢的需求，或感覺極具個性化，做與不做無所謂。

畢竟你調研的人不是技術專家，他們關注的永遠都是看得見的需求，如果你傻傻的只滿足了這些看得見的需求就交差，那就大錯特錯，結果只有一種：客戶不滿意，反饋系統難用。

產品在接收到一個需求時，除了關注業(yè)務反饋的點外，應該具備在實際工作場景中挖掘那些看不見的點的能力，甚至進一步的需求。

這需要對業(yè)務的充分理解，做到感同身受，設計出更合理、高效的方案。

舉個例子：

給某個超市做一個紙質價簽管理功能，客戶提出的需求就是能夠查看并根據商品價格打印價簽，這是一個看得見的需求。

于是，產品經理就在每條商品詳情頁增加了一鍵打印功能。按說客戶提出的點滿足了，但交付后客戶反饋系統沒法用，非常不滿意。

如果我們深入挖掘一下，就會發(fā)現至少有以下幾個看不見的和進一步的需求：

1. 一般便利店都會有上千個SKU，假設每次10%變價，也會有100個價簽需要打印，而每次進入商品頁面打印價簽的操作時間至少5秒，打印100次，再加上等待打印時間，可能半個小時都搞不定，這個過程對于店員來說非常煎熬，降低人效不說，而且會極大影響工作熱情；最好的解決方案就是提供批量打印功能，在等待打印同時還可以做別的事情；
2. 線下門店打印價簽通常是提前為促銷做準備，或者是促銷后恢復原價，這個反應速度越快越好，為了做到無縫銜接，價簽打印要前置，也就是在系統真正變價之前就準備好物料，所以要有按變價時間維度篩選商品并打印價簽的功能；
3. 促銷是變價的主場景，所以應該有預先知道門店促銷活動的功能，這就需要營銷日歷，讓店員清晰明確的了解到接下來的活動及變價情況，并且聯動打印價簽；
4. 促銷活動的種類繁多，那么在價簽樣式上要予以區(qū)分，尤其是與普通商品的價簽樣式，那么是不是可以考慮增加各種活動的價簽模板，并給出不同的默認顏色和樣式，額外再提供編輯功能；
5. 我們發(fā)現經常變價的門店人力成本非常高，除了打印還有核對、陳列，偶爾的操作失誤還會引來客訴，基于ROI考慮，是不是可以改用電子價簽呢？這就是進一步的需求了。

綜上，如果每一個產品都能向前一步說話，從行業(yè)“降本增效”的本質出發(fā)，設身處地的為客戶思考，獲取全量的真實需求，也就避免了無從下手及費力不討好的窘境。

價簽管理只是一個很簡單的功能，當我們面對復雜功能的需求調研和分析時該如何下手，還是要有一套方法論。

1. 過程分為三步

1.1 業(yè)務流程梳理

業(yè)務流程是分層的，尤其是當我們把目標客戶定位為中大型企業(yè)時問題尤其復雜：

1. 第一層：是組織級，集團視角，關注分工、管理和大方向的業(yè)務流向。比如在零售企業(yè)中，就會存在供應鏈、門店、售后，客服、財務等幾個不同的部門。這一層的調研內容主要是確認企業(yè)的組織構成，流轉方式，目前存在的經營問題，尋找潛在的機會點；
2. 第二層：是業(yè)務級，部門視角，關注每個崗位具體負責什么，產出什么，以及這些活動之間的關聯。例如門店部門要銷售商品，需要庫管、銷售運營、導購的配合才能完成，產出就是銷售額，這是業(yè)務流程梳理的主線索，也是主要輸出。這一層的調研內容主要是確認部門內崗位分工，每個業(yè)務事件的流程，參與者，事件及關注的產出物，通常是報表形式；
3. 第三層：是操作級，通常是某個崗位的視角，實現某個業(yè)務場景需要的具體操作步驟，可能由某個或幾個崗位的人操作，屬于需求細節(jié)。這一層的調研內容主要是確認每個角色參與的業(yè)務流，日常的操作流程，了解功能、數據、用戶體驗等方面的問題。

業(yè)務流程分析起來很多很復雜，還會有子流程嵌套，很難用文字描述清楚，因此這一步的產出最好采用跨部門和崗位的泳道圖，下邊以線下銷售場景為例說明：

線下門店銷售業(yè)務流程橫跨3個部門7個崗位角色，而每一個步驟又包括若干的子流程，輸出這個流程的目的是確認各個部門之間的關系，及各個角色應該承擔的工作內容。

1.2 角色與場景分析

基于步驟1輸出的角色應承擔的工作內容，再具體看某個角色在特定場景中都需要做什么事，那么就拆分成兩個基本要素：

1. 參與者：這個流程中與系統進行有意義交互的任何事物，可以是某個崗位的人，也可能是一個硬件或系統，比如門店銷售可以是導購，也可以是自助結賬機，線上銷售就是APP或者小程序；
2. 做什么事：是指系統執(zhí)行的一系列動作，是一個動詞+名詞的組合，且必須是有意義的，產生實際結果的動作，比如，操作收銀機執(zhí)行一系列動作，生成銷售訂單，這就是一個完整的場景了，但只是添加一個商品到購物車，這不能叫完整場景。

2. 為什么要用這種角色+場景的方式分析

主要因為以往很多技術性產品經理在分析和設計產品時，總是以功能的視角去思考，既這個系統應該有什么功能，這樣做出來的產品就是一系列功能的堆積，用戶常常抱怨太難用。

看到一堆“xx管理”的菜單，根本不知道干什么用，即使看了天書一樣的手冊，要完成一個場景，可能需要切換若干個菜單模塊，合上天書，又不知道該去哪找需要的功能了。

而以角色+場景方式驅動的分析方法，是一種側重于“用戶視角”的分析，將系統做成一個黑盒子，不僅可以有效指導最終展現的菜單形式，避免上述問題，還有利于梳理場景時發(fā)現那些看不見的問題。

下邊以“導購”角色的“銷售”場景為例進行分析：

步驟2分析的角色+場景只輸出了一個核心路徑，是主流程，還要補充拓展流程、完善前置條件、后置條件、特殊規(guī)則。

• 拓展流程：指分支事件和一些異常情況；
• 前置條件：指這個場景發(fā)生前需要系統具備哪些能力或處于哪個狀態(tài)；
• 后置條件：是場景結束時輸出的內容或一種狀態(tài)；
• 特殊規(guī)則：就是受限于客觀情況必須規(guī)避的情況，比如硬件性能、數據庫大小、使用環(huán)境、技術選擇、公司規(guī)定等產生的限制。

將多個角色場景進行抽象整合輸出系統用例，系統用例作為最小需求單位指導系統開發(fā)。

這里說的抽象整合就是技術層面的復用邏輯，好比軟件開發(fā)中“類”和“對象”的關系，系統用例是一類的抽象，角色場景是一個具體的行為。

仍然以“導購”+“銷售”場景示意，輸出系統用例如下：

三、系統開發(fā)

進行到這一步，系統變得越來越具象，引入的人也會越來越多，一個很復雜的項目為了保證原始需求不走樣，非常有必要的一步是把系統用例映射回原始業(yè)務流程，看看是不是都覆蓋全了，可以用類似這樣的表來跟蹤：

這是一個回顧和整理的過程，同時優(yōu)化系統用例，按照模塊分工給相關的人輸出原型設計和數據報表，這些是技術產品經理最擅長的了，但需要強調3件事：

1. 菜單結構設計

很多技術產品在設計交互時喜歡用功能模塊來劃分菜單結構，直接把底層的功能投射到用戶交互層，這對于沒有行業(yè)屬性的軟件來說是迫不得已，但在客戶實際使用中卻有很大缺陷。

因為在業(yè)務操作中，會出現不同層次頁面的頻繁交替，讓使用者云里霧里，感覺十分混亂。

產品經理只能通過輸出天書版的操作手冊來培訓使用者，無形中增加了學習成本，而放下天書，又忘了該去哪個頁面操作，想找一個功能也不知道該去哪個頁面。

對于垂直行業(yè)的B端產品來說更好的方式是以“業(yè)務場景”來劃分菜單結構，以完成某一件事為主線，好處是可以明顯改善重復和混亂的現象，讓整個系統的菜單結構清晰明了，使用者更容易上手

為了適應不同行業(yè)中“業(yè)務場景”可能存在的差異，系統中還可以設計一套業(yè)務流程管理功能(BPM)，去定制“業(yè)務場景”中的操作流程，并最終體現在菜單結構的改變。

這是一個很復雜的功能，但對于橫跨多種行業(yè)的軟件來說可以大大增加系統靈活性，減少后期的開發(fā)工作量。

2. 數據操作完整性原則

本質上軟件的工作就是信息輸入、信息處理和信息輸出。

在設計輸入環(huán)節(jié)時我們要檢查“增刪改查CRUD”四個基礎功能是不是給全了，是不是能夠在一個頁面內解決？以及是不是足夠好用。

比如商品主數據的輸入，由于涉及到大量SKU，那么設身處地為操作人員考慮，從提高效率的角度，要考慮批量導入，批量刪除、批量修改、條件篩選的功能；在設計輸出環(huán)節(jié)時我們要提供豐富的篩選查看以及必要的導出功能，這樣不僅方便客戶在系統內查看數據，也可以自助導出用其他工具透視。

通常不同的數據操作權限會分配給不同的角色處理，所以不僅要提供功能，還要考慮在權限層面解耦出來。

3. 角色權限模型

B端產品通常都適用于RBAC權限模型(Role-Based Access Control)，也就是每個用戶都要被賦予一個或多個系統角色，每個系統角色都對應一個明確的權限集合，包括對菜單、頁面元素、數據資源的訪問與操作權限。

需要建立一個“用戶——角色——權限”之間的對應關系，用戶與角色，角色與權限都是多對多關系，即一個用戶可以對應多個角色，一個角色可以分配給多個用戶，一個角色具有多個權限。

當用戶比較多時，還可引入用戶組，將角色與用戶組進行關聯，當角色發(fā)生變更時，可以大大提高操作效率。

完成這些工作后交付UI設計，最后進入軟件開發(fā)，這兩步就要交給專業(yè)的UI設計和軟件架構師操刀了。

四、總結

B端產品設計需要豐富的行業(yè)背景和專業(yè)能力，不僅要有邏輯能力還要有全局視野，清楚行業(yè)的上下游關系，看不同角色在鏈條中的作用。

不應是簡單的堆砌功能，也不是所有的功能都適合做到線上，而是要看清楚哪些符合行業(yè)本質，才在哪個方向發(fā)力。

本文由 @劉生 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議