關于介紹 MVP （Minimum Viable Product）的文章有很多，但大多都是 C 端相關的，比如砍掉低頻復雜的高級功能，抓住核心流程，找到核心用戶驗證等等?？傊?span id="gkep7e9w" class="candidate-entity-word" data-gid="154438">ToC 的 MVP 強調最多的是過渡——早晚有一天，會用新版本替代這個小垃圾。但是，ToB 的 MVP 不是這樣！

一、為什么 ToB 行業(yè)不會拿 MVP 直接賣

在討論這個問題之前先明確一下不同類型產品的商業(yè)模式。

1. ToC 的商業(yè)模式

ToC 的全稱是To Customer，這些“Customer”不會為獲得使用權限而付費，更多是為“自己”而消費。這樣一來， ToC 產品作為“消費”的平臺，就會有理由向每次“消費”索要服務費。

這些服務費不可能從普通用戶身上獲取，因此就有了電商平臺的入駐費用、廣告主的廣告服務費等。平臺收取第三方傭金，然后為他們提供一定規(guī)模的“Customer”。

因此，從商業(yè)角度來看， ToC 產品有時候會為了商業(yè)目的，犧牲掉少部分用戶的使用體驗。

2. ToB 的商業(yè)模式

ToB 的全稱是“To Business”，即面向企業(yè)。企業(yè)往往擁有比較復雜的業(yè)務，且個性化很強，通常需要他們自掏腰包來解決自己的困難。這就會要求所購買的產品必須能夠滿足自己的全部需求，產品價格要跟產品價值（滿足需求）相匹配。

當 B 端客戶需要你的某個功能時，你可以編各種各樣的理由來搪塞他或者說正在開發(fā)中，但不可以說你沒有，否則會給人一種很不專業(yè)的感覺（側面反映產品不成熟、積累案例少、不能快速響應信息化建設。

所以對于大部分 ToB 產品，不存在直接拿 MVP 去賣的情況。因為客戶需要你能給出對某一項業(yè)務完整的解決方案（思路），哪怕是低保真產品原型或 PPT ，都比一個沒做好的 MVP 更具說服力。

3. 總結

B 端客戶需要完整、成熟的業(yè)務解決方案，而不是暫緩燃眉之急的最小可行性“工具”，但這并不意味著ToB 產品沒有驗證產品上市可行性的解決方案。

二、定制開發(fā)為 ToB 產品擴張創(chuàng)造更多可能性

從軟件開發(fā)角度，MVP 在某種程度上代表一個產品未來的可能性，即：通過前期“試驗”，在下一個版本我們要做出哪些改變以達到效益最大化。

對于 ToC 產品，僅僅需要列出用戶使用數據就可以對某部分功能做出修改或刪除的決定。但 ToB行業(yè)不是這樣，哪怕某個功能只有一個客戶要用（前提是愿意為此付費），你都得把它做出來。這樣做的目的不僅僅是“以客戶為中心”，大多數情況下，是因為我們不敢保證不會有第二家客戶會用到！這才是最重要的原因。

做ToB 軟件開發(fā)，或多或少都會遇到需要定制開發(fā)的客戶，因為沒有哪款產品能做到100%適合一個公司全部的業(yè)務內容。在這個前提下，我們可以設想一個場景：

A公司經過層層篩選，購買了公司的某款產品，但因為自己的某項特殊業(yè)務，需要額外定制一個F1 功能；B公司購買產品后需要我們提供一個 F2 功能；以此類推……每積累的一個客戶，我們都會由客戶付費完成一部分產品升級工作，并且這些升級是由真實業(yè)務場景支撐的，而不是由產品團隊空想出來的。

在這個過程中，我們不止會遇到需要簡單升級的需求，還會遇到信任我們的客戶，交由我們完成部分與現有業(yè)務系統(tǒng)關聯性不是很強的產品設計。這就是標題所說的“可能性”，每個客戶的每次定制開發(fā)都有可能成為公司未來將要布局的一條產品線。

三、產品經理如何處理定制開發(fā)需求

回答這個問題前，需要說明一下ToB 產品經理當前的處境：

• 很少有權威性的產品專家（不懂業(yè)務）；
• 在商務溝通方面沒有話語權；
• 在產品線規(guī)劃方面缺少話語權；
• 與市場（銷售、售前）的距離太大……

上面說的處境問題只是我臨時想到的，有時間我會詳細總結。在這里說的意思是：面對定制開發(fā)需求，產品經理只能接坑，不能決定“不做什么”（總監(jiān)級、Boss 級除外）。能隨時隨地與客戶（需求方）面對面交流是產品經理所能奢求的最大福分。

