關于介紹 MVP （Minimum Viable Product）的文章有很多，但大多都是 C 端相關的，比如砍掉低頻複雜的高級功能，抓住核心流程，找到核心用戶驗證等等。總之，ToC 的 MVP 強調最多的是過渡——早晚有一天，會用新版本替代這個小垃圾。但是，ToB 的 MVP 不是這樣！

一、為什麼 ToB 行業不會拿 MVP 直接賣

在讨論這個問題之前先明确一下不同類型産品的商業模式。

1. ToC 的商業模式

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

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

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

2. ToB 的商業模式

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

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

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

3. 總結

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

二、定制開發為 ToB 産品擴張創造更多可能性

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

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

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

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

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

三、産品經理如何處理定制開發需求

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

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

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

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

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

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

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

2. （新）需求與現有系統的關系

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

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

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

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

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

4. 是否需要把新功能規劃到産品的下一代升級中

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

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

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

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

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

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

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

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

7. 極端情況

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

作者：産品路漫漫；産品路漫漫

本文由 @産品路漫漫 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

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

查看全部