需求挖掘是找方法、找途径把用户的需求收集过来，只要方法正确，花一些心思，都可以做得很好。而需求分析可以说是非常有技术含量了，产品经理的价值在这里也能得到更大的体现。
首先要解决一个问题，就是如何准确的传递需求。比如你发现了一个新的需求，如何让你的老板、你的开发、运营同事能够理解这个需求，让他们认可这个需求的重要性，这时候就需要讲故事了。
用讲故事的方式描述用户问题
讲故事是一种很重要的能力，也是沟通能力的体现。不管是给开发讲需求，用户访谈还是对外宣讲，产品经理都需要让别人理解你的意思，让别人buy in你所讲的东西。
没有人喜欢说教，如果你开需求评审会上来就说，好，今天我们来讨论一下需求，第一个需求是blahblahblah，估计没几个愿意仔细听。如果你能讲一个故事，让听众很容易带入，那么别人可能一下就get到你想讲的点了。
锻炼讲故事能力，你可以去几个地方学习：媒体记者、TED、传销组织（这不是开玩笑，传销组织能把人忽悠的一愣一愣的，就是因为他们特别特别会讲故事）。几本书：华尔街日报、无价
讲故事的时候有三个原则：平实、有用、简练。
平实：真实反映现实情况，不要夸大、臆测、评估、假设，不然别人都不相信，你还怎么把故事讲好？
有用：讲故事不是为了让人图一乐，而是为了传达信息，要对听的人有用，达到你的目的才是最重要的
简练：30秒不能抓住一个人，那你就不能阻止他走人
那么如何用讲故事的方式描述用户问题？当我们讲需求的时候，一般是按照这样的顺序讲：
一群什么样的用户->在什么场景下，想解决什么问题->解决过程中碰到了什么问题->最后用户是怎么解决的
最后一步先讲用户本来是怎么解决的，然后讲你的产品能够怎么帮用户解决这个问题，如果两者对比，发现你的产品能更好的解决用户问题，能够提高效率，显然你的产品就更有优势。同时也要考虑同类用户、不同用户之间的关系是什么。
举个栗子：
有了这个问题，下一步要做的就是提炼和延伸，探究问题发生的原因：
接下来提炼观点，如果你的产品出现了：
之前------------------------------------->自从出现了xxx
:( 对比 :)
不同场合讲不同的故事：
用思维导图梳理用户需求是一个很好的方式。举一个我自己写的作业的栗子，关于“待办清单”类产品的【用户-场景-问题-解决方案】：
需求优先级排序
KANO模型是以用户需求对用户满意程度的影响为基础，分析两者之间的关系。源于其能够高效地将不可见的产品体验问题可视化。
魅力属性：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升；
期望属性：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低；
必备属性：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低；
无差异因素：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意；
反向属性：用户根本都没有此需求，提供后用户满意度反而会下降；
需求池管理
需求池大概长这样：
需求池并不等于版本的全部内容，而是是占有一定比例，通常不会超过一半。每个版本核心的部分还是依赖于产品本身的迭代方向，比如上一个较大的功能模块，而需求池中和这个功能模块相关的需求可能就会被放在这个版本里做。
每个产品狗都必须有一个需求池。每个团队都需要有一个公开的的需求池。常用工具：Excel（个人好用，但团队用不方便），Teambition/Tower（团队用很方便），trello/JIRA（国外的，网速慢，可能会被墙），思维导图（个人使用很方便但无法团队协作）。一般选一个用就好啦，做很多份也没必要。
举个栗子：
一闪而过的想法、用户的吐槽、产品被投诉都是非常有价值的，值得被记录并且进行认真的分析。那么这些需求是怎么被收集到需求池的呢？需求进入需求池的过程大概是这样的：
需求收集：记录尽可能多的信息。反馈者、受影响的用户（可能是同一个人，可能是产品经理本人，最好追到具体的用户），详细描述现象（什么场景下遇到什么问题，用户的操作步骤或用户希望怎么解决），补充基本信息（版本、手机型号、网络环境、浏览器类型/版本，截图或视频作为证据，有多少人遇到了相同的问题等）
需求整理：分类需求是Bug、改进还是全新需求。如果是Bug就找测试，看复现还是不复现。如果是改进或全新需求，首先分析是否是有效需求，其次按照重要/紧急程度做四象限分析，确定要不要做、能不能做
需求反馈：第一时间给到提出需求的人反馈。把握几个原则：尽量当下反馈结果，尽量真实反馈结果不要套路别人，如果进入需求池，尽量做到有行动计划
再举个栗子：
版本规划
互联网核心思维之一就是迭代思维，而产品经理就需要对产品版本进行规划和管理。产品迭代策略和需求优先级管理就显得尤为重要。
如何理解互联网产品的版本？
版本=每次封闭的需求
封闭的意思是说，这个版本就做这些功能啦，不增加也不减少。这样可以有效地避免改来改去没个完，或者临时加个东西，改个东西，或者修修补补。
版本意味着每次迭代了哪些功能，通过版本还可以还原迭代的过程，有利于总结经验。移动互联网产品不是一次做完一年的需求，而是一个迭代的过程，千万别想着“憋大招”，会死的。
而在不同平台的产品通常有不同的周期：
举个栗子：
为什么要严格控制版本？
代表产品的规划：到达阶段目标需要经过的步骤
代表产品的节奏：不同的时间要做什么，产品在某个阶段重点关注的是什么
代表沟通的效率：版本封闭，尽可能避免了需求反复变更
代表内部的管理：用版本管好你的Boss，老板临时加需求的时候告诉他，您好我们先评判一下优先级但是不会动现在正在研发的版本呢亲，下个版本会考虑做的呢亲：）
版本要关注什么？
当前版本：现在的版本有哪些功能？
下一版本：下个版本做什么？一般会做后续2-3个版本的规划
需求池：需求池里面有哪些功能可以做在下个版本里？
做好版本管理，对内，你和你的团队都清楚目前要做什么，下一步要做什么。对外，其他人的反馈，你可以清楚的告诉他们，哪些会进入到开发列表，哪些暂时不会。
做一个有理有据的人哦。
如何确定版本方向？
1.明确关键用户、场景、需求：
核心用户是谁？用户在什么场景下需要解决什么问题？用户具体的需求是什么？
2.回到产品架构和业务逻辑：
产品形态和最终的目标是什么？拆分业务逻辑，具体有哪些功能模块？
举个栗子：
赶集网生活服务类别，竞标功能。以搬家为例做第一版：
业务逻辑
更细节地拆分下来
将功能区分前后端和不同用户群
接下来，找到功能的核心支点
从业务逻辑的角度找到占主导地位的角色是什么？--商家，商家要竞标才能完成交易
该角色要完成任务，最关键的任务是什么？--竞标，付钱
角色为了完成任务，最最最核心的功能点是什么？--商家竞标
因此，点击竞标这个按钮就是这个功能的核心，接下来，就是从核心去找上下游：
以竞标为中心，反推上游，是用户发标。推下游，是查看联系方式。在每个大的功能模块下再去细分具体的功能点。
1.0版本的重点是跑通流程，就是做从0到1，从无到有，而下一个版本，2.0版本要关注的就是提高功能的整个用户体验：
1.核心功能体验是否足够好？否则优先迭代
2.上游往下游转化率是否足够高？不高就次之选择迭代
3.下游功能是否顺畅？然后迭代
再下来，用户体验提升了，下一步就是要把生意做更大了。核心做好了开始做上游，只有更多的用户发标才有更多的商家竞标
总结一下，产品迭代的原则：
基于数据：
第一优先：围绕关键用户的关键行为（活跃率）
第二优先：围绕关键用户重复购买问题（留存率）
第三优先：新用户的引入与转化（拉新）
基于上下游关系：
先解决下游体验问题，再解决上游来源问题
基于用户群体：
先解决核心用户的主干需求，后解决分支用户需求
一个法则——三三法：每次需求最多三个模块，每个模块最多三个核心点
再举个栗子，三节课的案例（这里知识点相同，不再赘述，只截图）：