既然暴風雨總要來臨，那就說一下我們力所能及可以掌控的事情：

1. 是否真正理解客戶提出的（新）需求

既然是定制開發(fā)，那就代表之前我們沒有遇到過此類問題，所以就需要我們再三確認是否真的搞懂客戶提出的需求。

如果沒有，那就反復追問；如果覺得自己理解了！注意！要給客戶粑粑再講一遍，詢問他們是否理解的正確，這個很關鍵！必要的時候甚至需要雙方簽署更細致的需求確認書。

2. （新）需求與現有系統(tǒng)的關系

理解需求以后，就要付諸行動開始產品設計。在設計之前，產品經理需要與開發(fā)人員進行一次簡單的溝通，大致還原一下需求的業(yè)務場景，以及自己打算如何實現。在溝通過程中，產品經理需要講出該項需求涉及的數據類型和內容，哪些地方會用到新產生的數據，新內容需要從哪些地方調用。接著開發(fā)人員會提出自己的疑問，最終雙方會把數據關系理清楚。

除了數據關系，還有流程、權限方面的問題需要理順，但這些屬于產品的分內之事，前期一般不需要勞駕開發(fā)人員。

3. （新）需求的實現是否會影響現有系統(tǒng)的運行

把關系問題理順意味著婆婆接受了新媳婦，但婆媳之間能不能友好相處，這就屬于另一個問題。在探討這個問題前，產品經理需要準備已經畫好的原型圖或需求文檔，再次叫上開發(fā)人員。

這次除了討論數據關系、流程權限等問題，最重要的是確定加上這個功能會不會對現有系統(tǒng)有影響：需不需要動原來已經封裝好的代碼？會不會影響原有系統(tǒng)性能（數據計算效率、響應速度等）？……有時候甚至會考慮用新技術實現新功能，當需要切換不同前端界面時，如何處理新舊之間的跳轉問題等等。

4. 是否需要把新功能規(guī)劃到產品的下一代升級中

到此為止，新需求的定制開發(fā)肯定是沒問題了，剩下的工作交給開發(fā)哥哥們就可以。但產品經理仍然需要思考：是否需要把這次定制開發(fā)的內容規(guī)劃到下一版本的升級優(yōu)化中？也就是探討新功能的行業(yè)通用性、客戶接受程度，以及用戶的學習成本等。

5. 新功能能否獨立成一個單元模塊

對于小規(guī)模的定制開發(fā)，產品經理需要考慮是否要放在下一版本的升級任務中；但對于較大規(guī)模的定制開發(fā)，產品經理就得考慮，是否要完善或直接封裝該功能模塊，使其成為一個產品單元。

這種規(guī)劃是出于產品銷售考慮的，大部分ToB 產品都有按功能模塊售賣這類付費選擇，也就是說，每個單元模塊（甚至單個功能）都有其相應價格，客戶需要哪個就買哪個。獨立成單元模塊意味著，不僅有客戶為我們的“探索”付費，我們還能把探索的成果轉手賣出去；這與產品升級是有區(qū)別的，因為不管產品怎么升級，其銷售價格往往是不會變的。

如果該單元模塊具備一定的行業(yè)屬性，還會有利于市場和銷售部門進行推廣宣傳。

6. 新功能能否獨立成一條產品線

客戶選擇我們進行定制開發(fā)的理由有很多，當這個理由是信任時，客戶可能會讓我們做一些之前沒有涉足過的業(yè)務系統(tǒng)（其實他們只是想省錢~），這類情形就非常有利于規(guī)劃新的產品線。

比方說我們公司是做財務管理軟件的，客戶信（xiang）任（sheng）我（qian）們，所以希望我們幫助他們開發(fā)一個用于合同財務管理的功能模塊，表面上我們好像做著很吃力，但實際上這個定制開發(fā)極大地降低了我們切入新領域的風險。

7. 極端情況

還有一種情況，客戶的定制開發(fā)項目完全不具備行業(yè)通用性，調研后也沒有客戶愿意接受。坦白說，就是由某個傻X暈頭暈腦地簽下，然后不得不做出來的……這種情況就給產品經理和運維人員（尤其是后者）增加了很大的負擔，因為涉及到產品版本的管理，每次優(yōu)化升級都得單獨給他們發(fā)版……產品經理能做的就是，多陪陪負責這家客戶的運維GG~

作者：產品路漫漫；微信公眾號：產品路漫漫

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

題圖來自Unsplash，基于CC0協(xié)議