在B端產(chǎn)品的設計和開發(fā)過程中，產(chǎn)品經(jīng)理面臨的挑戰(zhàn)是如何從零開始構(gòu)建一個既滿足市場需求又具備可擴展性的產(chǎn)品。王戴明在其文章中深入探討了B端產(chǎn)品方案的關(guān)鍵要點，包括聚焦重點、究極精神和長遠規(guī)劃，并提出了一個詳盡的產(chǎn)品方案結(jié)構(gòu)。這些寶貴的經(jīng)驗和策略對于任何希望在B端市場取得成功的產(chǎn)品經(jīng)理來說都是必讀的內(nèi)容。

一、產(chǎn)品方案的要點

一般情況下，從0到1的B端產(chǎn)品往往聚焦于企業(yè)少數(shù)幾個痛點，同時具備很強的可落地性。

如果是商業(yè)化產(chǎn)品，還必須長遠規(guī)劃，以減少后期迭代的成本。因此，B端產(chǎn)品方案主要有以下三個要點：

1.聚焦重點

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

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

聚焦重點也是敬畏市場的表現(xiàn)。在互聯(lián)網(wǎng)浪潮下，不管是創(chuàng)業(yè)公司，還是客戶自己，往往都在一邊探索一邊調(diào)整。快速推出MVP版本，再根據(jù)用戶反饋迅速迭代，是產(chǎn)品創(chuàng)新的最佳實踐。

2.究竟精神

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

所謂相信用戶，是相信當用戶提出一個需求，它確實反映了用戶存在一個困擾；

所謂不要相信用戶，是不要指望用戶會透徹分析自己的需求，而他們所提出的方案往往也是“頭疼醫(yī)頭、腳疼醫(yī)腳”。

這并不能歸罪于用戶，畢竟，對他們來說，達成業(yè)務目標才是最重要的事，系統(tǒng)只是輔助手段，不值得花費太多時間深入思考。

關(guān)于要不要聽用戶的，海底撈創(chuàng)始人張勇有一段經(jīng)典的闡述：“消費者說海底撈不好吃，其實可能是嫌價格貴。我老婆說我回家晚，可能是我對她關(guān)心不夠。如果我信我老婆的話，每天都在家待著，我相信我老婆會更討厭我?！?/p>

在制作產(chǎn)品方案時，我們必須洞察用戶需求，找到需求背后的真相。而這種洞察能力，很大程度上依賴于我們的究竟精神。

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

產(chǎn)品經(jīng)理：為什么訂單沒有付款，就不允許發(fā)貨呢？

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

產(chǎn)品經(jīng)理：那么長期合作的客戶呢？是不是就可以不付款也允許發(fā)貨呢？

用戶：要分情況，有些客戶可以付一部分款就發(fā)貨，有些客戶可以不付款先發(fā)貨。

產(chǎn)品經(jīng)理：什么樣的客戶可以付一部分款就發(fā)貨，什么樣的客戶可以不付款先發(fā)貨呢？

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

如果一個方案沒有經(jīng)過嚴謹梳理，在落地過程中就可能出現(xiàn)問題。比如，在上述例子中，如果直接根據(jù)用戶需求設計產(chǎn)品，在后期很可能就需要對方案進行大改。

值得一提的是，B端產(chǎn)品經(jīng)理的工作非常依賴冷靜思考。

如果外界給產(chǎn)品經(jīng)理施加了過大壓力，就可能導致產(chǎn)品經(jīng)理“動作變形”，從而做出錯誤決策。

作為產(chǎn)品經(jīng)理，我們要警惕過大的外部壓力，時刻提醒自己：沒有慎重思考過的產(chǎn)品，不值得浪費寶貴資源。

3.長遠規(guī)劃

如果我們設計的是商業(yè)化產(chǎn)品，則必須注重長遠規(guī)劃。

從0到1的商業(yè)化產(chǎn)品，客群規(guī)模有一個從小到大的過程。當客戶和功能數(shù)量都較少時，如果缺乏規(guī)劃，產(chǎn)品就很容易野蠻生長。

