編輯導語：在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産品，則必須從更高、更全面的視角進行方案梳理。

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

1. 總體方案；
2. 詳細方案；
3. 管理報表方案；
4. 集成方案；
5. 用戶期望滿足。

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

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

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

對于針對大企業的B端産品，往往會涉及到系統集成。系統集成反映了上下遊業務的需求，也需要盡早規劃和設計。

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

三、總體方案

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

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

1. 方案概要說明；
2. 總體流程圖；
3. 應用架構圖；
4. 多組織架構設計。

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

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 協議

,

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

查看全部