B端产品经理如何定义产品的MVP？

工作越久，越能理解个人或企业精力或资源都是有限的，因此做任何面向市场的关键决策都需要尽可能降低不确定性，但即便采用科学的方法论也不能消灭选择的不确定性，因为商业本就充满了冒险。因此互联网产品才有了MVP理论，即起初提供一个最小可行性的产品，之后不断通过投向市场，通过倾听市场反馈，加深对市场和客户需求的理解，迭代和完善产品，最终达到产品与市场需求匹配，即PMF。

随着移动互联网发展趋于理性，做B端产品成为越来越多的产品经理的选择。B端本身具有决策层级多、不同客户需求认知层次不同、产品迭代周期长等问题，如果我们启动一个新的B端项目，作为B端产品经理应该如何定义产品的MVP呢？

拿校招举例

对于很多C端转B端的产品经理来讲，最担心的是没有B端经验。客观来讲，我们每个人找工作，本身就是将自身作为产品推销给企业（B端）的过程。因此可以以找工作为例，探讨定义B端产品MVP的方法。

拿小乐帝举例，读研期间由前端转产品经理，在某搜索公司PC浏览器部门实习半年，由于PC浏览器用户量见顶缩减投入，而没有转正名额。当时正值各家暑期实习，找暑期实习来不及了，浏览器部门实习经历又没有太多产品实战经验积累，此时的问题和需求是，如何利用手上的牌，拿到工作offer（将自己作为产品推销给企业并拿到订单）。

在实现拿到工作offer目标前期，有三条判断：

校招是长期过程，不需要在意一次面试成败，关键在于有助于迭代简历和面试，追求全局最优解
简历和面试是拿到offer的敲门砖，必须有一个基础的准备
大厂比小厂更适合没有经验应届生，且创业公司面试流程和反馈快，更有利于迭代简历和面试

在以上判断的基础上，在网上整理了历年产品经理面试问题，结合百家之长撰写了适合自身的答案，同时简历也找了一些模板范例有了基础版本，并且针对简历和面试问题花时间练习和背诵（MVP）。并且在校招正式开始前，开始投递一些小的创业公司，根据每次面试和反馈，不断调整了迭代简历和面试，拿到了某信息流产品offer，上线了第一家企业的PMF，同时逐步建立起投递大厂的信心和面试基础。

在此基础之上，开始扩大投递和研究触达渠道（1-N）。校招流程冗长且转化率低，产品经理校招通常会经历：网上申请—>HR筛选—>在线笔试—>群面—>一轮面试—>二轮面试…—>拿到offer。并非求职拿offer最佳选择，于是选择更短触达路径的触达渠道，成为实现目标的必要操作。当时研究的内推网私信功能，可以批量群发和快速触达招聘需求方，最终通过此渠道拿到3个产品offer。另外还有通过投递师妹实习单位拿到的offer，最终拿到的6个offer中，只有一个是通过正规校招拿到的。

MVP关键点

回顾整个过程不难发现，想做好B端产品MVP需要关注几个点：有基础demo、找到需求方快速最小成本验证（验证需求）、拿到订单（愿意付费）、扩大范围拿更多需求和订单。

B端产品不同于C端，通常客户能够提出来需求都是存在的，所以B端产品MVP更多是关注如何最小成本验证产品可行，并开始通过市场驱动产品迭代。

在做B端MVP时，起初访谈客户只是验证需求存在的阶段。在这个阶段，并不能知道应该做一款什么样的产品。在做产品访谈的过程中，不断收集客户的需求，通过梳理和抽象需求，逐步形成客户需求的本质和需要通过什么样的产品来实现。

此时应该进入demo阶段。demo并不应该拘泥于形式，可以是草图、原型图甚至简单的可交互产品，此阶段更多的是确认对需求和产品理解，是否与客户认知一致，能够真正解决客户问题，满足需求。这里需要注意，B端产品MVP并非一定要研发出产品来，而是有多种验证的方式。

B端产品MVP与C端产品MVP主要不同点在于，B端产品本身就能够售卖，而C端用户和商业变现通常是分开的。因此B端产品MVP阶段，并非验证完需求就结束了，还应该关注客户的付费意愿以及愿意付的费用多少，才能分别从需求侧和商业侧完成MVP的验证。

在实际B端产品定义MVP的过程中，需要基础demo，但也不应该局限于需求和方案本身，应该尽早引入商务或市场人员，协助寻找访谈客户或种子用户，以辅助验证方案和作为第一批试用客户，帮助产品进入需求驱动循环。在选择访谈客户或试用客户时，应该选择那些本身需求比较强且执行力较强的客户，才能加速后续迭代，不至于陷入推不动和产品停滞的尴尬。

完成以上步骤，再协调研发资源开发产品也不迟，前期充分的市场调研，永远比投入大量资源，结论却是“产品做的很好，就是没有需求”要好很多。

B端MVP实践

之前负责某推荐产品线，业务目标是收集站长流量，为后续商业化做铺垫。早期研发资源紧张，同时对站长群体需求了解有限。

为了解决站长需求了解问题，对大量站长产品做了调研，同时与做站长的同事做大量交流，此同事在各平台铺软文的方式，逐步拉起了对此推荐产品感兴趣的QQ群，积累起了种子用户。同时尽量复用之前推荐平台的模块，结合站长群体技术理解程度低的现实，将产品做的足够傻瓜式操作（仅通过点选就能快速给网站上线推荐功能），并且与种子用户交流方案开发前迭代方案（MVP）。

产品上线后，逐步发现下载到注册使用转化漏斗很低，由于网站域名能代表唯一ID，于是将注册/登录环节去掉，还能帮助站长自动创建推荐栏，整体转化率提升非常多（PMF）。

也逐步意识到随着PC互联网流量下降，站长大量转型，推荐产品仅能帮助网站流量降得“没那么快”，不能从根本上解决流量盘活和下降的问题，想推动推荐产品大规模落地，仅依靠推荐产品不够“刚需”。在此基础上，发现对于站长原创内容能力较低，内容采集产品对站长是刚需，于是进入自建采集工具或者与第三方合作的方式，出于成本考虑采用了后者，后续接连与主题开发者和采集工具开发者合作，实现了推荐产品大规模落地，如今落地网站已经达到10000+。

这其中选择合作伙伴落地推荐产品的过程中，某些个人开发者有正式工作，只能周末研发且情绪波动大，对开发进度把控有限，导致大量时间都在“等”，大大降低了迭代和推动效率。因此选择MVP试用客户和早期客户时，需要筛选业务需求紧迫，且执行力强的客户。

MVP是一个动态的过程，而不是结果。