差异化的 ToB 产品

这几年做 B端产品，也经历了很多有意思的事情。

前几年机缘巧合，认识了一个在微博做桌面端的产品同事老郭，自从去年中旬他回到成都后，就一直在找合适的机会。昨天他刚好找到一个新的机会，因为这件事和他聊了一会，我也顺带复盘了自己在 B 端产品的经验，梳理出来和大家进行分享。

ToB 业务和 ToC 业务有一个巨大的区别——用户需求差异巨大。

用户需求

很多出身于 C 端的产品同学都能算作是半个运营，优化用户体验，抠设计交互细节，支撑运营活动，为了获取流量并进行转化着实消耗了不少脑细胞。相比之下 B 端产品经理思考的问题的方法有所不同，用户量级更小、相对更加垂直，用户类型通常是“组织群体”，包括决策者、管理者、普通员工。

和一般的“用户”角色相比较，B 端产品更在乎“客户”。有时候在满足客户需求的情况下，甚至可以完全无视用户需求。比如我们设计了一款企业内部使用的 HR 产品，目标用户当然是企业中的各位人力同事（用户），但最终决定是否采用这款产品的决策人可能是 HRD，亦或是某个业务线负责人或 VP（客户），哪怕满足了无数一线同事的真实需求，但 HRD 对于数据可视化的不满意可能让所有努力付诸流水。

而如何去收集客户的真实需求呢？除去相关的需求分析方法，对于行业或者角色的洞察力以外，了解相关人的考核指标（KPI 或OKR）并进行分析也是一个好方法。

还是拿上面的 HR 系统举例，如果我们能设计一个大屏来对企业内部各种人力资源与效率进行统计与展示，HRD 可以将其中的数据进行导出或截屏放在自己的述职报告，并在高管闭门会中进行讲解，可能就刚好解决了她的 KPI 痛点。

客户需求

我记得有一次去北京开会，刚好约了老郭吃饭，饭桌上老郭和我大吐工作苦水，作为一个桌面端产品经理，经手了很多出于审查需求的功能与模块（比如在某些时间段不允许修改头像或昵称），虽然这些功能无法为真实的用户提供价值，也无法为微博带来某些数据增长或收入的转化，但客户却比较满意。

我们都知道做产品分析需求的时候要尽可能分析到精确的个体或者人群，而某些时候产品经理可能压根见不到对应的真实客户，这时候就要花费大量的精力去揣摩对方的真实想法，如果揣摩错了，可能会导致产生一些新的问题。

比如，真的不能修改头像和昵称吗？这个需求是客户提出的么？

之前我负责过一次项目的招投标，借机也对公司的内部决策链有了些许的理解。我们原本想买一个产品的推广方案，由我所在的业务线发起了采购需求，随着采购的项目进度进行，一个我从未听说过由 CEO，法务 Leader，财务 Leader，市场 Leader 等各种不同部门大佬组成的“采购委员会”就出现了，由他们来决定这个方案是否可以通过，有的大佬还具有一票否决权。

这时对于那些参与投标的营销服务商来说，能否及时了解到目标客户的决策链，并进行针对性的分析就显得十分重要。有几个人我认为还不错的方案都被决策链中的大佬以意想不到的方案所婉拒了，这也显得怪可惜的。

当然对于大部分企业来说，增加收入，降低成本，提升效率永远是核心考察点，这三件事永远也躲不掉。

销售需求

随着 B 端产品的设计研发到上线，一个更真实的问题就出现了，如何动员销售同事帮我们把产品卖出去？如何让他们心甘情愿的帮我把产品卖出去？如何让他们在承担多个产品销售任务的时候最先想到我的产品？

同样的两个产品，产品 A 包含众多技术名词，没有演示 Demo 和产品说明书，使用和部署环节都会出现无数意想不到的 Bug 和问题，而产品 B 倒是简单轻量易于部署与安装，用户看到 Demo 的时候甚至还要拍大腿连连称赞，换做这个销售是我，我也更愿意卖 B 产品。

任何 B 端产品在设计的时候，都需要考虑销售和客服需求，之前每一次设计的产品发版更新后，我都会组织对口的销售业务线同事来做一次 release 沟通会，一方面帮助他们快速了解新版本的特性和功能优化，一方面收集他们在一线收集到的用户需求与吐槽点，此外还能增进大家的关系，在我看来这一点简直不要太划算。

当然，不同公司对于销售的考核方法也不甚相同。有的公司规定客户签完合同付完款就算销售业绩，而有的公司则规定客户真实打款完成后才作为销售业绩，对于销售一线的同事来说，他们的核心目的就是为了搞钱，如何帮助他们更快更好更简单的搞钱，并设计对应的策略优化产品，甚至说服业务线 Leader 为销售同事提供更好的激励，也是需要 B 端产品经理考虑的一点。