关于介绍 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. 是否真正理解客户提出的（新）需求

既然是定制开发，那就代表之前我们没有遇到过此类问题，所以就需要我们再三确认是否真的搞懂客户提出的需求。