产品经理收到需求反馈后，首先要对需求进行分析，评估需求是否合理。
如何进行需求分析？可以通过下面三个问题来进行
需求三问
第一问，需求从哪里来，到哪里去
需求是谁提的，要实现什么效果，真正需求是什么？
接到需求后，首先要搞清楚需求的来龙去脉，问清楚具体要做什么，找到用户的真正需求
第二问，需求有没有问题，有没有更好的解决方案
用户反馈的需求，是用户遇到问题时，自己想到的解决方案。但用户的想法可能不是最优的，甚至是错的。
产品经理需思考用户需求是否合理，有没有其他更好的解决方案。
试想如果在马车时代，我们找用户调研需求，用户会反馈需要跑的更快的马，跑的更持久的马，更舒适的马鞍，是调研不出来汽车的需求的。
第三问，需求上线后，有哪些影响，可能引起哪些问题
最后一问，需要我们想清楚需求上线后有哪些影响，可能引起哪些问题。
对于这些问题和影响，需要提前想好应对策略，做好预案，必要时作为需求点，放到原需求里面一块实现，整体上线。管理好各方预期，避免届时被动。
案例
案例一
用户找到产品经理，说我想要一把锤子和一颗钉子。
需求第一问，为什么要锤子和钉子，是为了做什么？
用户说自己买了一副画，我想把它挂到墙上
通过分析，可以发现用户的真正需求是“把画挂到墙上”。
需求第二问，有没有更好的解决方案
用户希望用锤子和钉子把画钉上去，这个方式真的是最好的吗？我给用户一些胶带，粘贴上去是不是更好？我给用户一些图钉，是不是更容易把画挂上去？
需求第三问，当前的方案实施后可能会有哪些问题，需不需要提前准备
如果最终采取了胶带粘贴的方案，胶带粘贴可能不够牢固，需要提醒用户把画的四角都粘贴一下。
至此，用户需求方解。
案例二
这是笔者实际工作当中遇到的一个真实案例。
在某电商独角兽公司，有一天业务运营人员邀请产品经理讨论一个需求
运营H同事：我们想让研发做几个活动模板，以后做活动时，配置下模板，就能上线活动
思考：需求第一问，为什么要做模板，希望解决什么问题，达到什么效果
产品经理：为什么要做模板，是为了解决什么问题
运营H同事：我们经常做活动，比如品牌日、热点专题、促销、秒杀等，几乎每天都要做新的活动。每次做活动，都需要技术排期开发，周期比较长，而且研发资源就那几个人，经常有些活动想做但排不上期。
思考：运营同事提出做模板，是为了解决日常活动与研发周期长的矛盾，这是用户的真正需求。
需求第二问，做模板能解决用户的问题吗？
产品经理：你现在想做哪些模板
运营H同事打开电脑，把想做的模板展示了出来，有热点专题模板、秒杀模板、全球好点模板、镇店之宝模板等
产品经理：你们最近半年都做了哪些活动，活动页面还有吗？能发我看看吗？
运营H同事找了下历史活动资料，把历史上的活动页面发了出来
思考：通过对比用户要做的模板，和历史上的活动页面，我发现一个问题，多数情况下，同一个类型的活动页面，每次都不是完全相同的，每次都有一些小差异，样式上都有一些小调整，有时候还会出现完全不同的新页面。如果做了模板，以后运营人员可能会经常要求修改模板样式，或者做一套新的模板出来，技术可能会陷入无尽的模板修改中，这个方案不能彻底解决“运营做活动与研发排期”的矛盾。
本次需求沟通结束，产品经理已经拿到了用户需求，先散会，产品经理后面再想想解决方案。
会后我想到了自己以前在京东做开放平台时，遇到的店铺装修项目。京东把店铺页面开放出来，商户可以自己定义店铺页面。通过调研，我发现这个方式可行，于是决定采取这个方案。
后续又和运营、技术沟通了下这个方案，最终发现这个方案比较复杂，研发周期比较长，但是业务方很着急，马上要搞大促了，于是决定采取一个简化的方案。把页面元素抽象成各个组件，组件分为数据、样式两部分，让运营人员像搭积木一样，自行搭建活动页面。和运营、技术沟通后，发现这个方案既操作简单，研发周期也比较短，最终决定采取这个方案。
需求第三问，当前的方案实施后可能会有哪些问题，需不需要提前准备
最终方案为了缩短研发周期，在组件排序上，采取了一种逐个点击上下移动的方式，这个可能会影响运营人员的操作效率，引起对方吐槽。
于是，提前和业务运营同事反馈清楚，为了在你们期望的时间内上线，排序操作只能先这样，可能用起来会麻烦些，一期上线后，立即启动优化（后面也确实印证了这个问题，一期上线后，运营妹纸多次跑到我面前说“哪天我们眼睛瞎了就赖你”，逐个点击上下移动，确实太费眼力了）。
至此，用户需求有了比较完善的解决方案。
系统上线后，运营人员平均每个工作日创建30多个活动页面。该系统不仅有效的释放了研发资源，还解决了日常运营做活动的瓶颈。获得了运营人员的高度称赞，多次受到COO的嘉奖。
