关于介绍 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协议