话说产品方法论——需求与用户研究

开一个坑，结合自身经历和现在在看的一些书，将一些基础的产品方法论总结出来，与大家交流的同时鞭策自己。

作为0岁的产品经理，我们在学习产品方法论时，容易偏重于产品设计的理论，对产品设计的喜爱也许是多数同学想成为产品经理的动机，然而在实际的业务场景中，需求的采集和挖掘是绕不开的话题，而且是极其重要的一环。今天简单讨论一下需求采集模型——Z模型，也算是开坑大吉了。我首次见到Z模型是在苏杰的《人人都是产品经理2.0》一书4.1节，推荐大家阅读这本书，条理清晰，也有案例，生动有趣，实在是产品经理入门宝典，适合入行前读，入行后复盘的时候读，以及被裁员之后（狗头）创业读。

1 Z模型

把需求采集方法分四类：说、做、定性、定量。我们不妨先结合自己的感觉和项目经验，想一下这四点对应着什么。

• 说：就是和用户侃，聊；
• 做：就是看看用户是怎么做的，用户的行为，和实际的执行；
• 定性：这个在实际业务场景比较难描述，有时候找用户随便聊聊就是定性；
• 定量：靠科学的指标/数据来分析问题并给出方案。

《人人2.0》讲到，说的劣势是“耳听为虚”，做的优势是“眼见为实”，因为很多时候用户说的和做的是不一致的，也就是说，用户有可能描述不清楚自己的需求，甚至是不知道自己真正想要的。

我在实习期间负责B端产品的时候感悟尤其深刻，B端产品特别是一些专业性较强的B端产品，如低代码产品，面向的客户/用户往往不具备对应的专业能力，所以他们有时很难表述清楚自己想要什么。

定性研究可以找出原因，偏向于了解，属于个体研究；定量研究可以发现现象，偏向于证实，属于群体研究。
定性的问题是“以偏概全”，你想了解大学生使用课堂在线签到系统的意愿，只采访身边的几位同学，以代表全校乃至全国高校的学生，显然是不科学的，所以要辅以定量，比如在全校各学院收集问卷几千份。但是定量也会“以表为本”，能发现现象，却不知背后的原因。比如我们的在线签到系统上线后，发现6月比5月的月活少了一半，我们就可以从5月活跃但6月不活跃的用户中抽取一些做访谈，了解发生了什么。（网课转线下了？产品不好用，老师都不用了？）

《人人2.0》：产品经理理解用户需求的过程，并不违背人类认知新事物的一般规律——从观点到行为，再从行为到观点，一样会从定性到定量，再从定量到定性，以实现螺旋式上升，使了解和证实在不断迭代中得到进化。

前面图中的四个象限，分别对应上一种需求采集方法，如下图，用户访谈、调查问卷、可用性测试、数据分析（《人人都是产品经理》有详细描述），方法的使用顺序可以画成一个“Z”，这便是“Z模型”。

苏杰参与淘宝产品的完整需求采集过程案例：
►产品规划阶段： 听用户“定性地说”，确定产品方向（做什么）；随机抽样了40个用户做访谈，据此写出需求列表。
►项目早期： 听用户“定量地说”，确定需求优先级（先做什么）；投放了20万份调查问卷，确定了需求优先级的排序。当然，这只是确定优先级的辅助手段，最终做什么，还是由产品经理决定。
►项目实施过程： 看用户“定性地做”，确定要先实现的那几个需求应该怎么做；设计的同时完成可用性测试，其间陆续找了10个用户来验证。
►上线后的优化阶段： 看用户“定量地做”，根据产品的用户使用情况做数据分析，不断地改进产品。
“Z字采集法”也有一个螺旋上升的循环，数据分析以后，通常又会做用户访谈来证实数据分析的假设。

2 需求的三种深度

观点与行为→目标与动机→人性和价值观。
以吃早饭为例对应聊聊。
观点和行为：多数学生们去超市买了牛奶面包，而不是去食堂吃。（用户最直接表现出来的，第二天食堂全去卖牛奶面包了，发现依然没有学生来）这个是浅显的层次，产品经理不能只停留在这个阶段。
目标与动机：学生们为什么这么做？食堂饭比较贵？食堂存在卫生问题？食堂环境压抑等等。产品经理到了这一步依然可以进一步挖掘价值观层面的需求。
人性和价值观：觉得牛奶、面包这种西餐很“潮”，可以让自己更健康更积极，或者是避开食堂的高碳水高盐，瘦下来，在朋友圈展现更好的自己。这些往往是产品最本质的用户价值。

关于需求的探讨，《人人2.0》开端部分就给出了很有意思的漫画：

2.1 马斯洛需求理论

马斯洛需求理论和弗洛伊德本我、自我、超我的理论有很多印证的地方，在做需求的采集或优先级确定时，马斯洛需求理论也可以作为参考。

2.2 人性七宗罪

暴食： 干啥啥不行，干饭第一名。

贪婪： 别管用不用得到，买买买买买。

懒惰： 出门多没劲啊，点个外卖吧！（上门服务应运而生）

嫉妒： XX羊队是第一名。（《羊了个羊》通过排名刺激用户的一种手段）

骄傲： 终于打到荣耀王者了，牛！

淫欲： 刷刷抖音。B站上也有一些擦边视频，正是迎合了这种人性，所以有观众。

愤怒： 键盘侠。

此外还有很多类型的人性，有正面也有负面，比如好奇、同情、从众、恐惧，等等。

3 总结

在实际业务场景中，也不是说一定要死死地套用上述模型或方法，往往都是根据实际情况来，很多时候需求/优先级都是互相讨论、多方协调出的结果。我觉得对于需求采集，某种程度上产品经理还是要“集权”（当然一定要灵活应变），人人都可以采集，但是最好统一交给产品经理来处理，然后大家再探讨。

每日反思：虽然是技术出身，但是就像之前某个mentor告诉我的，技术是我的护城河。诚然，技术是优势，但技术一定不是产品经理的全部，技术产品经理应该多花时间去思考，而不是越俎代庖，去抢可爱的开发天团的饭碗。