前言
　　在团队中，发现很多pm把“用户需求”时常挂在嘴边，似乎有了这个词就有了庇护自己所设计的功能的“尚方宝剑”。如果把该“用户需求”单独拿出来看，可能无可厚非，但是否要实现该需求，为什么实现这个需求而不是实现那个需求，又似乎很难有充足的理由。在此我仅把自己所发现的实际团队中的问题做一些不成熟的思考。
　　一、“用户需求”不等同于“产品需求”
　　“用户需求”我们不应该尽量满足吗？当然应该。但首先应该明确“用户需求”和“产品需求”。“用户需求”是产品可能的目标使用者（可以称为“产品用户”）所提出的任何改善产品的意愿。“产品需求”是产品的关键人（可以称为“产品关键人”）对产品的意愿。比如企业老板、公司大股东、市场部门都是产品关键人。
　　比如：需求1：用户提出希望实现产品功能A
　　需求2：研发部门评估认为实现功能A需要1个月的周期
　　需求3：市场部门希望在2周时间内产品上市
　　需求4：老板希望尽可能的降低研发的投入费用
　　需求5：销售部门希望产品上市后有足够的竞争力
　　很明显，以上的几个需求只有“需求1”是“用户需求”，其它都是“产品关键人”的需求。产品关键人不是产品的直接使用者，但决定这企业资源的投放方向，对产品起到至关重要作用。
　　所以，“用户需求”仅仅是“产品需求”的一部分，用户需求和产品需求之间往往是一种相对矛盾的关系，产品经理的工作实质是“在用户的需求和产品需求（企业能提供的资源）间找到一种平衡”。作为产品经理，不是只把“用户需求”挂在嘴边并不计投入的满足，因为是要付出成本的（企业资源），尤其是对于中小企业。那么，哪些需求要满足哪些不满足，这就是涉及到需求收集和需求筛选。
　　二、不重视日常需求的收集
　　上文提到了“需求收集”，在这个环节，团队中发现的主要问题如下：
　　每个产品经理都知道需求收集很重要，但实际工作中又往往不注重记录下获取的各种需求，以便产品设计或迭代时参考。最常见的情况一是认为获取的需求很简单，不值得记录，认为即便不记录在产品设计时也会考虑到该需求。二是认为获取的需求不是产品设计能直接解决的（这种需求往往是非功能性需求，比如对性能、价格、渠道的需求等）。
　　以上的两种思想导致把各种可能的需求都漏掉了。作为产品经理应该尽可能全的记录任何需求，首先产品设计和需求记录的不一定是一个人，即便确实是很简单的需求对于产品设计也是有益无弊的。其次产品不是简单的基于功能的技术实现，而是渠道、价格、市场、技术、运营、售后等的综合体现，所以任何需求都是可能影响产品的因素。
　　三、不注重阶段性整理需求
　　以何种方式记录需求？不少人喜欢以简单的方式进行记录，比如word、txt、excel、脑图等，这些方式都没有问题，但实际情况往往是只图每次记录的便捷，而忽视阶段性的对这些需求进行整理归类，于是在正式需求讨论时面对的是一对各种不同格式、表述模糊（经过一段时间可能自己都回忆不起当时记录的是什么意思）的文档。这极大的浪费了需求筛选的时间和质量。所以一定要定期整理需求，把需求进行归类并把描述不清的需求尽量表述准确。
　　在此，仅把个人的记录需求的方式表述如下：
　　1、以“单项需求卡”的形式记录各种来源的需求
　　需求采集的方法有用户访谈、问卷调查、可用性测试等等，个人习惯于把收集的各种需求以“单项需求卡”的方式进行记录。如下图：

　　每一项需求都记录为“单项需求卡片”，文件名后面的“已记录”代表该需求已经记入《产品功能列表》中了。具体内容如下图：

　　以上的“问题提出者”和“用户问题描述”用于记录用户提出的问题，问题经过我们的分析记录在“解决方案”中，描述如何解决用户的问题，最后进一步分析出问题所代表的“用户实际需求”。这个“用户实际需求”就是最终要记录在《产品需求列表》中的需求。
　　那么为什么不直接把以上的表格转换成Excel的方式进行记录呢？第一、Excel不好记录图片；第二、单项需求卡有利于持续的记录不同老师对同一问题的描述，也就是说以后更容易追溯从“问题->解决方案->用户实际需求”的演化过程。作为产品经理，要尽量能做到有理有据的说明问题，所以要对中间的过程进行必要记录，而不能仅仅为了快捷直接记录结果，而最终导致无据可依，靠打嘴架解决问题。
　　2、将“单项需求卡”中的需求汇总为《产品需求列表》中
　　单项需求卡片的需求可汇总为《产品需求列表》，如下图：

　　其中的“产品需求说明”就是“单项需求卡片”中的“用户实际需求”的内容，“解决方案”就是“单项需求卡片”中的“解决方案”的内容。
　　这样持续不断的记录和定期整理需求，最终的《产品需求列表》是后续工作的依据