比如，買贈是消費品行業(yè)常用的促銷手段。在某些情況下，贈品需要關(guān)聯(lián)到主品，比如買5瓶大可樂送1瓶小可樂。

產(chǎn)品經(jīng)理為了設計和操作方便，可能選擇直接在訂單行上新增兩個字段，體現(xiàn)贈品名稱和數(shù)量。

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

1）需要管理贈品發(fā)貨；

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

3）需要和ERP系統(tǒng)集成。

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

因此，作為商業(yè)化產(chǎn)品經(jīng)理，不能夠只盯著眼前的需求，而要放眼長遠，做全面的考慮。

二、產(chǎn)品方案的結(jié)構(gòu)

如果只是針對一小塊功能的迭代，產(chǎn)品方案要求相對簡單。重點說清楚1）解決什么問題；2）解決問題的方案；3）頁面設計和邏輯即可。

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

我建議的產(chǎn)品方案結(jié)構(gòu)如下：

1、總體方案

2、詳細方案

3、管理報表方案

4、集成方案

5、用戶期望滿足

在總體方案部分，需要對產(chǎn)品價值、整體方案和總體架構(gòu)進行說明，一方面便于給公司和客戶高層進行匯報；另一方面也便于產(chǎn)品經(jīng)理們了解彼此的工作，提高溝通與協(xié)作效率。

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

對于B端產(chǎn)品，管理報表雖然功能相對簡單，但反映了管理者的需求，需要和業(yè)務功能一并設計。否則，一旦后期發(fā)現(xiàn)產(chǎn)品不能支撐管理報表需求，就很可能導致返工。

對于針對大企業(yè)的B端產(chǎn)品，往往會涉及到系統(tǒng)集成。系統(tǒng)集成反映了上下游業(yè)務的需求，也需要盡早規(guī)劃和設計。

最后，產(chǎn)品對用戶期望的滿足程度，往往決定了用戶對產(chǎn)品的滿意度。即便在MVP階段無法滿足所有需求，也需要納入長期規(guī)劃。

三、總體方案

總體方案是整個產(chǎn)品方案中最精華的部分。理論上，僅僅通過總體方案，高層就能夠決策一個產(chǎn)品要不要研發(fā)。

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

1）方案概要說明

2）總體流程圖

3）應用架構(gòu)圖

4）多組織架構(gòu)設計

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

1.方案概要說明

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

方案概要說明包含以下三部分內(nèi)容：

1）產(chǎn)品定位：

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

客戶是誰？

痛點是什么？

客戶為什么選擇我們？

比如，某位創(chuàng)業(yè)者希望做一款組織管理工具，但具體解決客戶什么痛點，以及和釘釘、飛書這些成熟產(chǎn)品有什么區(qū)別，都不能清晰表述。這樣的產(chǎn)品大概率會失敗。

在這個部分，我建議產(chǎn)品經(jīng)理可以暢想一下：如果客戶寫來一封感謝信，訴說使用產(chǎn)品后給他們帶來的改變，那么這封信的內(nèi)容應該是怎樣的呢？

比如，對于一款針對養(yǎng)生服務連鎖門店的SaaS軟件，產(chǎn)品定位如下：

客戶是誰？會員制的養(yǎng)生服務連鎖門店，根據(jù)XX咨詢報告，2020年全國約有700萬家養(yǎng)生服務連鎖門店。

痛點是什么？

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

為什么選擇我們？

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

客戶感謝信示例如下：

你好小李，自從使用你們的產(chǎn)品后，我們的獲客成本大大降低，特別是省去了1000元/客的地推成本。同時，潛客進店成交率提升了20%，這得益于互聯(lián)網(wǎng)裂變帶來的更高質(zhì)量的線索。

另外，使用了你們的產(chǎn)品后，由于運營數(shù)據(jù)都自動生成，門店行政人員的工作量大大減輕。更重要的是，由于可以在手機端實時查看運營數(shù)據(jù)，公司的決策效率大大提升。以前月初才能分析上月運營情況，現(xiàn)在每天都可以開運營分析會議。感謝你們設計出這么優(yōu)秀的產(chǎn)品！

