編輯導語：在B端產品從0到1的設計中，產品經理需要進行合理規劃，找準產品自身定位，洞察使用者需求，以求更精準地解決使用者痛點，並推動後續方案的迭代最佳化。本篇文章裡，作者總結了B端產品從0到1的設計方案流程，一起來看一下。

上一篇，我們講了從0到1設計B端產品的業務調研。今天，我們繼續講產品方案。限於篇幅，本文將重點闡述總體方案部分。

對B端業務調研感興趣的朋友，可以閱讀我的文章《沒有這個能力，還是合格的中級產品經理嗎？》。

一、產品方案的要點

一般情況下，從0到1的B端產品往往聚焦於企業少數幾個痛點，同時具備很強的可落地性。如果是SaaS產品，還必須長遠規劃，以減少後期迭代的成本。因此，B端產品方案主要有以下三個要點。

1。 聚焦重點

從0到1的B端產品必須聚焦重點，以最小成本驗證產品的價值。

聚焦重點的本質是“定位”，即面向哪一類客戶，解決哪一個痛點。定位良好的產品，就像一把錐子，能夠迅速切入市場，並且取得穩固的市場地位。

聚焦重點也是敬畏市場的表現。在網際網路浪潮下，不管是創業公司、還是客戶自己，往往都在一邊探索一邊調整。快速推出MVP版本，再根據使用者反饋迅速迭代，是產品創新的最佳實踐。

2。 究竟精神

永遠相信使用者，但是永遠也不要相信使用者。

所謂相信使用者，是相信當用戶提出一個需求，它確實反映了使用者存在一個困擾；所謂不要相信使用者，是不要指望使用者會透徹分析自己的需求，而他們所提出的方案往往也是“頭疼醫頭、腳疼醫腳”。這並不能歸罪於使用者，畢竟，對他們來說，達成業務目標才是最重要的事，系統只是輔助手段，不值得花費太多時間深入思考。

關於要不要聽使用者的，海底撈創始人張勇有一段經典的闡述：“消費者說海底撈不好吃，其實可能是嫌價格貴。我老婆說我回家晚，可能是我對她關心不夠。如果我信我老婆的話，每天都在家待著，我相信我老婆會更討厭我。”

在製作產品方案時，我們必須洞察使用者需求，找到需求背後的真相。而這種洞察能力，很大程度上依賴於我們的究竟精神。

比如，使用者提出，希望能夠增加一個訂單付款狀態，且當狀態為“未付款”時，不允許發貨。如果我們能夠進一步提問，就會發現使用者更深層次的需求。模擬對話如下：

產品經理：為什麼訂單沒有付款，就不允許發貨呢？

使用者：因為和這些客戶不是長期合作，為了控制風險，所以必須先款後貨。

產品經理：那麼長期合作的客戶呢？是不是就可以不付款也允許發貨呢？

使用者：要分情況，有些客戶可以付一部分款就發貨，有些客戶可以不付款先發貨。

產品經理：什麼樣的客戶可以付一部分款就發貨，什麼樣的客戶可以不付款先發貨呢？

實際上，有經驗的產品經理，會根據信用管理的框架，對客戶類別、信用政策、應收款管理等方面進行全面梳理。因為從產品架構角度來看，這個需求無疑應該納入信用管理模組。

如果一個方案沒有經過嚴謹梳理，在落地過程中就可能出現問題。比如，在上述例子中，如果直接根據使用者需求設計產品，在後期很可能就需要對方案進行大改。

值得一提的是，B端產品經理的工作非常依賴冷靜思考。如果外界給產品經理施加了過大壓力，就可能導致產品經理“動作變形”，從而做出錯誤決策。作為產品經理，我們要警惕過大的外部壓力，時刻提醒自己：沒有慎重思考過的產品，不值得浪費寶貴資源。

3。 長遠規劃

如果我們設計的是SaaS產品，則必須注重長遠規劃。

從0到1的SaaS，客群規模有一個從小到大的過程。當客戶和功能數量都較少時，如果缺乏規劃，產品就很容易野蠻生長。

比如，買贈是消費品行業常用的促銷手段。在某些情況下，贈品需要關聯到主品，比如買5瓶大可樂送1瓶小可樂。產品經理為了設計和操作方便，可能選擇直接在訂單行上新增兩個欄位，體現贈品名稱和數量。

這樣的設計在面對簡單需求時，可能不會出現問題。但一旦遇到比較複雜的需求，就會出現問題，比如：

需要管理贈品發貨；

一種售賣品送多種贈品，比如買2瓶大可樂送1瓶小可樂和1個杯子；

需要和ERP系統整合。

正確的做法是，主品和贈品都放在獨立的訂單行，擁有相同的欄位，並且透過“贈品”欄位來標識該訂單行是否贈品（打勾即為贈品）。

因此，作為SaaS產品經理，不能夠只盯著眼前的需求，而要放眼長遠，做全面的考慮。

