当我们做产品的时候，实际上我们其实是在不断提出假设、验证假设。我们在与用户间通过产品不断驯化，达到动态平衡，建立更良好的关系。

多年前，我在一本初创的文学杂志上看过一个非常有意思的故事。

故事的背景是一座桥，这座桥是当地年轻情侣约会的胜地，因为一些机缘巧合，这座桥上经常会有人跳河自杀，自杀的人往往是来桥上约会的情侣，一言不合就跳河（一般是为了挽回女友），由于救助及时，多年来极少有人因为跳河而丧生，而正是这一跳，又能让情人回心转意，可以说是“不用死就能达到死的效果”，所以每年在这里跳河的人络绎不绝。

但是有一天，发生了一起不常见的悲剧，一名男子跳河以后，紧接着另一名男子也跟着跳下去，大家都以为第二名跳河的男子是去救前面那名男子，所以就在桥上观望，没想到两人都是去跳河的，结果两人都死了。

这个场面很微妙，在故事里所有人的认知中，在这座桥上跳河，就是“不用死就能达到死的效果”，没有人认为真的有人会跳河而死，包括跳河的那两人，如果没有前面那个人，那么第二个跳河的人就会得救。

同样，如果没有后面那个人，第一个跳河的人也会得救，偏偏两人踩着微妙的时间差接连跳下，本来只是表决心立Flag，结果丢了小命。所以作者在文中戏称，这俩人不是自杀，简直就是互杀。

另一个故事，是最近跟同事聊天的时候得知的。

现在在上海微信、支付宝非常方便，大家身上几乎都没有现金。某天跟同事闲聊的时候，他说到今年十一回老家，特意上银行取了一点现金，结果没想到在老家那个十八线小县城里，连买菜摆摊的大爷大妈都用微信、支付宝支付，所以取的现金到现在都没用完。

我为什么要讲这两个故事呢？

对于这两个故事，我至少有2个疑点：

1. 溺水可能会淹死，这是常识吧，为什么变得像在楼下摆心形蜡烛一样成了一种仪式？
2. 交易的基础不应该是货币吗，为什么仅凭一张不明就里的二维码，我们的交易、支付形式就变成了：“嘀，收钱到账8.88元”？

我们的意识深深地陷入了情境中——第一个故事当然是个虚构的情境，但是我想在读这个故事的时候，大概不会有人说：“这也太扯了，简直毫无逻辑”，然后把书往垃圾桶里一扔；第二个故事则是我们现在现实世界所处的情境，再真实不过。

一、什么是情境？

这个问题我其实思考了很久。

跳出情境，这两个故事看起来都不合理，还有很多更不合理的事情，比如之前频频被曝的快手大量哗众取宠的视频，比如直播里的天价打赏，比如大快朵颐之前先举起手机“开光”的习俗……这些故事每天每时每刻，在各个角落反复上演，从新闻快速变成了习惯，然后被我们用各种论断合理化。

嗯，习惯了。没什么好大惊小怪的。

我只找到了一个词来解释：这里产生的所谓“情境”，大概就是驯化的结果。

我们在通过各种各样的产品、平台、关系、事件……彼此不断驯化，这种驯化发生在我们能感知的一切事物中——关系、习惯、价值观、行动方式……

就像你训练汪星人跟你“握手”一样，我们自身也在被不断驯化。

比如：

• 我们每天都刷牙，甚至有的人吃完东西就要漱口，然而几十年刷牙这件事可能并不普及。
• 每天早上叫醒我们的可能不是梦想，而是蚂蚁森林的能量球该收了。
• 和领导或客户吃饭，我们变得非常注意大家就席的座次，和酒桌上的礼节。
• 上下班路上，我们不会再在拥挤的地铁上烦躁不安，而是习惯于插上耳机，听听“得到”。
• ……

我们在被周遭的关系和环境不断驯化，化解彼此的冲突，变得和谐共存，成为环境希望我们成为的样子。

我认为，驯化从来不是一个单向的过程。就像我们认为，人类驯化了小麦和鸡，让它们能够成为我们的主要食物来源，小麦和鸡也同样驯化了人类，让人类从狩猎采集社会进入农业社会，开启完全不同的生活方式。

这个时候，我们再回到产品经理的日常工作中来看，或许会有不一样的发现。

我经常会问我面试的产经理，你怎么定义需求？你怎么理解产品经理的工作。大部分人的回答可能都接近于：

需求就是用户的问题；产品经理就是通过产品去帮助用户解决这些问题。

听起来产品经理就像个矿工，拿着产品这把铁锹，学习一些叫做产品思维的勘探技能，然后找到名叫用户问题矿藏直接去开挖就行了。

——问题回答起来似乎符合直觉，但仔细一推演就变得出乎意料。

如果我们把自己定位成解决问题的人，那么我们可能就像拿着锤子，在到处找钉子：今天看到这里有问题，明天看到那里有问题，好像这个世界总是有无穷无尽的问题等待我们去解决。

如果你能够理解我前面所说的，我们只是通过产品在实现与用户之间的彼此驯化（当然这里面还有很多其他因素都参与了驯化的过程），我想你也就能够理解为什么我认为，产品经理最核心的能力，不是发现问题并提出解决方案，而是提出假设并验证假设。

看起来这两者并没有什么不同，实际上却有本质的区别。

首先，问题是无处不在，但是并不一定都需要解决的。

