作者：徐毅，华为云DevCloud首席技术布道师、敏捷转型执行教练及顾问。

这个材料是2018年底，DevCloud内部的大咖说活动约稿，深感当时看到的一些问题，希望能够通过自己微博的力量能够影响一些人、至少推动问题改善一些，于是决定分享这个《产品思维：从技术思考走向用户思考》的议题，最后是在2019年1月10日做的分享。此文中分享的材料主体没有做改动，主要是替换了少量图片，补充了一些图片来源的说明，然后最后一页的自我介绍，把最新的信息刷新上去了。

产品思维

从技术思考走向用户思考

我觉得咱们没有啥2C思维，所以专门先用第一页讲2B和2C的一些区别。不过现在来看，其实咱们还不是2B思维，咱们是2O或者叫2超大B思维，因为运营商实际上是一种特殊的B。一般的2B是指面向广大的中小企业，和超大的NA企业，这两个群体是有区别的。不过在此也不赘述了，还是回到当时材料里面的内容吧。简单来说，2B业务，通常客户企业真正的用户是不直接跟我们厂商接触的，而是客户内部通常会有个代言人，比如IT部门的某个人，或者跟我们谈项目的客户侧项目经理，会去收集需求，然后转述给厂商这边的BA（业务分析师）或PM（项目经理），但这个问题就在于，客户侧接口人可能并不是我们产品的使用者，可能无法准确理解真正用户反馈的需求，进而导致表述失真，以及厂商侧自身的传递失真，从而导致厂商侧产品团队接收到的信息与真正用户发出的信息出现大偏差。而客户侧决策者往往不是真正用户，所以在2B模式下，一家企业也只需要搞定少数几个决策者或有能力影响决策的人即可，对于广大的真正用户，反而是不需要太关心的。但在2C模式下，每个用户都是客户，他们自己决定自己的钱包，而且由于数量众多，厂商不可能有那么多的客户经理、业务分析师、项目经理的资源，所以只能采取产品经理主导的模式，由产品经理通过面攻击而非点攻击或线攻击的方式方法去理解用户/客户需求、解决问题，而团队和产品经理是密切配合的关系，不是传递关系。

我基本上只用工行的卡和服务，所以用了工行来举例，银行基于自己的App提供的转账功能如下第一张图，而且还需要用U盾，日常转账非常麻烦。当然，时至今日已经有了很多改变，比如说一定额度以下，使用工银e支付可以直接免密支付，也变得更方便了，不过这不影响我们材料的主体思想，因为工银e支付的这些功能恰恰就是他们开始拥抱2C思维的结果。第二张图是我用了微信做例子，方便很多，也简单很多，现在有了二维码扫码支付，就更便捷了。

我认为关键在于，在我们心目中，是否认为“用户可以选择”，用户是否可以用脚投票。之前在IBM时候辅导过工行的研发中心，包括他们的网上银行和手机银行团队。我发现他们的问题就在于业务方给研发的要求，基本上可以总结为，凡是柜台有的业务，都要尽可能地全部在网上银行提供，凡是网上银行有的功能，也都要在手机银行上提供。但是，我的天啦，柜台、Web、手机，是三种完全不同的场景，用户的行为和需求等各方面都是有很大的不同的，而且片面强调手机银行上功能的全面性，而不顾用户实际的使用情况，包括频率和体验等，是无法带来好的效果的。前些年至今，支付领域的发展情况，大家也都看见了，用户用脚投票的结果，哪种思路是有效的。

我们应该怎么做呢？就是要换位思考，转变关注点，从关注供给侧厂商自身的系统和技术，转向关注另一侧消费侧的用户和他们的体验。

用户到底想要什么？

那么，用户到底想要什么呢？如下这张图来自于《用户思维+》这本书，我觉得非常棒，而且这个小测验当时把我也给羞辱了一顿，所以我特别喜欢拿出来做例子。图片就无法体现PPT的动画效果了，大家可以先看图片的左边部分，你宁愿用户有哪种感受？哪种场景更有可能成为预测可持续成功的标志？哪种场景可以激发更多诚实的口碑传播？

A：这个产品棒极了！

B：这家公司棒极了！

C：这个品牌棒极了！

但实际上，正确答案是秘密选项D“我棒极了！”。这与我们的产品、我们的公司、我们的品牌无关。这与用户对我们的感觉无关。与之有关的是用户对自己的感受，也就是我们的产品或服务帮助他们做了什么或称为什么样子。