二、產品方案的結構

如果只是針對一小塊功能的迭代，產品方案要求相對簡單。重點說清楚：

但如果是從0到1設計一款產品，特別是設計一款SaaS產品，則必須從更高、更全面的視角進行方案梳理。

我建議的產品方案結構如下：

總體方案；

詳細方案；

管理報表方案；

整合方案；

使用者期望滿足。

在總體方案部分，需要對產品價值、整體方案和總體架構進行說明，一方面便於給公司和客戶高層進行彙報；另一方面也便於產品經理們瞭解彼此的工作，提高溝通與協作效率。

在詳細方案部分，需要對每個模組的需求進行分析，重點論證是否偽需求，並明確成功指標，然後透過文字說明和流程圖對解決方案進行闡述，最後才是頁面設計和相關邏輯說明。

對於B端產品，管理報表雖然功能相對簡單，但反映了管理者的需求，需要和業務功能一併設計。否則，一旦後期發現產品不能支撐管理報表需求，就很可能導致返工。

對於針對大企業的B端產品，往往會涉及到系統整合。系統整合反映了上下游業務的需求，也需要儘早規劃和設計。

最後，產品對使用者期望的滿足程度，往往決定了使用者對產品的滿意度。即便在MVP階段無法滿足所有需求，也需要納入長期規劃。

三、總體方案

總體方案是整個產品方案中最精華的部分。理論上，僅僅透過總體方案，高層就能夠決策一個產品要不要研發。

總體方案又分為以下四個部分：

方案概要說明；

總體流程圖；

應用架構圖；

多組織架構設計。

接下來，我們挨個進行闡述。

1。 方案概要說明

該部分內容主要說明產品的定位，以及MVP版本的範圍。這也是B端產品從0到1，產品方案最核心的部分。

方案概要說明包含以下三部分內容。

1）產品定位

定位決定成敗。大部分產品失敗的原因，都是沒有回答好以下三個問題：

比如，某位創業者希望做一款組織管理工具，但具體解決客戶什麼痛點，以及和釘釘、飛書這些成熟產品有什麼區別，都不能清晰表述。這樣的產品大機率會失敗。

在這個部分，我建議產品經理可以暢想一下：如果客戶寫來一封感謝信，訴說使用產品後給他們帶來的改變，那麼這封信的內容應該是怎樣的呢？

比如，對於一款針對養生服務連鎖門店的SaaS軟體，產品定位如下：

① 客戶是誰？

會員制的養生服務連鎖門店，根據XX諮詢報告，2020年全國約有700萬家養生服務連鎖門店。

② 痛點是什麼？

痛點主要是兩個。一是門店獲客差，二是門店運營管理效率低。

③ 為什麼選擇我們？

我們的產品是針對養生服務連鎖門店的SCRM，能夠針對性解決他們的痛點。更重要的是，我們的核心團隊有豐富的養生服務連鎖門店運營經驗，在門店數字化運營方面也有成功經驗。

客戶感謝信示例如下：

你好小李，

自從使用你們的產品後，我們的獲客成本大大降低，特別是省去了1000元/客的地推成本。同時，潛客進店成交率提升了20%，這得益於網際網路裂變帶來的更高質量的線索。

另外，使用了你們的產品後，由於運營資料都自動生成，門店行政人員的工作量大大減輕。更重要的是，由於可以在手機端實時檢視運營資料，公司的決策效率大大提升。以前月初才能分析上月運營情況，現在每天都可以開運營分析會議。感謝你們設計出這麼優秀的產品！

2）產品功能模組

在明確使用者痛點和產品價值後，我們還需要明確產品的功能模組。

首先需要明確MVP版本的功能模組。

MVP其實包含了兩個要點。一是“最小化”，即只做最核心的功能；二是“可行”，即使用者能夠使用起來，並且滿足他們最核心的需求。

曾經有創業者問我，如何判斷一個產品已經完成MVP階段？我個人認為就是客戶是否願意續約。之所以用“續約”而不是用“付費”，是因為擔心客戶付費以後，發現產品並不能很好的解決業務問題。

如果是SaaS產品，還建議區分標準化功能和定製化功能。如果是定製化功能，建議與標準化功能區隔開，避免對標準化功能造成干擾。比如，客戶希望在訂單上增加一個特殊邏輯，根據自定義公式自動生成商品價格。如果我們還沒有計劃對其進行標準化，就可以為這個公式設計單獨的頁面，並且預設商品價格計算不使用這個公式。

除了MVP版本的功能，我們還可以規劃後續版本的功能。

長遠考慮有利於提前設計好產品架構，降低後續迭代的成本。比如，如果未來計劃建設財務模組，或者對接成熟的財務系統，那麼就可以提前考慮“關賬”的概念：對於財務核算來說，本月是不允許隨意調整上月出庫訂單等業務資料的，否則會影響已經出具的上月財務報表。