比如：十年前，喜欢旅行的朋友可能会希望买一台相机，把旅行中所见拍下来留作纪念，但是相机太大会很麻烦，所以可能他们希望相机在保证拍摄效果的同时，又能尽量轻便易于携带；十年后的今天，这个问题（相机不够轻便）可能已经消失了，因为我们使用的手机变了。

如果我们过于关注问题，我们可能会陷入一种自证预言——这是一个问题，我们需要找到最优解。假设则不同，假设的含义本身就存在两面性——假设成立，或假设不成立。

我们可以假设把APP界面菜单由舵式导航改成宫格式导航，可能能够让用户觉得体验更好，或者假设如果推出一款“胶囊奶茶机”可能会非常受欢迎，然后想办法验证这些假设。

其次，假设逻辑更容易带来颠覆式创新。生活中确实存在各种各样的问题亟待解决，但是真正颠覆我们的生活，带来新一轮驯化的产品，一定不是来自问题逻辑。

我们可以想想：iPhone、信用卡、电子邮件、SpaceX……他们诞生时，并没有解决新的问题，甚至于有很多后来被证明是开创性的产品，在刚开始的时候看不出相较于已有解决方案的任何优势。

假设逻辑则不同，假设逻辑不会在现有的问题解决方案中钻牛角尖，而是先想象出一个全新的情境，再进行验证，与用户彼此驯化，最终走向变革。

最后，问题逻辑与假设逻辑的行动是不同的。既然有问题，那么就会有答案，所以我们才会有大量的方法指导我们如何分析问题、解决问题，我们会铆足劲向最优解努力。

而假设是不一定能产生解决方案的，一旦验证不可行，我们就会马上调转枪头，或者寻求其他路径，或者直接放弃当前的目标，皆有可能（对于认准问题逻辑的人来说，可能会接受不了这种“始乱终弃”的行为），对于按照假设逻辑行动的人来说，证明假设成立和不成立同样重要。

所以，按照假设逻辑行事的人，更有可能对于用户存有敬畏之心，尊重彼此不同的逻辑。

二、当我们在做产品的时候，我们其实在做什么？

我的观点是：我们其实在不断提出假设、验证假设。我们在与用户间通过产品不断驯化，达到动态平衡，建立更良好的关系。

当然，这里我并不是说问题逻辑不正确，问题逻辑非常重要，假设逻辑与问题逻辑是密不可分的。假设逻辑好比做决策的大脑，问题逻辑则是那双灵巧的手，基于假设逻辑来解决问题，我们才更有可能做出正确的决策。

三、我们要如何来提出假设，并验证假设呢？

要提出一个正确假设的前提一定是充分的调研，而调研的前提就是清零——给我们自己清零。

在工作中，我遇到的最常见的需求分析方式就是：发现一个问题→想到可以用什么功能来解决→分析→设计，这个时候所谓的分析往往成了走过场，只是为了自己想做的功能找到“充分”的理由。

直觉给出的解决方案先入为主，后面再要做透彻的分析几乎是不可能的，所以我们一定要有意识地给自己清零，告诉自己，我们其实还没弄清楚用户的真实问题，慢慢的，也就有了充分调研清楚的能力。

四、我们应该如何调研？

我认为有两个点很关键：一是用户当前所处的情境，二是用户的行动逻辑。

用户当前所处的环境到底是什么样的？在用什么解决方案？他们认为这个解决方案如何？他们是如何使用的？他们为什么会选择这样的方案？他们行动的目标是什么？他们为什么会有这样的目标？他们的绩效由什么决定（B端）？……

5个why的方法能够很好地帮我们分析这些问题。除了直接问用户，我们也应该关注互联网上用户同行的一些观点和吐槽，以及一些相关的产品如何来思考这些问题（这些能够从他们的营销资料中有所体现）。

调研清楚用户情境和用户的行动逻辑之后，我们需要明确三个重要的角色：用户、利益相关者、团队（跟之前介绍过的体验画布第3、4、5版块一致），这三个角色就是参与驯化“仪式”的主角。

用户是我们目标的使用者，团队是指我们自己的团队（不仅仅是产品或研发团队，还包括运营、品牌、销售、客服……所有跟我们统一立场的，能够影响问题解决的角色，都属于团队角色），其他人则是利益相关者。

我们比较容易界定用户和团队，但是在分析利益相关者的时候，可能就会有点迷茫了。利益相关者可以是国家的监管机构，比如基于《网络安全法》进行监督的机构，也可以是第三方服务商，或者是某社区发垃圾帖的水军等。

我们分析这三类角色时，需要考虑他们是如何影响我们的假设是否成立的，以及他们的核心诉求和行动逻辑。这里需要注意的是，我们不仅仅要考虑积极的影响，同样需要考虑消极的影响。

最后，我们需要给我们做出的假设制定一个标准，基于这个标准来衡量假设是否成立，这个标准最好是可量化的。

调研、角色分析、衡量标准，这是我认为假设逻辑非常重要的三点。至于后续具体的需求分析和设计，有太多的工具能够指导我们行动（体验画布就不错），我也就不必展开了。

小结：

1. 产品和用户之间，通过相互驯化达到动态平衡，建立良好的关系，而为用户提供确定的体验；
2. 产品经理的核心工作是提出假设、验证假设，依次真正找到能够与用户建立关系、彼此驯化的契机；
3. 如何提出假设并验证假设，调研、角色分析、制定衡量标准是三件非常重要的事情。

本文由  @不知 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。