这次比较不同，先抛出大家可能的收获知识点，再聊文章内容。
看完文章，你能够得到什么？
①解决80%有关产品需求的疑问点，包括面试中涉及需求的相关问题
②获得包括《需求挖掘分析pdf完整版》《需求文档范例》《需求自检表》《需求排期表》《需求分析ppt》等多份阿境独家实用文档
③一套完善的需求挖掘与分析的方法论
“阿境，用户想要在动态上加一个话题功能，我们规划一下吧”
“这是用户需求，不是产品需求”
“本质上用户是为了能给自己发表的内容打上标签是吗？”
“是的，并且需要先判断是真实需求还是伪需求，再进行定义，我们也可以通过用户需求，来分析出我们的产品需求，从而确定我们要做的方案”
若你是个PM，想必上述对话的场景，屡见不鲜。
需求是一个被互联网人说烂的词，却也是最基础的词，产品说需求、运营也说需求、市场也说需求。
那么有几个问题大家思考下，
他们说的需求是同一类吗？
究竟什么是需求？本质是什么？
什么是产品需求跟用户需求？
真实需求与伪需求怎么辨别？
对于需求分析你有一套明确的思路吗？
需求的来源、管理、优先级排期等你能够侃侃而谈吗？
......
在看过这些问题之后，若你能够在很短的时间内有了明确想法，那阿境觉得可以关闭掉文章，因为这是浪费你的时间。（花个10分钟去炖个排骨享受生活都比看这篇文章值得一些）
如果没有，那么！且听厦门吴彦祖阿境啰嗦一下吧。
产品经理的职责便是在最短时间内最大化地创造价值，那么接触最多的的便是日常处理的需求，而需求分析也是非常关键的一步。
如果在看过问题之后，对于部分实施的方法还有疑问，或者是想要系统地进行需求的认知，那么不妨往下看看。
01
需求基础概述1、什么是需求？
什么是需求？
百度百科的定义是：需求是在一定时期，在一既定的价格水平下，消费者愿意并且能够购买的商品数量。
这个定义也是基于经济学当中的定义，如果把它套上产品的帽子，那么我们可以转变为：
需求是在一定时期，在一既定的场景下，为了解决某个问题而激发出用户对于某种目标的渴望。
从中，我们可提炼出几个点：时间、场景、提出者、使用者、方案。
而在实际工作中，脱离了时间、场景的需求，也往往容易被我们忽视。
综上所述，简单来说，需求就是在特定的场景下，用户所产生的问题。可以用“用户+场景=需求”的方式来理解，也可以说，需求是预期与现状的差值。
2、需求的本质
天主教教义当中，有七宗罪，分别是：傲慢、嫉妒、暴怒、懒惰、贪婪、暴食、色欲。而我们的产品，正是解决人身上所带来的原罪的产物。
而从马斯洛需求模型来看，有自我需求、尊重需求、社交需求、安全需求、生理需求。
从这两个方面上来看，需求源于人，最初的源头在于用户。而用户的存在，必然会遇到这样那样的问题。
一个需求归咎到底，还是满足了用户不同等级的欲望。
需求的本质是对用户欲望的满足，以及消除用户的恐惧感，从而解决用户的实际问题。
一款好的产品一定是能满足人性或者欲望的。
而产品本身是众多需求的集合体，根据不同的组合而成为当前产品的形态，产品功能则是满足了用户的目的，而需求和产品功能是一一对应的。
所以我们说，产品经理在处理需求的时候，所具备的同理心这一特质，才能够更好的洞察需求，洞察需求的过程也是在洞察人性，即洞察需求的本质。
3、用户需求与产品需求
先来看一句话“用户给产品经理提了一个需求，研发评估了下这个需求不能做”。
这当中出现了两个“需求”，这两个是同一个意思吗？
很显然不是。
从这个简单的例子可以看出，无论是用户，还是产品经理，还是业务人员，都在谈需求。
而需求被赋予了更多的含义时，就需要引入其他更深层此次的概念加以区分。
比如，上述例子中，前者是用户需求，后者是产品需求。
用户需求主要是指出用户想要怎么做，产品需求则更多的是指导产品需要怎么做。
1）什么是用户需求？
用户需求是用户当前尚未满足，又渴望被满足的欲望，并由此产生的方案。当用户使用得起产品，并且产品并不能够满足用户当前使用时，用户才会对产品产生新的需求，也就是我们所说的用户需求。
用户需求有个较大的特点，不能够指导产品开发，更侧重描述用户想要达到的目的，借此所提出的需求方案（想要的东西），则为用户需求。
2）什么是产品需求？
产品需求是用户需求经过产品经理的“加工”后所诞生的产物，输出具象的产品方案后实现，在实现之后完成产品既定的数据目标，则为产品需求。
产品需求更侧重能够指导产品开发，并且指导产品完成自身的目标（以数据指标作为目标的依据）
3）用户需求如何转化成产品需求？
当我们清楚用户需求与产品需求之后，那么我们如何将用户需求转化成产品需求呢？
作产品经理，我们需要收集清楚信息，经过严格且缜密的需求分析，才能达到将用户需求转化成产品需求的目的。
4、真实需求与伪需求
要解释真实需求与伪需求的区别，可以看个例子：
做个市场调查，问1千个用户是否喜欢*金，几乎所有用户都是肯定回答。那么这个时候就认定*金是当下用户的需求，那么便过于草率了。
因为再深究下去，用户买了*金干什么？对*金的了解清楚吗？等等问题，深入了解完一番之后，用户可能就不会买了。
人性是贪婪的，“需要跟购买”是两回事，用户总是“说一套，做一套”。
再举个例子，用户告诉我们他需要钱，如果你不追问，可能只是知道他需要钱，并不清楚拿着钱去做什么。用户告诉我们的是他“想要”的东西，而我们需要知道的是“用户内在的心理预期”，从而了解用户的真实需求。
可以说，某些情况，用户“欺骗”了我们。
那么这完全是用户的错吗？
不是的，用户有时候都不知道自己更需要什么，他们更倾向于给出解决方案，当他们描述出他们的意向内容时，作为产品经理的我们，需要去剖析，从“伪需求”的表层下，挖掘出用户的“真实需求”
“伪需求”指的是当前用户并不一定需要，而是根据他们遇到问题所提出的解决方案之一，但并不一定能够完全解决他们当下的问题。
“真实需求”是通过梳理需求提出方当前的情况，遇到的问题所分析出来的结果。
02
需求挖掘与分析
1、用户是如何阐述需求的？
有一句话在产品界流传甚广：
“如果我当初问人们想要什么的话，他们只会告诉我想要更快的马。”
从而我们知道，用户的需求是想要一个比走路更快的交通工具。
这其实是个谬论，交通工具并不是结果，而是过程。
不妨再问一句：然后呢？
可能事实上是利用交通工具去上班，去自驾游等，目标不同，所能满足用户需求的产品也不同。
由于处于游戏分发行业，恰逢近期接触到了许多用户的反馈，拿其中一点举个例子：
“我想要更快的游戏速度体验”
在没有深入挖掘之前，我们可能会一股脑地去提升服务器容量、优化游戏代码质量，从而提升游戏速度，但用户是否是真的单纯地想提升游戏速度呢？
做几个假设
“更快的游戏速度体验→在有效的时间内玩到更多的游戏内容”
“更快的游戏速度体验→获得与游戏对手相同的速度→击败对手”
“更快的游戏速度体验→获得成就感”
......
就这几个假设来看，相同的需求描述，是不同的需求点。
A目前遇到的问题是游戏时长少；
B的问题是游戏卡顿引发地对战失败，想要赢得胜利；
C的问题是在游戏中获得成就感；
那么，我们是不是可以这么解决呢？
针对于A，提供个防沉迷账号；
针对于B，提供个游戏加速器；
针对于C，提供相应的成就徽章体系等；
乍一看，毫无毛病，仿佛一下子解决了用户的需求，于是又是一番大刀阔斧地改动优化。
让我们把自身再抽离来看，ABC是否有更隐蔽的点需要我们去挖掘呢？
别忘了，人在描述一件事情的时候，往往会将观点以有利于自身的角度加工并阐述。
A可能是因为家长限制了娱乐的时间，从而无法获得更多的娱乐时间，即使提供了防沉迷的账号，也无济于事；
B可能是自身技术不太好，即使在相同的速度体验下，依然打不过对手；
C可能是对于游戏投入的不够多，导致在游戏当中无法获得更高阶的奖励（物质与名气）；
若是如此，那么所应该提供给ABC的功能，可能又是另外一番答案。
从上面几个简单的例子，抽象来看，可以剥离出几个观点
1）对于提出问题，用户更倾向于给出解决方案
人们往往倾向于解决问题的方案，而很少关心问题本身。所以我们常常会得到“我想要一匹马”的这种声音。
并不是用户提出的解决方案对于产品没有建设性，而是往往人在迫切解决自身问题时，提出的观点并不能查观全貌；
且用户并非产品的主导者，仅对部分功能有使用，那么在这个前提下，用户提出的解决方案能够一定程度地解决用户当前遇到的问题，但却可能延伸出更多的问题；
作为产品经理，通过自身对于产品的目标定位及价值理解，重视用户的解决方案，衡量解决方案底下所埋藏的需求的价值，才是重中之重。
2）在描述需求时，用户往往会将自身观点进行或多或少地加工
当用户对自身需求有隐瞒时，我们也就对需求的理解有偏颇，相同的解决方案，可以延伸出不同的需求。
由此，通过设定不同维度的问题，引导用户以描述性的角度，阐述自身的问题，才能够最大化地避免用户对于自身需求的美化加工。
3）需求并不是绝对的，在不同的阶段，用户会给出不同的需求观点
在初入游戏的时候，我们更需要的是一个教程带领我们了解更多的游戏攻略；
在游戏中度用户的时候，我们更需要的是游戏的体验性，攻略、工具等可能是在这个阶段中较为合适的需求。
在成为游戏深度用户的时候，我们更多的是在游戏中得到成就感，游戏成就体系等则应运而生。
由此可见，需求并非千篇一律，不同的阶段，用户提供到的是不同的需求观点。
“小时候我想要一颗糖，长大了我想要一辆跑车”也就是这个道理，需求受制时间的因素影响，也受制自身的发展影响。
2、如何挖掘需求？
这边的挖掘需求更多的是指主动地去挖掘产品需求。
这边有两种方式，一是从用户身上入手，从用户身上了解需求；二是从产品数据上入手，从数据上洞察需求。
1）更好地洞察用户需求
洞察用户的需求本质是还原用户真实的需求，一般会采用直接访谈、问卷的形式，但是用户全靠一张嘴，因为所处的环境、心境的不同，往往得到的结果会有偏颇，在此阿境介绍两个方法。
一是深度访谈的方式，二是真实融入用户场景，通过这两种方式来进行洞察用户需求。
①与用户进行深度访谈
与用户进行访谈，是需求的来源之一。
而由于用户更多地是站在自己的角度上去体验产品，所以难免有些片面。
在访谈的方式，有比较详尽的方法，阿境后面会单独开一篇文章来介绍，这边就简单概括下。
包括①结构性访谈、②非结构性访谈
非结构性访谈：是访谈者提供一个开放性的主题或问题，由报道人自由阐述；结构性访谈：是访谈者根据研究主题事先设计好的具体问题，系统地访谈研究对象；
这两个的区别是：
非结构性访谈能够通过开放性的问题，了解用户处理某个事情时的方方面面，但需要访谈者记录下全程并且提炼有效信息；
结构性访谈则更多的是根据固定设计好的问题进行，可以理解为问卷调查的线下版，对于访谈问题的设定有一定的要求，否则容易造成无效访谈。
通过这两种访谈方式，收集用户的真实情况：
①用户遇到的问题是什么？
②用户当前在处理问题的时候是怎么做的？
③用户想要的是什么？
在这个过程中，也有几个注意事项：
①客观真实很重要，访谈者要剥离开自身的主观想法
②在舒适轻松的环境下进行访谈（最好是用户熟悉的环境）
③掌控整个过程，引导用户表达自身的想法
②真实融入用户所在的场景
通常我们在做访谈的时候，是以“设计者”的思维对“使用者”的采访，得出的结果相对来说有一定的片面性，同时我们作为“设计者”，不一定能够设身处地的作为用户的身份来考虑问题。
这也就是产品经理拥有“同理心”的重要性。
花费一定时间，成为产品的用户，融入到用户的真实场景当中，借此观察用户的在相应场景的行为及感受体验。
在这个过程中，我们可以观察几点元素。
分别是：用户、环境、任务、目标、行为。
用户：用户是怎么去做这件事的？
环境：用户当前所处的环境如何？
任务：用户当前的任务是完成什么事？
目标：这件事完成的目标是什么？
行为：用户用什么方式来完成这件事？
通过真实融入用户所在场景，并且观察这几个元素，来实现“边参与边观察”的目的。同时在这个过程中去真实的感受用户的情感变化，再将情感变化具象化为实际的数据或者描述
2）从产品数据表现发掘需求
做产品，数据是很重要的一环。
往往每个团队会搭建自身产品的数据概览，包括用户行为数据和业务数据。
具体数据不过多展开。
通过产品的数据，包括渗透率、留存率、页面转化等，长期观测，能够结合着察觉到产品数据的变化，而数据变化的背后是用户行为的改变，从而发现用户的需求迁移。
一般看数据，看现状与看变化。
看现状主要是了解业务距离产品目标的差距，能够加深PM对业务的认识。
看变化主要是养成数据感，通过数据变化，发掘产品问题，从而制定解决方案。
3、需求的基本要素
在拿到手一个需求的时候，如果是一句话需求“在直播tab想要添加一个悬浮球”，那么作为产品经理，没有充足的信息，很难评估该需求是否成立。
那么，作为需求本身，提出的同时，我们需要得知哪些必要信息呢？
包括需求的场景、解决的问题、目标等。
之所以需要理清需求的细节，一是因为有部分需求是伪需求，那么当提出人在梳理需求细节的过程中，可能就会幡然醒悟该需求也许是个伪需求；二是对于产品经理来说，清楚需求的基础信息，才能够更好地去评估需求。
可以看下阿境整理的需求九要素，当这些问题在需求的提出时也能够一起提交，那么便能够比较好地进行需求的评估。
1）需求的类型
一般分为两类，*策需求、线上bug需求、线上漏洞需求、合同期限需求、普通需求等。
*策型需求一般是根据国家颁布的法律法规所衍生出的需求，普通需求则为除了*策型需求以外的需求。
之所以需要区分需求的类型，则是因为*策型需求的必要性及严重性，故无需过多的分析，在满足*策的要求下，最小化成本执行即可。
2）需求的场景
根据百度释意，需求的场景是指在一定的时间、空间（主要是空间）内发生的一定的任务行动或因人物关系所构成的具体生活画面。
需求的场景有几个要素：用户（who）、时间（time）、空间（where）、动机（why），行为（what）。
即，什么用户在什么时候，哪个地方，因为什么动机做了什么事情。
3）需求解决的问题、解决的痛点
在需求对应的场景下，用户遇到了什么问题？在这个问题下，是完全无法进行下一个步骤，还是仅仅是操作不顺畅等。
在描述问题的时候，需要越详细越好。
4）当前针对该需求的解决方案是什么？
针对于遇到的问题，当前是否有其他方式能够解决？
若有，则用户/运营/业务人员等是采用什么方式来进行解决的？解决的具体步骤是什么？需要详细的描述。
5）需求的目标
需求要达到的目标是什么？
一般包括数据性指标（提升多少渗透率/留存等）、优化型目的（eg：用户更好地回到顶部tab）。
通常目标尽量可量化，也需要了解当前的情况是如何，才能确定需求能达到什么样的目标。
6）需求价值判断
需求的价值判断包括需求的频次、覆盖用户、刚需程度，这几个维度主要都作为评估需求优先级的判定标准。
①需求频次
该需求的使用频率是多久？
一个月一次？每天一次？每天多次？不同的触发频率，在评估需求的优先级及选择解决方案的时候会有较大的不同。
②涵盖用户
需求的目标用户群体？
需求涵盖的用户是哪部分用户？该部分用户占据产品的占比是多少？
一般了解需求的用户，主要是清楚需求的涵盖范围，作为需求优先级评估的评定标准之一。
③刚需程度
用户对于需求的需要程度？（如果不做这个需求会怎么样？）
当前需求如果有其他的解决方案，用户是否能够使用？使用的情况如何？
7）需求的优先级如何？
这边的优先级主要指需求提出方基于自身所了解的信息，对于需求的评估。
另外，可以指出对于需求优先级的评估依据，能够更好地帮助产品经理准确判断需求的真实优先级。
8）需求的预期解决方案是什么？
对于需求的提出人（用户/运营/业务方等），针对于上述需求的基本情况，可以简单阐述需求的解决方案。
该方案虽然不一定是最终解决需求的方案，但能够清楚用户对当前问题的预期想法，作为我们做方案的参考依据。
9）其他基本要素
包括提出人、提交日期、期望完成日期。
主要是能够对需求进行溯源及整理。
4、如何进行需求分析？
需求分析，实际上的问题是“如何判断一个需求是否要做？”
在了解了需求的收集、基本要素以及挖掘需求的方式之后，下一步便是进行需求的分析。
但在需求分析之前，除了收集了需求本身的信息，还需要有其他的信息辅助我们做决策，后续才能够对需求进行合理的判断。
1）基础信息整理收集
①当前业务的数据（包括用户行为数据、业务数据）
②当前业务的运营情况
③当前产品对于该业务的规划情况
④竞品分析，了解竞品的情况
⑤用户调研访谈情况（调研问卷、访谈等）
再了解了业务方提供的信息之后，我们往往无法判断需求是否要做，此时结合上述的五部分内容，补充对于需求的了解，由外而内。
“外”指的是竞品对于该需求的处理情况，行业内的解决方案如何。
“内”指的是当前业务的数据、运营情况、自身产品规划、用户调研等。
两者相结合，能够对需求所处的环境有个全面的了解。
2）需求分析八步法
总结了“需求分析八步法”，可以说是本篇文章的精品之精品了，不得不看！
分别是“析要素、挖场景、推价值、看用户、拆竞品、盯市场、查现状、定规划”，且听吴彦祖给你们一一讲解。
从这八步法分析过后，便能清楚需求是否要做，如何正确地剖析一个需求。
①“析要素”
分析需求基础要素。
上述提到需求要素包括需求的类型、场景、解决问题、目标、需求价值、优先级、预期解决方案等，之所以是”析”，是因为从需求提出方接到需求之后，往往是不完善的，我们需要去剖析直到了解完整且正确的需求内容。
一丝错误的信息，比如目标不清楚，场景不正确等的偏差，都会影响我们对需求的评判。
②“挖场景”
挖掘需求对应的场景。
这其实是需求基础要素当中的其中一个，但之所以单独拎出来谈，是因为脱离了场景谈需求，是不合适的。
用户+场景=需求，场景占据了很大的一个部分。
充分挖掘需求所对应发生的场景，从而了解用户真实的问题，才能够得到合适的解决方案。
③“推价值”
推敲需求价值。
这个需求价值可以以用户、产品、企业三个维度的角度来分析。
对于用户来说，给用户提升了什么价值？也就是用户价值。
对于产品来说，提升了产品的什么功能指标？也就是功能价值。
对于企业来说，提升了企业哪部分的收益？也就是商业价值。
这三部分综合起来便是在分析过程中所应该明白的需求价值。
④“看用户”
看待用户对于该需求的看法，了解以及使用情况，这一步是摸检查的预期及日常使用情况，从用户视角看需求。
一般是采用用户问卷调研，用户访谈的方式，通过直接去接触用户，得到最真实的用户感受，当然，在这当中，合理的设计问卷，合理的设计访谈问题，控制访谈的整体节奏，也是重中之重，是能否得到正确且真实的用户感受的前提之一。
⑤“拆竞品”
拆解分析竞品（包括直接竞品、间接竞品）的现状，在明白竞品的用户、商业模式等基础信息的前提下，从竞品的角度去分析对应需求的作用。
借此达到管中窥豹的目的，结合自身产品，明白相似的需求我们能够从中借鉴到什么内容，给予我们什么样的灵感和帮助，同时也了解竞品的不足，在产品设计中能够适当规避。
⑥“盯市场”
紧盯市场动向，对于该需求，摸清市场上的看法以及各大产品各自的发展迭代逻辑，通过市场的反馈及发展，剖析该需求所对应的业务的长久规划。
⑦“查现状”
摸查产品目前现状。也就是产品经理对于当前产品业务的了解程度越高，那么在分析的时候，结合自身产品业务的现状来分析，便能够极大地减少判断错误的概率。
这包括产品当前所处的生命周期，业务的数据情况，业务的运营情况，共三大部分能够概括现状。
⑧“定规划”
确定需求所对应业务的短期、中期、长期规划。
根据规划，了解当前需求解决的问题，处在规划的哪一部分。从整体回归局部，以先总后分的分析思路，理清需求的位置。
3）需求其余条件评估
①需求是否符合当前产品发展的方向规划
②需求对于平台其他业务有什么联动影响吗？
③如果做了这个需求，成本层面与收益层面是否成正比？
03
如何管理需求
1、需求的收集
1）为什么要进行需求的收集及记录？
我们在做版本迭代的时候，往往有一定的需求需要消化，而需求的来源就较重要了。
平时缺少了需求的积累，那么在版本迭代的时候，便会手忙脚乱。
主要的原因有三：
①需求来源众多
②需求并不是当下就需要进行消化
③需求多级传递导致需求歧义
“少壮不努力，老大徒伤悲”，通过平时的需求积累，标注需求的优先级等，能够有效地扩大产品的需求池，从而在适当的时机，通过消化需求，解决用户的真实问题。
2）需求收集的本质及原则
需求收集的本质，在于“收整”及“归纳”。
原则是以用户为中心，以市场为导向，以行业动态为基准，客观地进行需求的收集，同时需要具有远瞻性，当下不符合产品发展的需求，不代表以后不符合。
但一定程度上，用户不一定是需求的来源，目标才是。
3）需求收集方式
需求的收集方式，通常来源于七个：产品规划、内部人员、业务部门反馈、用户反馈、产品数据表现、竞品分析、行业动态。
①来自产品规划
作为产品经理，对产品需要有明确性的规划，清晰自己产品定位所在，产品的规划也是极其重要的。
在产品/业务的不同阶段，产品经理依靠自己的规划，制定不同阶段的目标，从而延伸出相对应的需求。
②来自产品内部人员
产品内部人员包括产品经理、研发、交互、设计、老板等，主要代指产研线上的角色。
一个产品通常有多个产品经理，在日常迭代当中，产品经理有自己对于业务模块的思考，同时经过一系列的调研、数据等，能够发现自身产品的问题，提出需求。
研发、设计、测试等偏研发/设计侧的人员，则是站在自身对于产品的理解所提出的需求，更多的是单独模块，单独功能的优化。如调整主题色、调整客户端接口，优化页面交互方式等。
老板这个角色一般是提出战略性、大方向的议题，不一定是具体的需求。如确定产品的发展方向，从而产品经理经过论证确保可行后，根据方向进行分析拆解成具体的需求。
③来自业务部门反馈
业务部门通常包括运营、售前、售后、商务、市场、客服等。
不论是客服还是运营，这些岗位都是离用户最近的岗位，通常我们所说“倾听用户的声音”，而在客户与用户的沟通过程中，运营在工作的过程中，都能够结合用户的需求，以及产品可优化的部分去提出需求。
④来自用户反馈
用户反馈包括应用意见反馈、用户访谈、社区论坛、主动联系反馈等。
倾听用户的声音对于产品，是很重要的。
由此产品经理对内需要建立完善的用户反馈机制，对外需要搭建用户调研/访谈流程。
其中用户调研包括两种，定性调研和定量调研。
定性调研，主要调研文化背景与生活环境、用户的经验和习惯、探索用户行为背后的原因。最具代表性的是用户访谈。
定量调研，主要调研各个变量之间的关系，是通过各种数据呈现的客观事实。最具代表性的是问卷调查。
在倾听用户声音、用户访谈的过程中，需要注意的是进行信息的解析，也就是根据用户传递的内容，过滤掉失真的那部分，从而得出有效的结果，进而才能够转化成产品需求。
麻省理工大学的心理学家罗伯特·费得蒙研究表明，60%的人在10分钟的交谈中会撒谎2到3次，男人和女人撒谎的频率差不多。
“人们是无法告诉你他们真正想要的是什么，但是可以通过引导让他们说出来。”
准确洞察用户需求的基础是让用户对你说正确的话，有兴趣可以跟阿境单独聊聊，这边不再展开。
⑤来自产品数据表现
“用户会骗人，数据不会骗人”。
可口可乐公司在20世纪80年代，做了一个实验：一款新口味的产品，一款原口味的产品，让实验者挑选，在填写问卷的时候，85%的人选择了新口味的产品。
而真正投入市场后，这85%的人，有90%的人又反水选择了原口味的产品。
从这个试验中可以看出，用户是会骗人的。但是他们的行为数据不会骗人，最大化的还原了用户的心态，选择。
作为产品经理，我们需要根据产品/业务本身的数据表现，发掘问题。从用户层面上来说，在产品当中进行数据埋点，通过用户在产品当中的行为，最大化地了解用户所遇到的问题。
通过宏观数据，查看用户在产品当中的行为；比如渗透率、留存、页面转化、人均次数等行为数据的变化，可以了解并分析用户在产品当中遇到的问题，从而形成需求并解决。
同时，用户的行为表现在数据上，通过这些，能够清楚用户的行为方式，用户的