需求理解和定义的过程可能不在需求本身，而是在需求之外，跟人的因素、心理学、社会学等有很大的关系。
用户需求与产品需求的区别
用户需求，关注的是用户遇到了什么问题，希望能解决成什么效果。用户需求是从自身角度出发，自以为的需求。
用户经常提出的需求，从他们角度而言都是正确的，但是他们更多的是从自身情况考虑，但对于产品的某个功能都有自己的去往，但是对于产品定位、设计的依据等情况并不了解，他们的建议也许并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。
产品需求 是提炼分析用户真实需求，并符合产品定位的解决方案。
解决方案可以理解为一个产品，一个功能或服务，一个活动，一个机制。
需求分析：从用户提出的需求出发，我们就应该明白如何定义并获取用户需求。构建其用户角色，描述使用场景，定义用户问题。句法格式如：某用户，在某场景下，遇到了某问题。（5w1h）
我们不能简单地看用户需求，而是应该去挖掘用户产生这个需求时，其心里是什么驱动着用户。
所以，更应该思考，需求分析的过程，是如何把用户需求转为为产品需求，中间的纽带是什么？
转化需求
我们自己知道开发的流程，参与过项目的开发，我们知道开发需要的是具体的、详细的、可执行的步骤，而不是一个宽泛的概念。举个例子：比如说我需要在填写合同的过程中，了解到我当前的进度并且可以跳转到相应的模块，这样我会降低焦虑感；
这样的需求是用户场景标准的写法，可是当你拿着这样的需求去找开发人员吗？如果这样的话，开发人员会问你：怎么展示？放在哪？内容是什么？怎么触发展示？等等。如果开发人员不乐于沟通，按照自己的想法来，那就麻烦了，开发之后会进行反复的修改，陷入相爱相杀的拉锯战。
用户场景的作用有两个：一是作为进度跟踪的依据；一是作为与人交谈的备忘录；用户场景并不是精确的需求；因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前来完成，这是敏捷需求分析的精华所在。任何提前做好准备的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费；
用户需求就是真实的、来自各种渠道、各色人物对你的产品的索求，你需要对这些声音做出整理分类，然后分析这些索求背后的原因，还要和团队成员交流来确定要不要开发相应的功能来满足用户的索求，最终变为一个个用户场景汇总到团队的需求池。
显然，到这里只完成了一小部分的工作，也就是只对用户端的需求内容做了处理，如果你这就拿着用户吃场景去找开发人员，那你相信我，你一定会被打的；就算不被打，那之后开发时反反复复的过程也一定会将你和开发人员折磨到心力交瘁。
你接下来需要做的正确的事是：将需求池里的用户场景细化，将其变为一个个页面，一个个按钮，一个个文本框，然后画出原型图甚至草图，并交流你的想法，反复修改。直到你们都觉得页面的操作流程是最简化，某个按钮放在这里是最方便的，某条提示内容这样写最贴心，等等。
说到底就是将用户场景细化+可视化。这个过程虽然也会反反复复，但是我觉得这是值得的。细化是指思考的细化，产品形态的具体化，思考越细越好，越具体越好；可视化是指将你的思考变为可视化的东西，能让人一目了然，迅速了解你的想法，是和团队交流交流使用的，形式包括草图、原型图、思维导图、流程图、文档等等，不只这些。
这就是将用户场景变为产品功能的过程，当你把用户场景细化+可视化后，你拿着原型、流程图、思维导图和开发人员沟通时，你们会和谐很多，把过程中可视化的东西汇总整理起来，将思路串联起来，呈现出画面，会节省很多时间。
用户场景作为一个个用户期待的愿景，产品功能是一个个相对独立的可测试可交付的功能，正是这些功能驱动了用户场景的持续发生，让我们的产品变得越来越完善。我们可以在每次项目的启动会上给开发人员讲解用户场景，让他们理解要开发的产品功能是为怎样的使用场景服务，然后在认领任务时使用产品功能，而不是用户场景，这样可以确保他们提交的工作都是量化的，可测试的，项目也是清晰有序的开展的。
总结
怎样理解用户需求和产品功能？
其实对这个问题的回答也就是产品经理存在的意义：产品经理是一条连接用户与公司团队的纽带，前期他会奔走在群众之间，记录、整理、分析、思考用户的各种需求，后期他会带着这些需求和团队成员一起打磨出解决方案。用户需求是对外，产品功能主要是对内。
但这只是产品经理重要性的一方面，另一方面在于产品经理对整个项目的把控和推进，在于产品经理对团队和项目的管理上
