第一，过于学术，沉迷于“科学研究”。
我在读研的时候，做的就是统计分析、数据挖掘相关的课题，所以工作中开始
遇到数据分析的时候，我挺兴奋的，感觉可以好好地研究一番了。但渐渐我体会到，
实际的生产和科研是有很大不同的。科学研究通常只注重“性价比”的性，只要结
果好，往往不在乎投入，因为相对而言科研的结果不是为了马上应用，而是为了证
明实力。
但实际生产环境就更注重综合的性价比了，所以我们日常的数据分析方法也就显
得不那么严谨了，我特指小步快跑的创业团队，他们可能不需要在每次分析前都去验
证样本群体是否符合某种统计分布，也可能不需要用“人工神经网络”等“高科技手
段”去预测产品将来的用户数，甚至给出“A>B”的结论时也用不着做“显著性检验”，
一切的一切需要的只是一种感觉，一种对数据的敏感，对商业的敏感。
第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。
无意地误读数据，举个例子，对一个人群，人们的身高用平均数来衡量是有意义
的，因为我们知道身高属于典型的正态分布，中间多两边少，所以一个平均值就能了
解群体的大致情况，而对人们的收入，就不能用平均值来衡量了，一个超级富豪和 1000
个零收入的人一平均，很可能得出人均收入 100 万的荒谬结论。这个问题的对策，是
学习统计学的知识 12，努力提高自己的水平。
主动地误读数据，是比较有趣的现象。在提取数据之前，我们心中通常已经有
一些结论了，无非是想验证它，而抱着这点思想，就总能找到数据来证明自己已有
的想法，并且技术越娴熟的人越容易做到这点。对于这点，我想一个简单的对策就
是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益
牵扯，比如为了证明老板的判断，或者为了保持自己之前拍脑袋的英明形象等，你
明白我的意思。
第三，平时不烧香，临时抱佛脚。
12 推荐阅读《黑天鹅》和《统计数字会撒谎》这类统计学的图书，不似教材那般枯燥，适合工作以后的人阅读，附
录中会有简单介绍。
这是一个很实际的问题，我们经常在做决策的时候才想起来数据分析，但忽然发现
手头没有数据可分析。一次又一次地发生同样的情况……为了避免，我们应该在产品设
计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的
登录频率等，这也算一种典型的非功能需求，这样做对产品的可持续发展非常必要。
日志分析的商业价值
下面举个小例子，看看数据分析是如何转化为商业价值的。整体的思路是：在对
产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些
现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终
指导产品发展方向。
2008 年底的时候，我们希望产品的用户能更活跃，活跃的衡量指标是更多的登录
次数，方向确定之后，我们假设有方法可以促使某类用户更多地登录，于是对产品的
用户登录日志13做了一些分析，希望找到方法和对应的用户。结果，发现了一条很有趣
的曲线，如图 2-7 所示。
直接看图，图中的横轴是把所有付费用户的第一次登录日期对齐，表示用户从这
一天开始使用产品，查看他们在此之后半年，也就是 180 天的活跃情况；纵轴是这几
千家公司的总体活跃情况，可以简单的理解成纵轴数值越高，用户登录次数越多。可
以看到，活跃公司比例的变化明显分为 4 期，特别是 1～4 个月之间出现了先下降再上
升的现象，于是我们先尝试着解释：
该产品是通过经销商销售的，在卖出去之后，经销商在前期也会登录产品帮助用
户做一些初始化产品的工作，所以产品的登录行为有经销商登录和用户登录两部分，
虽然通过已有的数据无法区分这两种行为，但它们确实各有特点。
13 因为是企业用户，所以本例中“用户”与“公司”是一个概念。
图 2-7 用户登录产品的情况14
第一阶段：第 1 个月，活跃度考察的是 1 个月内用户的登录次数，所以 30 天内活
跃度不断上升达到峰值，约 60%。这段时间内，经销商登录次数较多，帮助用户初始
化，用户的登录次数缓慢增加。
第二阶段：1 至 3 个月，活跃公司比例缓慢下降到约 40%，其间包含两部分，经
销商行为和用户行为：
. 经销商登录次数逐渐减少，只有一个趋势：衰减，这个衰减绝对比图中的更陡峭；
. 用户登录行为有两种趋势：衰减与增加，而增加是大于衰减的，从第三阶段可
以看出；
第三阶段：3 至 4 个月，活跃公司比例逐渐上升到 60%，这是因为到 3 个月之后，
几乎再没有经销商登录行为了，完全是用户登录，并且经过 3、4 两个月的使用，用户
已经通过产品体会到实际的商业价值，所以登录产品并使用的行为越来越多；
第四阶段：4 个月以后，稳定在 60%弱一点，进入动态平衡期，用户使用产品的
情况不再有大变化。
14 这次的数据分析是我用一款工程软件——Matlab 做的。这完全是个巧合，正好上学的时候一直拿它做数据挖掘。
常有这种体会，之前学过的东西，当时不知道有什么用，多年以后说不定什么地方就真的用上了，很惊喜。所以
早年的学生时代，当你还没想清楚将来要做什么的时候，也就意味着不知道应该学什么，也不要就真的一直空想
而什么都不学，不妨先学着别人安排你学的东西，等想清楚自己的目标以后，再优化自己的知识结构。
上面这些解释，完全是我们根据对用户的认识，主观做出的判断，为了验证上述
观点，接下来我们做了用户访谈，采取了两种形式——先电话调研、然后有选择的登
门拜访，试图区分出经销商登录和用户登录的不同，果然让我们发现，两种人群的主
要登录入口不同，经销商通常从 A 入口登录，因为他们要做的初始化操作从这里进去
方便，而用户通常从 B 入口登录，因为日常操作更多在这里。
由此启发，我们深挖了一段时间从不同入口登录的日志，确实验证了用户的说法，
于是，分离出经销商和用户两种登录行为造成的曲线，我给出了简单的手绘，如图 2-8
所示。
图 2-8 用户登录与经销商登录
好，接下来问题就来了，这么“劳民伤财”的分析，是玩儿的么？商业价值呢？
有两点。
一方面，我们会考核每个经销商下面的用户活跃度，目的当然是为了让他们更多
地服务用户，指导用户使用以促进活跃，但有的经销商会耍小聪明，通过自己登录来
忽悠我们。原来我们很苦恼，现在可以通过登录行为的分析，对这种情况做一个初步
的判断，事实上我们后来就对不同入口的登录行为、同一台电脑登录多个用户账号的
行为做了跟踪，如果某些用户登录次数的增加是以 A 入口为主，或者是某时间段同一
台电脑登录多个用户账号，再关联这些用户的经销商进行分析，就能够找出作弊的经
销商，以示惩戒，至少，也可以增加经销商作弊的成本。
另一方面，这次分析告诉我们，对我们有实际意义的是 B 入口用户的登录，所以
产品的优化重点应该放在 B 入口，另一个数据也证明了上面的推论：有某种登录行为
的群体，在出现该行为后几个月的活跃度情况如表 2-1。基本上只要出现过“B 入口登
录”，之后用户的活跃度就会很高，是真正的用户登录。事实上，这次数据分析指导了
产品改进，后来，我们对 B 入口登录做了很多引导，比如降低门槛，运营推广，在宣
传手册、光盘上重点说明，等等，起到了很好的效果，用户活跃度真真切切地上去了。
表 2-2 登录行为与若干月后的活跃度关系
出现某种登录行为的群体
1 月后
2 月后
3 月后
A 入口一周内登录>=2 天
68.70%
56.80%
58.10%
A 入口两周内登录>=8 天
92.00%
81.80%
78.10%
B 入口一周内登录>=2 天
95.40%
91.20%
87.10%
B 入口两周内登录>=8 天
99.60%
96.40%
94.40%
说点题外话，上述的访谈过程，我们抽取了近 100 个样本，电话有效沟通了 30 多
例，上门拜访了 10 例，行业涉及机械、纺织、五金、建筑、服饰等，比较全面，考虑
到上门成本问题，所以只在杭州、常熟两地进行。从决定调研开始，连前期的准备、
后期的总结，估计总共花了 15 人天，也就是两个人一周半的时间。整理报销费用的时
候，我简单算了一下，给上门的用户礼品平均每家 50 元，差旅费用，在选了本地和附
近用户的基础上，均摊到每家，大约 150 元，人力成本 1 人天粗略记为 500 元，平均
分摊给最终上门的 10 家用户，每家大约要 1000 元人民币，不算不知道，确实挺贵的……
这还只是很简单的调研，所以用户研究的成本真的很高，很多小公司都能省则省，我
们很无奈，老板也很无奈，以后在抱怨老板没用户研究意识的时候，也需要体谅一下
他们的难处。
2.2.5 需求采集人人有责
上面用很大篇幅说了一些常用的需求采集方法，这一节，我想先抛出一个“一手
需求与二手需求”的概念，有个很形象的比喻就是“生孩子与养孩子”，话糙理不糙，
我们内部经常这么说。
我们首先把“生孩子”——需求采集视为己任，人人有责，希望所有人都参与，
都来“生孩子”，我们帮大家养，这就要给他们一个简单的“生孩子”的工具——“单
项需求卡片”，最后，简单介绍一下其他常用的方法，这样才能做到“尽可能多地采集”。
生孩子与养孩子
之前所述的各种方法，都是直接从用户那里得到需求，我称之为一手需求，就像
“生孩子”。其实很多时候，我们还会接受二手需求，比如老板说要给用户做个××功
能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来，就像“养孩子”。
“生孩子”，更多的时候发生于新产品诞生前，这时候外部没有用户、内部没有运
营、销售、服务等，所以对于需求而言，更多的是产品人员驱动，去主动采集需求，
比较常见的就是直接去潜在的目标用户那里采集。这个从无到有的过程，个人觉得发
挥的空间最大，是最有成就感的。
小明：“还是‘生孩子’好啊，痛并快乐着……”
而“养孩子”，通常是产品已经运行了一段时间以后，用户也有了，公司内部也多
了很多相关的人员，比如销售和服务。虽然产品部门与用户的直接接触变少，但多了
很多间接来源，即与终端用户接触的干系人，他们会向你反馈很多需求，而用户也开
始主动提出需求了。
对比一下，生孩子的时候，我们去主动“拉”需求的比例较高，需求都是直接从
用户那里得到的，有点“进攻”的感觉，而孩子生出来以后，就不再是你一个人的孩
子了，必然是大家一起养，所以我们需要照顾的各方各面也会更多，我们会收到很多
“推”过来的需求，比较像“防守”的感觉。
有很多同学从一开始工作接触的就是已经存在的老产品，需求始终堆积如山，如
果碰上销售强势的产品，那更是连响应销售提过来的需求都来不及，也许做了半年一
年，突然回想，发现自己连真正的用户都从来没接触过，而是始终在满足销售的需求。
个人感觉，这种二手需求，或多或少有扭曲，以销售为例，他们的考核指标决定了会
比较注重眼前，希望产品的卖点越多越好，而之后用户用得如何，就不那么关心了。
比如我就经历过一些让人很抓狂的二手需求，销售希望产品增加一个功能，这个功能
在说服客户购买产品时有“临门一脚”的作用；而用户买完以后，最好又别用这个功
能，以免增加服务部门的压力……所以在公司层面上看，我觉得产品部门至少应该和
销售、服务等部门有平等的地位，坚持不断的从终端用户那里直接获得需求，才能保
证产品的可持续发展。
但二手需求毕竟是常态，我们经常接到的就是口头上的几句话，或者一封邮件的
几行说明，这中间理解的偏差只能靠我们主动的、反复的沟通来弥补，那么有没有什
么办法解决呢？下面我就介绍一种简单的二手需求采集工具——单项需求卡片。
单项需求卡片
单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及
产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干
系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员
的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，
比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间。
一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景，
谁在什么时间、地点产生了何种需求，先看一个模板，如表 2-3 所示。
表 2-3 单项需求卡片模板
需求编号（可由需求人员填写）
需求类型（可由需求人员填写）
包含“采集时刻 + 采集者”信息
功能需求、非功能需求等
来源（Who）（重要信息，方便追根溯源）
产生需求的用户：最好有该用户的联系方式等信息
用户背景资料：受教育程度、岗位经验，以及其他与本单项需求相关经验
场景（Where、When）（重要信息，用来理解需求发生的场景）
产生该需求的特定的时间、地理、环境等
描述（What）（最重要的信息）
尽量用（主语+谓语+宾语）的语法结构，不要加入主观的修饰语句
原因（Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的）
为什么会有这样的需求，以及采集者的解释
验收标准（How）
需求重要性权重（How much）：
（如何确认这个需求被满足了）
1. 尽量用量化的语言
2. 无法量化的举例解释
满足后（“1：一般”到“5：非常高兴”）
未实现（“1：略感遗憾”到“5：非常懊恼”）
需求生命特征（When）
需求关联（Which）
1. 需求的紧急度
2. 时间持续性
1. 人：和此需求关联的任何人
2. 事：和此需求关联的用户业务与其他需求
3. 物：和此需求关联的用户系统、设备，以及其
他产品等
参考材料
竞争者对比
在需求采集活动中的输入材料，只要引用
一下，能找到即可
按照“1 分：差”到“10 分：好”进行评估：
1. 竞争者对该需求的满足方式
2. 用户、客户对竞争者及公司在该需求上的评价
由于填写卡片的人经常不是专业的需求人员，所以卡片的质量无法保证，比如下
面这个例子就是一个典型（如图 2-9 所示）。
图 2-9 单项需求卡片实例
上图是工程师提的一个需求，就像我们永远无法猜到用户会怎么使用我们的产品
一样，“单向需求卡片”原本是让大家给产品提需求，而工程师却拿它来给产品经理提
意见，很有意思。从表格的填写就可以看出来，实际工作中我们能拿到的都是填写不
完整的，甚至是字迹难以辨认的，当然，也可以尝试电子版，那样我们整理的成本低
一些，不过很可能愿意填的人就少了。但我们心里得有个底线，一张有价值的单项需
求卡片，至少得有“需求描述”，需求编号、来源、场景最好也能有，其他的，其实很
少有人愿意填写了。
回到这张卡片，工程师描述的一个需求也很有意思，值得我们共勉——“PD 慎重
地考虑一些细节的改变，在没有大影响的前提下，不要对稳定的版本做一些鸡毛蒜皮
的动作”。工程师们也希望自己做的事情都能产生商业价值啊。
每当我们拿到这样的卡片，就需要主动去和提交人交流，完善卡片的内容。真实
的工作中你能体会到，这张卡片只是需求过程的中间产物，所以我们在这上面花费的
精力也是尽量缩减，单向需求卡片所描述的用户需求，最终要转化为产品需求才有真
正的价值。
尽可能多地采集
需求采集，并不是产品设计之前的工作，而是一个贯穿始终的过程；它并不是产
品人员的事情，而是所有人的责任；它没有特定的方法，不管白猫黑猫，抓到老鼠就
是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求……这才是需求采集
的大生产运动。
最后再简单分享几个有特点的需求采集方法，希望大家能灵活应用，尽可能多地
采集。
现场调查。说简单一点就是打入“敌人”内部，和客户一起工作一段时间，深度
了解需求。它是一种典型的定性分析，持续时间长，从几小时到几个月，既能听到用
户怎么说，也能看到用户怎么做，不过受众面极其狭窄，一次只有一个，要特别小心
被“非典型”用户带到沟里去。
AB 测试。基于大用户量比较合适，比如有一个按钮不知道是放页面的左边好，还
是右边好，而我们有 10 万用户，那就先随机挑选少量的用户发布这个按钮，1000 人放
左边，另外 1000 人放右边，然后过一段时间分析结果，再决定剩下的 98%用户该怎么
办。很明显，这也是让用户直接参与了设计，这样低成本的方法让很多传统行业的同
学羡慕不已。
日记研究。互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的
朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要
明白日记的作者往往是同行，而不是主流用户。
卡片分类法。我们把产品的各种需求写在便利贴上，让用户一起讨论并完成分类。
这能让你深入了解用户是怎么给产品划分模块的，用户认为这个网站应该是什么结构。
因为产品设计人员的思维和用户的思维通常不一样，这也就导致了如果是产品设计师
来单方面决定网站结构的话，很可能导致用户理解的困难，所以卡片分类法能让最终
的产品更加符合用户的心理模型。
自己提需求。这是最简单的方法。每一个靠谱的产品都会有一群粉丝用户，不用
你去找他们采集需求，他们也会给我们惊喜，主动提出很多需求，作为产品的主人，
我们好意思还没有用户了解产品么？产品要用才能感觉出好坏，特别是自己做的产品。
产品做多了，我们随便看看别人做的产品，总能一下子挑出很多问题，提出很多需求，
反过来看自己的产品越看越完美，这一定有问题，所以必须用自己的产品，最好是发
动认识的人都来用。
需求采集的各种新方法层出不穷。和学习任何领域的知识一样，建议大家在了解
知识框架后，坚持“需求驱动学习”。
2.3 听用户的但不要照着做
采集了很多需求，但是一团乱麻，从哪里着手？
用户都帮我们想好该怎么做了，照他说的做么？
在开始需求分析之前，我们先回到 2007 年 7 月——我写了一篇里程碑意义的博文，
是《产品设计体会》的第一篇，也可以看作是为这本书写的第一笔。
2007 年 6 月 28 日，网店版 2.0 上线，这是我主导的第一个付费产品，之后的三周
我基本天天都会在淘宝论坛上泡不少时间，最大的体会就是：要听用户的意见，但不
要照着做。
有的用户很“危险”，在提意见的同时还说你们应该做成什么样子，这时候产品经
理一定要头脑清醒了，用户提的解决方案往往是站在自己的立场上的考虑的。比如对
“快递单打印”的功能，用户提出要添加一个他经常用的小快递公司的快递单模板，
而我们会发现，这家快递公司可能只是一个区域性的快递，最终的解决方案是做了一
个“自定义快递单”的功能。
有时候，用户给出的做法存在明显的逻辑矛盾，就算他给出的解决方案合理，也
要再深挖用户内心根本的需求，比如用户描述“新建非支付宝交易订单的时候必须要
选择用户不合理，希望能自己填写客户”。这里更深层的需求就可能是他需要把线下客
户也管理起来，所以我们或许更应该做一个新增线下客户的功能，而不是在新建非支
付宝交易的时候让用户自己填写客户姓名。
我们是产品经理、产品设计师，最终怎么做应该由我们决定。
2.3.1 明确我们存在的价值
用户跟福特要一匹更快的马，福特却给了用户一辆车。
这就是我们存在的价值。还记得小明么？
他说他需要一个电钻，这是他提出的解决方案，但在大毛的刨根问底之下，发现
小明其实想要的是一种温馨的家的感觉，有了这个认识，我们就可以给出很多产品来
满足。比如卖他一套实施方案，带着电钻、油画，上门安装；比如用背面有强力胶的
钩子挂画；比如直接把画黏在墙上；比如直接在墙上画，并且让小明自己画；再比如
放一组书架在那里……经过我们分析得到的解决方案，比起小明自己说的，优势就在
于可能省了钱、省了时间、更温馨，等等。
对同一个问题，这两套解决方案的区别就是，一个是用户需求，一个是产品需求。
而这中间的转化过程，就是这节的主题——需求分析。
用户需求 VS.产品需求
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需
求的过程。
听到过一个说法，说需求分析与常见的技术分析最大不同是思路的本质差异，技
术分析是“树干——树枝——树叶”的任务分解过程，技术人员很适应并乐于用这种
方式思考，可以把大问题分解成小问题，发现难点逐一攻克。不少需求人员都是做技
术出身的，所以开始往往会用这种思路做需求，听到客户提出的功能点，直接想怎么
做系统设计了，这导致有时候需求分析甚至已经越俎代庖到“详细设计”的职责了。
大多数人在生活中也习惯于用这样的思路来对付问题，而真实情况是，需求分析是“首
先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完
整的需求分析是一个“分-总-分”的过程。一方面不能漏掉提炼用户需求的这个过程，
目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，
后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解
成树枝、树叶。
小明又出现了，这次他说要吃猪骨头火锅（用户需求），80 块吧，但没想到又碰到
了大毛。
“真的想吃？”
“想吃！”
“为什么？”
“我饿了……”（找到了本质！）
