本周小乐帝约了做语音识别的小伙伴，交流最近做AI产品的一些想法。聊天后发现To B业务的公司有几种驱动模式很有趣。典型的驱动模式有：技术驱动、市场（销售）驱动、产品驱动。
技术驱动典型的如百度，本周陆奇被采访也提到了百度技术强势，产品太弱的问题，缺少产品基因直接导致了百度在BAT三分天下的格局中掉队；市场（销售）驱动如小伙伴所在某公司，销售谈下单子，客户要啥做啥，销售与产品研发职能和KPI隔离，最终做出的产品漏洞百出，销售只能跪着卖，产品和研发也疲于奔命，彻底地变成了外包公司；产品驱动如小乐帝公司，不同的产品在公司战略规划中有不同作用，有些是保证现金流，有些是获取流量，有些是变现，产品在不同的定位中稳步发展，公司想象力跟着变大，小乐帝觉得这算得上是AI领域的互联网思维。
To B产品客户为先
小乐帝所在团队是一群极具推荐系统经验的人，这群同事非常了解如何将推荐系统做复杂，如何获取更好的推荐效果。但To B业务并未因此订单滚滚来。在与竞品竞争时，客户表示你们的接入成本太高了，直接将我们pass掉，我们还没有表现我们推荐牛逼之处呢？从互联网行业到AI行业，从To C业务到To B业务，这群前互联网人还不适应。
小乐帝作为卧底以客户的身份拨通了竞品的电话，瞬间转变角色从客户的角度思考问题，客户需求的核心无非两个：简单和有效。
对于企业来说，在快速变化的市场环境下，时间成本就是最大的机会成本。如果是新业务或产品，产品研发资源有限，接入推荐系统实际是低成本试错，时间就是生死；如果是老业务，肯定是自身发展遇到了瓶颈，接入推荐更多是死马当活马医的状态，无效就抓紧换其他方案。
To B业务客户更感性，客户更多看与哪位销售关系好或哪位销售口活好而做决定，而非理性思考。简单和有效，一方面，是满足公司业务的救火需求，一方面，是对客户判断的一种快速检验和修正。
推荐系统是提供给客户，客户又在自有业务提供给用户用的。因此推荐系统业务模式核心是B2B2C，推荐系统所要解决的不仅是C端推荐有效性问题，B端需求更是核心，直接决定了业务引入的问题。
基于此，小乐帝再次评估需求优先级时，将客户优先作为一个原则传播给了研发同学。
To B的业务边界
学过经济学相关课程的都会讲到企业的边界的问题。推荐系统这个业务，起初我们意淫客户按照我们定的规则提供物料内容，即便有成本也只有接入一次而已。但后续发现，如果接入成本过高，企业直接就会放弃，不会给我们接入的机会，更谈不上后续表现我们推荐效果之强大。
To B业务的边界在哪？To B业务的边界是提供给客户傻瓜式的产品和服务，不需要客户去想去东拼西凑来配合，而是将脏活累活揽进来，通过产品化的方式解决掉。业务竞争也会朝着这个方向推动产品化工作。
传统的推荐系统，会需要拿到物品信息、用户信息、用户行为信息，通过各类召回算法召回候选集，再进行机器学习排序和生成列表等步骤。理论上来说，推荐只需要满足有正例和负例行为数据，就能对生成推荐结果。后续某个案例也采用了这种方式。在这个基础上，重新划分了客户提供的内容，使客户提供内容做到最小化，而对于我们内部则是根据已有数据做生成更多特征，保证推荐效果的质量。
业务边界由对客户提很多要求，客户水平参差不同，调整为客户提供最小化支持，通过业务内部做更多工作保证推荐效果。将推荐系统黑盒化和产品化，不随客户水平变化而变化。
AI产品经理的定位
最近有意向转行AI产品经理的小伙伴很多，但AI产品经理本质上与传统互联网产品经理并无区别，都是在纷繁复杂的日常工作中，提取出对业务发展有益的信号，并并除掉噪声，以求产品向前发展始终保持最佳投入产出比状态。
AI产品经理与传统互联网产品经理差异也很明显。主要体现在对商业的认知和对技术的边界的理解。以小乐帝举例，To B产品需从客户商业价值实现思考问题，满足简单高效的需求，对技术边界的认知更具挑战，需要懂推荐系统原理、机器学习、迁移学习、卷积神经网络等一切可以促进业务发展的技术。当然这个也是随着业务发展不断扩充能力，小乐帝也在由小白向入门努力的路上。
产品需求来源
小乐帝由To C转向To B最无所适从的是需求来源的变化，To C产品需求可以通过研究竞品，可以培养同理心，可以调研周围人。而To B产品需求则更加黑盒和被动，无法通过常规手法主动挖掘需求，更多是被动式业务驱动需求。
通过这段时间从业经验，小乐帝摸索出了To B产品经理获取需求的几个方式。首先，可以通过销售和项目沟通群挖掘产品需求，尤其是项目出现的问题或重复的流程都是需要重点关注的；其次，在以上信号挖掘的基础上，调研竞品，由结果推原因是更快的方式，如果想造核弹，最快的方式一定是请造过核弹的人；最后多主动找同事和同行从业者沟通，客户遇到的问题都是相通的，同事和同行往往有一些其他视角的经历与思考。
确定AI产品方案
在传统互联网公司工作时，做产品方案正式评审之前，会有需求预评审阶段，顾名思义就是在正式评审前，与各需求相关方对下需求，请各自提意见，将方案做的尽可能完善，在正式需求评审时一遍过，提升整个团队效率。
做AI产品需求时，与互联网确定产品方案并无不同，唯一差异只是AI产品需求由于To B与AI的属性，需求预评审人多出了售前和建模工程师，保证需求满足客户需求和建模效果。
这段时间，慢慢由之前混沌走进些许光明的状态中，仍需努力。
「产品经理读书会」
专注于爱读书爱思考的产品人提供读书推荐、产品思考、以书会友的环境
欢迎爱读书的产品人分享产品道路上的感悟
投稿邮箱：[email protected]