當然，不能為了“確定性較低”的未來規劃，給研發造成過大負擔。這時候就比較考驗產品經理的系統架構能力和業務洞察力。在這個方面，推薦大家閱讀我的文章《成熟的B端產品經理，都有這個能力》。

2。 總體流程圖

B端產品往往需要支援多部門、多角色協同，因此對於業務鏈條較長的產品，需要繪製總體流程圖，以便於從整體上鳥瞰整個產品的業務流程，避免錯漏。

在範圍上，整體流程圖需要覆蓋所有關鍵流程和業務型別。在顆粒度上，整體流程圖主要描述關鍵步驟，不需要細化到具體功能甚至頁面。對於比較簡單的業務流程，比如客戶資訊管理，可以跳過總體流程圖，直接繪製詳細流程圖。

示例如下：

在上圖中，現結和落地結算是XX製造企業的兩種關鍵業務型別。

對於現結業務，出庫即可確認商品所有權轉移，因此根據實物出庫數量衝減系統庫存數量，並且生成財務結算單據即可。對於落地結算業務，出庫只是實物轉移到客戶現場，到月底時，需要根據客戶實際使用數量生成財務結算單據，並衝減系統庫存數量。上述流程圖正是描述了兩種關鍵業務的整體流程。

3。 系統架構圖

對於比較複雜的系統，我們還需要繪製系統架構圖。

特別是SaaS產品，合理的系統架構可以有效減少功能重複、避免資料混亂和降低系統擴充套件難度。反之，一旦在不合理的系統架構上搭建起頁面，特別是在擁有一定數量的企業客戶後，修改的成本可能會很高。

相對來說，自研產品的糾錯成本就低得多。畢竟只有一家企業在用，只要和業務部門協商好，推翻重建也是可行的。

系統架構設計的重點要做到低耦合、高複用。

所謂低耦合，是將功能按照業務相關性，分為多個系統應用。系統應用之間透過API進行互動。這樣，單個應用的升級，對其他應用的影響就小很多，從而提高了系統的敏捷性。比如，銷售訂單管理、倉庫管理和CRM就可以獨立為多個應用，並且在必要的時候分配給不同的產品經理負責。

當然，對於同一類應用，有時候我們還需要進一步拆分。比如，針對大客戶的銷售訂單管理，和針對小客戶的銷售訂單管理，由於需求差異較大，為了避免彼此影響而增加系統複雜度，可以考慮劃分為兩個獨立應用。畢竟，相對於研發成本，業務匹配程度和使用者使用成本更為重要。

所謂高複用，即將各個模組所共用的功能抽離出來，單獨形成一個系統應用。這樣，一方面確保了資訊來源的一致性，另一方面也簡化了系統架構，避免了重複開發。比如，客戶資訊在銷售訂單管理、CRM、TMS（運輸管理）等系統應用中都會用到，可以考慮合併成一個應用。

系統架構設計雖然沒有標準答案，但實際上不管是傳統的Oracle ERP系統，還是新興的各大電商、SaaS系統，都有非常成熟的架構設計。多研究競品，再結合實際情況進行適當的調整是系統架構設計的好方法。

示例如下：

在該示例中，品牌商系統主要面向年銷售額50億以上的品牌商，經銷商系統主要面向年銷售額2千萬到1億之間的經銷商。

考慮到前端業務需求差異較大且相互排斥，同時使用者對產品體驗和效率要求較高。為降低系統複雜度，採取了首先按企業型別劃分大版本，再按業務型別劃分功能模組的系統架構策略。而對於客戶資訊管理、商品資訊管理等基礎模組，考慮到業務需求差異較小且相互包容，同時也不是高頻操作，為了增加可複用性，採取了共用一套模組的系統架構策略。

4。 多組織架構設計

企業業務的開展，是基於多個部門的相互協同和相互監督的。當用戶在使用B端系統時，流程流轉、資料安全性都必須符合企業協同與管控的要求。這就需要我們設計好組織、角色和許可權功能。

對於存在多事業部或分子公司的大企業，還可能需要設計多組織架構。

示例如下。

某電器公司為擴大銷售規模，分別在A市和B市建立了分公司，各負責一個大區的銷售工作。為便於管理和激勵分公司團隊，公司決定兩個分公司獨立核算利潤，並根據實現的利潤進行分紅。

為支援兩個分公司的獨立核算，並防止資料洩露，該公司IT團隊決定分別給兩個分公司建立一個“利潤中心組織”。在“利潤中心組織”下面建立了相應的“角色”，並分配了相應的“功能”比如銷售訂單、發貨功能等等。最後，將相應的“角色”分別分配給了兩個分公司的員工。

四、結語

到這裡，B端產品方案的總體方案部分，就告一段落了。下一篇，我們接著闡述以下部分：

王戴明，微信公眾號：To B老人家，人人都是產品經理專欄作家，多年網際網路產品與資訊化管理經驗。

本文原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議