2）產(chǎn)品功能模塊：

在明確用戶痛點和產(chǎn)品價值后，我們還需要明確產(chǎn)品的功能模塊。

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

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

曾經(jīng)有創(chuàng)業(yè)者問我，如何判斷一個產(chǎn)品已經(jīng)完成MVP階段？

我個人認為就是客戶是否愿意續(xù)約。之所以用“續(xù)約”而不是用“付費”，是因為擔心客戶付費以后，發(fā)現(xiàn)產(chǎn)品并不能很好的解決業(yè)務問題。

如果是SaaS產(chǎn)品，還建議區(qū)分標準化功能和定制化功能。

如果是定制化功能，建議與標準化功能區(qū)隔開，避免對標準化功能造成干擾。

比如，客戶希望在訂單上增加一個特殊邏輯，根據(jù)自定義公式自動生成商品價格。如果我們還沒有計劃對其進行標準化，就可以為這個公式設計單獨的頁面，并且默認商品價格計算不使用這個公式。

除了MVP版本的功能，我們還可以規(guī)劃后續(xù)版本的功能。

長遠考慮有利于提前設計好產(chǎn)品架構(gòu)，降低后續(xù)迭代的成本。

比如，如果未來計劃建設財務模塊，或者對接成熟的財務系統(tǒng)，那么就可以提前考慮“關(guān)賬”的概念：對于財務核算來說，本月是不允許隨意調(diào)整上月出庫訂單等業(yè)務數(shù)據(jù)的，否則會影響已經(jīng)出具的上月財務報表。

當然，不能為了“確定性較低”的未來規(guī)劃，給研發(fā)造成過大負擔。

這時候就比較考驗產(chǎn)品經(jīng)理的系統(tǒng)架構(gòu)能力和業(yè)務洞察力。在這個方面，推薦大家閱讀我的文章《成熟的B端產(chǎn)品經(jīng)理，都有這個能力》。

2、總體流程圖

B端產(chǎn)品往往需要支持多部門、多角色協(xié)同，因此對于業(yè)務鏈條較長的產(chǎn)品，需要繪制總體流程圖，以便于從整體上鳥瞰整個產(chǎn)品的業(yè)務流程，避免錯漏。

在范圍上，整體流程圖需要覆蓋所有關(guān)鍵流程和業(yè)務類型。

在顆粒度上，整體流程圖主要描述關(guān)鍵步驟，不需要細化到具體功能甚至頁面。對于比較簡單的業(yè)務流程，比如客戶信息管理，可以跳過總體流程圖，直接繪制詳細流程圖。

示例如下：

在上圖中，現(xiàn)結(jié)和落地結(jié)算是XX制造企業(yè)的兩種關(guān)鍵業(yè)務類型。

對于現(xiàn)結(jié)業(yè)務，出庫即可確認商品所有權(quán)轉(zhuǎn)移，因此根據(jù)實物出庫數(shù)量沖減系統(tǒng)庫存數(shù)量，并且生成財務結(jié)算單據(jù)即可。

對于落地結(jié)算業(yè)務，出庫只是實物轉(zhuǎn)移到客戶現(xiàn)場，到月底時，需要根據(jù)客戶實際使用數(shù)量生成財務結(jié)算單據(jù)，并沖減系統(tǒng)庫存數(shù)量。

上述流程圖正是描述了兩種關(guān)鍵業(yè)務的整體流程。

3、系統(tǒng)架構(gòu)圖

對于比較復雜的系統(tǒng)，我們還需要繪制系統(tǒng)架構(gòu)圖。

特別是SaaS產(chǎn)品，合理的系統(tǒng)架構(gòu)可以有效減少功能重復、避免數(shù)據(jù)混亂和降低系統(tǒng)擴展難度。

