马斯洛需求层级理论也好，Y *** 论、Z *** 也好，归根到底都是一些思考框架和 *** ，如何把握需求、提炼需求，还是需要我们在真实的环境中多聊、多看、多做。

无论是市场营销还是产品设计，“需求”这个词，是最频繁被提及的词汇。

在市场营销领域，无论是新的产品的研发设计，还是制定推广活动方案，我们需要做的是“消费者洞察”。所以市面上有大量的调查公司，帮助品牌通过问卷、焦点小组访谈等方式，收集用户反馈，以求获得insight。

近些年，随着互联网行业兴起和产品经理岗位的火热，“需求”一词有反复被提及，需求分析成为产品经济的必备技能之一；在“人人都是产品经理”上搜索8,226条结果。

马斯洛需求层级理论也好，Y *** 论、Z *** 也好，归根到底都是一些思考框架和 *** ，如何把握需求、提炼需求，还是需要我们在真实的环境中多聊、多看、多做。

需求的之一个层次：需求的忠实记录者

腾讯推崇产品文化，其有一个著名的「10/100/1000法则」：即每位产品经理每个月必须做 10 个用户调查，关注 100 个用户博客，收集反馈 1000 个用户体验。

于是，很多产品经理，特别是刚刚进入产品领域的新手，每天将“用户需求”、“使用场景”这些词挂在嘴边，并践行腾讯的「10/100/1000法则」，每天都在记录用户的反馈和槽点。

能坚持倾听用户反馈并记录用户需求，固然不错，然而这还不够。

举一个小例子。早些年，针对B端广告主 *** 视频素材的需求，做了一个小工具，小白用户选定模板之后按规定上传图片或者视频，就可以渲染出一支质量还凑合的视频，并且可以直接推送到投放后台。然而，很多广告主在后台留言，希望能开放下载功能。这个时候，我们就面临着一个选择：是否需要开放下载？

需求的第二个层次：需求的挖掘机

多问一句Why，发掘需求背后的动因。通常情况下，用户通过语言或者文字表达出来的，只是最直接的功能指向。

每一个功能指向背后，都暗藏着一个 *** 因素，这个 *** 因素才是用户真正希望解决的问题。如果不能挖掘出需求的来源，那么产品经理基于此设计的解决 *** ，也不会真正解决用户问题，或者给用户的解决办法不是更优解。

接着上文提到的开放视频下载功能为例。用户希望下载视频，而不是我们此前设定的生成→推送的使用路径，必然是在这个链路中某（几）个出了问题，并提出了以下2个假设：

视频质量不及用户预期，用户下载下来之后，会进行重新剪辑；

视频推送到投放后台的时候有问题，导致用户希望绕过这条链路。

针对之一个问题，我去看了用户最后使用的视频素材，发现并没有二次加工的痕迹，即下载下来的视频是什么样，在投放时还是什么样。也就是说，视频质量并不是造成用户希望开放下载的原因。

于是，我找了有类似需求的用户一一聊，问他们下载下来之后，会有哪些操作。

答案竟然出奇的简单：下载之后，对视频重新命名，然后重新上传，因为在投放后台中视频素材量级非常大，之前推送之后，经常无法跟已经在库中的视频区分开来。

需求的第三个层次：系统地思考需求

每一个产品都可以视作一个小的系统。系统由元素、元素间的关联和目标构成。

当我们收集需求的时候，更多地是在关注元素，经常会忘记元素间的关联和整个产品的目标，也即“一叶障目，不见泰山”。

我们针对用户的反馈，做出了完善的解决 *** ，然而基于该 *** 的功能上线之后，会不会影响到其他功能？会不会有其他连锁反应？

苹果一向被视作设计的标杆。然而其一款鼠标的充电口却在鼠标下方，导致充电的时候无法正常使用。当然，有些人视作是为了追求极致的美观，但是牺牲用户体验的美观，是否是更优选择？

再比如我们经常吐槽的家庭中的插座，两孔与三孔的插孔经常不能同时使用。

上次我在 *** 时，吊起某支付软件时，我突然想起要买另外一个商品，于是双击Home键想回到电商App中，结果指纹识别成功成功付款了。

这样失败的案例不胜枚举。

这里额外啰嗦几句。现在互联网产品中的分工越来越细致，一款App会按照功能模块进行拆解和分工，每个功能点都有专门的人负责。细致分工的好处是，每个功能点的体验都可以做到机制，然而如果没有一个产品整体负责人进行整体把控，是否一定能保证1+1>2？