滴滴产品总监：资本寒冬！如何通过To B业务拯救现金流？

演讲者|叶科技(滴滴出行企业事业部产品总监)

本文经混沌研习社(微信公众号：dfscx2014)授权转载，研习社是一所线上商学院，致力为创业公司培养具有互联网思维和全球化视野的创新人才。

我之前做过很多 to B的业务，包括在IBM做咨询，以及在百度做大客户运营。这个过程中我经历了从传统IT项目到互联网产品设计以及到现在的互联网+的过程。

基于各种角色的经历，我和大家分享一下to B的企业级应用以及to C的个人应用的产品需求区别，以及怎样更好地做 to B业务。

与2C业务不同

2B业务的购买方和使用方并非同一人

其购买决策链条更长、业务系统更复杂

基于购买方(客户)和使用者(用户)这两个角色的不同需求，是导致2B跟2C业务需求捕捉差异较大的根本原因。

2C业务不管是免费的还是付费的，通常购买者和使用者是同一个人，在决策方面个人喜好起决定性作用。

比如说打车，你直接到应用商店下载一个滴滴出行，用手机注册一下就可以用。整个决策链会非常短，并且你有可能随时可能换成另外一个打车软件。

对于2B业务来讲，他有一个购买决策的过程，这个过程会比较复杂。企业内部各个部门包括采购、财务、法务、行政、IT，每个部门看的东西不一样，你要完成整个采购极有可能要涉及到多个部门的协调。

另外一点就是B和C的需求重点会不一样，大家都知道C端APP我最关心的是价格。从体验上来讲，哪个做得好，我就喜欢用哪一个。从传统的MSN到QQ到微信都是这样一个过程。

对于B端的产品来讲，对于费用还是一样敏感，因为企业天然会注重成本。

除此之外，企业会看这个产品能帮我解决什么问题，能帮我做哪些管理，能给我员工实现哪些功能，他里面有服务的层面。

再次才是服务体验好不好，产品设计的操作性友好不友好。

从这个方面来讲考虑的因素会多，导致B的产品也会比较复杂。在产品设计方面，除了有一个前台APP以外，企业版产品还需要设计一个管理后台。

销售反馈的客户需求可能失真

让客户自己提解决方案

产品经理专注解决用户真实痛点

那么，我们有哪些途径来分析和挖掘2B业务的需求呢?

第一，基于行业发展和业务变革带来的需求。

比如说企业云服务，现在有华为企业云、云之家这些传统做ERP都往云端去走，自己不用打理那些IT的基本设施。

最早大家会担心它的安全，当整个技术成熟以后，这样的担忧就很少了，于是很多业务就会往这边迁移。

第二，拜访客户获取的需求反馈。

如果产品已经上线了，可以通过拜访用户得知使用效果，有哪些改进，下一个版本哪些迭代或者新功能可以推广。

还要获取的信息就是竞品功能，有一些用户其实已经在用你的竞品，你要去了解，他们在用什么竞品，并且调研选择竞品的原因，竞品哪些功能比较好。

第三，产品经理一定要亲自去访谈客户，才能得到一手的资料。销售那边反馈过来的信息会有很多问题。要注意这样几点：

1、产品经理要以倾听为主，让客户多说，倾听客户最原始的声音。

2、产品经理要抛开产品的售卖逻辑，关注产品到底能解决客户什么问题，特别是痛点，越痛价值越高。

3、得到需求后，不要立即反馈解决方案，因为可能阻挡客户真实想法。让客户先提建议方案。

4、一定是要平衡用户跟客户对产品的需求，因为购买者(客户)和使用者(用户)的角度不一样，所需要的功能必然不同。有冲突的时候，可以遵循这样的原则：管理类需求以客户意见为主，功能和体验类需求，以用户需求为主。

第四，调查问卷获得的用户需求。

这是比较常用的方式，强调几点：

1、有针对性的专项调研，不要泛泛做一个特别大的问卷调查，很难得到用户真实的需求。比如滴滴2B业务中，开发票就是一个专项功能，聚焦开发票做调研，更容易收集到有效反馈。

2、不要问客户/用户你要不要这个功能。

如果问卷问：什么功能你会需要吗或者你需要以下哪几种功能?通常反馈效果不好。因为产品经理设计的功能不会特别偏或者方向错误，你提出来这个问题，用户肯定会说要。

3、用排序或者单选，不要给多项选择

排序或者多选，能让你知道真正的解决方案应该选哪一个。如果是多选，他只要看差不多的，都会选，你很难分辨哪些是他们最想要的，哪些是一般想要的。

第五，通过活跃度发布验证需求。

互联网里边越来越多把活跃度发布作为测试工具或者作为一种新产品发布、反馈收集的一个通道。这个更多适用于一些新功能的推广测试。

我们常见是AB测试。我做两类，一类是新功能上线，另外是不动还是用老功能看看是不是有相关指标的改善。这个对于极早获取用户一些意见反馈完善现有的功能是非常好的。

比如滴滴出行里边，本身是支持通过不同城市、时间段去定向发布新产品的，我在北京是一键打A产品，在上海是一键打B产品，这个不同服务可以在不同区域试一下效果如何。通过这种活跃度发布会获取不同区域对不同服务的一个反映。

不能为签单而一味满足个别需求

要看到表面需求背后的真实需求

全盘照搬竞品功能，风险很大

上面说的这些方法里，我们往往会犯一些错误，主要讲几点：

第一，个别需求和普遍需求 、表面需求和真实需求的陷阱。

我们经常碰到说销售出差回来某某客户需要这些功能非常紧急，只要这个需求满足了他就能签单。

对于这种如果我们直接就说OK，做了以后能签个大单，往往会触发一个问题：表面需求跟真实需求，个别需求跟普遍需求的矛盾。

举个案例，我们滴滴企业版做的过程中，最早做了企业支付，也就企业开账户充钱，他的员工可以用企业账户里面的钱去打车，这样就特别好，报销不用走财务审核了。

我们后来发现，第一批客户签进来以后，后面并没有大量的其他客户进来。我们派销售拜访客户以后，他们反馈说，让企业充值，第一，占用资金，第二，财务走流程特别麻烦。

如果滴滴出行像信用卡一样先授信，按月结算，这种我们就很快能签了。挺有道理的，如果碍于资金占用，滴滴可以先授信。

把授信这个功能做完以后，发现提出这个需求的客户，并没有因为这个功能的优化而进来。

再去访谈时，客户说还有风险问题。他觉得没有任何限制，公司的钱直接让员工花掉了，财务风险不可把控。这个跟授信是没有关系的。

最后我们的解决方案是，做了一些支付限额，通过一些规则去限制你，比如说时间、地点、额度、车型，去控制你用车的数量、用车的行为，这个对我们来讲一个非常好的反思。

所以我们的解法是，如果销售反馈的需求，要让销售用更多客户来证明，单一客户的需求再急也不能马上做，一定要确定这个是不是普遍需求和真实需求。

第二，竞品的功能能不能照搬?

我们经常说最好方式是我做一块新业务，看看竞争对手是怎么做的，我甚至把它全盘照抄过来，抄的过程中我改一些东西甚至优化一下。

从产品角度来讲，照搬其实是个问题。竞品不是所有的功能客户都需要，很多竞品需求的产品功能有可能是错误的，如果照抄，你也会同样犯这个错误。

解法就是说，我们一定要了解，什么样的功能他为什么这样做，现在使用效果是如何。这样你才会更了解客户需要什么，才有可能想出比竞品更好的解决方案。