反之，一旦在不合理的系統(tǒng)架構(gòu)上搭建起頁面，特別是在擁有一定數(shù)量的企業(yè)客戶后，修改的成本可能會很高。

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

系統(tǒng)架構(gòu)設計的重點要做到低耦合、高復用。

所謂低耦合，是將功能按照業(yè)務相關(guān)性，分為多個系統(tǒng)應用。系統(tǒng)應用之間通過API進行交互。

這樣，單個應用的升級，對其他應用的影響就小很多，從而提高了系統(tǒng)的敏捷性。

比如，銷售訂單管理、倉庫管理和CRM就可以獨立為多個應用，并且在必要的時候分配給不同的產(chǎn)品經(jīng)理負責。

當然，對于同一類應用，有時候我們還需要進一步拆分。

比如，針對大客戶的銷售訂單管理，和針對小客戶的銷售訂單管理，由于需求差異較大，為了避免彼此影響而增加系統(tǒng)復雜度，可以考慮劃分為兩個獨立應用。

畢竟，相對于研發(fā)成本，業(yè)務匹配程度和用戶使用成本更為重要。

所謂高復用，即將各個模塊所共用的功能抽離出來，單獨形成一個系統(tǒng)應用。

這樣，一方面確保了信息來源的一致性，另一方面也簡化了系統(tǒng)架構(gòu)，避免了重復開發(fā)。

比如，客戶信息在銷售訂單管理、CRM、TMS（運輸管理）等系統(tǒng)應用中都會用到，可以考慮合并成一個應用。

系統(tǒng)架構(gòu)設計雖然沒有標準答案，但實際上不管是傳統(tǒng)的Oracle ERP系統(tǒng)，還是新興的各大電商、SaaS系統(tǒng)，都有非常成熟的架構(gòu)設計。

多研究競品，再結(jié)合實際情況進行適當?shù)恼{(diào)整是系統(tǒng)架構(gòu)設計的好方法。示例如下：

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

考慮到前端業(yè)務需求差異較大且相互排斥，同時用戶對產(chǎn)品體驗和效率要求較高。為降低系統(tǒng)復雜度，采取了首先按企業(yè)類型劃分大版本，再按業(yè)務類型劃分功能模塊的系統(tǒng)架構(gòu)策略。

而對于客戶信息管理、商品信息管理等基礎(chǔ)模塊，考慮到業(yè)務需求差異較小且相互包容，同時也不是高頻操作，為了增加可復用性，采取了共用一套模塊的系統(tǒng)架構(gòu)策略。

4、多組織架構(gòu)設計

企業(yè)業(yè)務的開展，是基于多個部門的相互協(xié)同和相互監(jiān)督的。

當用戶在使用B端系統(tǒng)時，流程流轉(zhuǎn)、數(shù)據(jù)安全性都必須符合企業(yè)協(xié)同與管控的要求。這就需要我們設計好組織、角色和權(quán)限功能。

對于存在多事業(yè)部或分子公司的大企業(yè)，還可能需要設計多組織架構(gòu)。

示例如下：

某電器公司為擴大銷售規(guī)模，分別在A市和B市建立了分公司，各負責一個大區(qū)的銷售工作。為便于管理和激勵分公司團隊，公司決定兩個分公司獨立核算利潤，并根據(jù)實現(xiàn)的利潤進行分紅。

為支持兩個分公司的獨立核算，并防止數(shù)據(jù)泄露，該公司IT團隊決定分別給兩個分公司建立一個“利潤中心組織”。在“利潤中心組織”下面建立了相應的“角色”，并分配了相應的“功能”比如銷售訂單、發(fā)貨功能等等。最后，將相應的“角色”分別分配給了兩個分公司的員工。

四、結(jié)語

到這里，B端產(chǎn)品方案的總體方案部分就告一段落了。大家可以關(guān)注我的公眾號，我抽時間再講一講詳細方案怎么做。

最后，一份好的方案文檔也是面試大殺器，很多產(chǎn)品經(jīng)理就是通過提交方案文檔來獲得面試機會：