做产品久了常常会犯这种错误，就是会将用户需求和功能描述混淆起来使用，或者是跳过用户需求直接描述功能需求，什么是用户需求？什么是功能描述呢？对比会更容易理解一点；
用户需求：
希望可以有更丰富的方式来表达自己的意见；
我想能更方便的进行购买商品；
……
功能描述：
开放用户可以上传图片的方式来进行评论；
我们开发一键购买功能给用户，方便用户更快的下单
……
类似的描述可以找出很多，我们经常收到的是无论是来自用户、上级或者其他渠道的需求和意见时，往往都是功能描述需求。原因就是我们在遇到问题时会根据自己的经历和知识给出相应的解决办法来，所以我们接收到的不同的「用户需求」实际上可能是同一个，反之亦然。这也是PM和普通用户在思维方式上的最大区别：
用户：
遇到问题–>提出解决的建议1
比如这种：每次下单跳来跳去好麻烦，跪求个一键购买，
PM：
遇到问题（或收到用户建议）–> 分析用户需求、场景等 –>产生解决方案1,2,3 –>选择最优解
PM多了了解背景和筛选最优方案这两个过程，比如我们应该了解反馈的用户是集中在手机端还是web端？是不是我们的支付路径太长？是否可优化？是否有其他购买方式？反馈的用户有些什么特征呢？等等，即便最后也是通过一键购买解决，但值得肯定的是我们选择的是当前的最优解。
为什么要这么做的原因就是两点：
1、用户不一定能准确描述自己的需求，或者是用户需求不等于用户的问题。
2、用户的解决方案不一定是最优的。PM就是发现背后的用户需求然后很优雅的解决它。
这就是经常听到PM要去了解用户需求和场景重要性的原因，另外需要注意的是向团队描述需求时，一定要先描述用户的需求和场景，然后在描述解决方案，避免跳过这步直接描述功能需求。否则结果大家都懂得。