那么应该如何做呢？《用户思维+》的作者也给出了好产品的“成功准则”。而且结合近期刚出版的《福格行为模型》（我翻译的），我认为这些准则，实际上是什么呢，帮助他们真的变得很好就是在帮助他们提升完成行为或养成习惯的能力，而帮助他们保持渴望成功的愿望就是帮助他们维持或加强动机，而减少认知资源泄露就是在减少干扰让提示变得更清楚，这么一来，按照福格行为模型的B=MAP共识，只要做到这三个方面，用户就能够更好地完成行为或养成习惯，这些行为和习惯就能够成就卓越用户。

那具体我们应该怎么去成就卓越用户呢？以及怎么让用户选择我们来成就卓越的他们，而不是其他厂商呢？这就需要我们做好自己的价值主张设计。价值主张设计包括用户群体是谁、他们要完成什么工作任务（JTBD，Job-to-be-DONE）以及他们对结果的期望、过程中的风险和阻碍，也即一般说的痛点；我们作为一家厂商，要怎么去帮助用户解决问题、达成JTBD。注意，这个时候，还没有到具体的产品功能或服务内容，而是先在方案层面，也即我们要提供什么样的方案去确保用户可以达成期望（得到他们想要的）、缓解痛点（应对风险、移除障碍）。例子有很多，网上随便搜，比如最常被用来举例的爱彼迎的价值主张设计图。

如果你认可，那么，接下来的问题就是：你产品/服务的价值主张是什么？可以一句话说清楚吗？

确保安全无忧、稳定可靠，只要找对了场景，也是一种价值主张哈。这方面可以参考KANO模型来分析，魅力因素可以认为就是业界说的爽点，期望因素可能算作痒点，必备因素应该就是痛点。

具体怎么做，我认为需要应用设计思维的方法，大家可以搜一搜斯坦福设计思维图、IBM设计思维原则图，公司内我印象中iLearning上面也有了课程，大家有很多资源可以学习了解，我这里就不再复述了。

创造产品的本质就是要创造英雄

让用户在使用我们产品和服务的过程中，能够在我们的帮助下攻坚克难、达成所愿，成为更好的自己，这就是一个优秀产品的特点。而且时机很重要，在开场的时候，你想要去动员这个“未来的英雄”，基本上只可能会吃闭门羹，因为激励事件还没有发生，用户对这个未来还没有认知。

而且明确了故事线之后，我们就可以顺着故事线去设计数据埋点，进而通过结果数据监控，来反向检测我们的用户体验路径设计是否合理，是否能够产生我们预期的结果，并可以围绕这个已明确的故事线进行复盘改进。

这跟业界流行的AARRR海盗指标思路也是吻合的。AARRR是一个具体的数据模型，适合SaaS类业务，但我们可以根据自己的业务特点，拟定出自己的转化漏斗模型。而模型的每一个指标，都是我们故事线中能够体现业务关键节点的关键指标。而每个指标都来自于对用户关键行为的监控和度量，而这些关键行为就是用户顺着故事线不断前进会产生出来的。所以，逻辑完美吻合。

故事线也非常有助于凝聚团队共识，甚至直接用来管理开发进度。它可以明确我们厂商围绕故事线各个节点，需要给用户提供的产品功能和服务，每一张卡片就是一个Story（故事卡），所有人就都能够很清楚，我们所做的功能对用户行为所产生的价值，也都能够明白我们工作的意义，不只是完成某些代码的开发，而是为了成就卓越的用户。而这种意义，正是《驱动力》书中指出的三大驱动力自主（Autonomy）、专精（Mastery）和目的（Purpose）其中之一。多嘴一句，其实我认为这个Purpose翻译成“使命”或“使命感”更加贴切，也即是我记得公司一些高层领导曾经讲过的，我们心中要有殿堂，这个殿堂其实也是一种使命感。

细节方面，设计要有人性。具体来说，就是要重视产品的UX设计（不等于UI设计；或称UCD，但核心不是叫什么，核心是实质上是要聚焦于用户体验去设计产品的功能和使用与操作方式），我相信大家一定有吐槽过很多产品。在如下图的这几本书里，你会找到同感，我极力推荐大家阅读。

然后是商业模式画布，也不多说了。

精益扩张，这里也只是展示一下，还是推荐大家有时间可以看看这本书，我觉得非常棒。其中有个点很关键，就是我们要关注关键指标，而不是虚荣指标。当然，做到这一点，其实至少有两方面的要求：一是要能够真正理解业务，甚至是理解这个业务背后的时代背景，才能够真正地识别和制定出关键指标；二是说如果我们知道什么是关键指标、什么是虚荣指标，然后还需要我们能够克制，要坚定信念，去追求关键指标，而不要为了表面繁荣去追求虚荣指标。

其他一些对我们有帮助的理念和书籍。

作者介绍