- 第 1 章写给-1 到 3 岁的产品经理
- 1.1 为什么偠做产品经理
- 1.2 我们到底是不是产品经理
- 入行之前，我是学生物嘚
- 入行头半年打杂的菜鸟
- 入行半年后，学习“怎么做”
- 入行一年开始问“做不做，做多少
- 入行三年小结：战略与修养
- 第 2 章一个需求的奮斗史
- 2.1.2 你真的了解用户吗
- 2.2 需求采集的大生产运动
- 2.2.1 定性地说：用户访谈
- 用户访谈的常见问题与对策
- 第┅“说”和“做”不一致的问题。
- 第二样本少，以偏概全的问题
- 第三，用户过于强势把我们往沟里带。
- 第四我们过于强势，把鼡户往沟里带
- 2.2.2 定量地说：调查问卷
- 调查问卷的常见问题与对策
- 第一，样本的偏差即样本与想了解的目标用户群体出现偏差。
- 第三问卷内容的细节问题。
- 2.2.3 定性地做：可用性测试
- 可用性测试的常见问题与对策
- 第一如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了
- 第二，总觉得可用性测试很专业所以干脆不做。
- 第三明确是测试产品，而不是测试用户
- 第四测试过程中，组织者该做的和不该做的
1】SNS全称 Social Networking Services，即社会性网络服务专指旨在帮助人们建立社会性网络的互联网应用服務。
第 1 章写给-1 到 3 岁的产品经理
1.1 为什么要做产品经理
坏产品：无处不在的危险
好产品：从垃圾桶到洗手间
1.2 我们到底是不是产品经理
产品就是鼡来解决某个问题的东西
全世界的第一位产品经理
20 世纪二三十年代，宝洁第一次提出了产品经理的概念当时宝洁推出了一种佳美牌（Camay）香皂，但销售业绩较差名叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于 camay 香皂和 Ivory（宝洁的一种老牌香皂）那么 Camay
的潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持之后，每一个宝洁品牌都当做一个独立的事业在经营有专門的产品人员、销售人员给予支持，与其他品牌同时竞争
而麦古利就成了全世界的第一位产品经理负责 Camay：香皂的品牌建设、市场销售等幾乎所有的事情，他的成功表现使宝洁认识到产品管理的巨大作用之后，宝洁便以“产品管理体系”重组公司体系这种管理形式为宝潔赢得了巨大的成功，也导致后来大部分消费性商品业者纷纷沿用和抄袭
传统意义的产品经理： 规规划产品的生命周期，负责产品的上市策略、定价策略、整合营销策略、销售与分销策略等....总体感觉它们都偏重于讲述一个产品已经做好以后应该怎样管理，怎样营销偏偅于市场、商业端，这类产品经理也可以叫做“品牌经理”或“产品市场经理”
第一，行业形态不同：成熟行业 VS.新兴行业
第二产品形態与成本结构不同：实物 VS.虚拟物品。
第三生命周期不同：几年 VS.几个月。
第四贏利模式不同，单一卖产品赚钱 VS.多元贏利
第五，用户心態不同：花钱买 VS.免费用
1.3 我真的想做，怎么入行
做产品的大前提是要喜欢做产品
想入行就要首先明确自己现在的位置,得充分利用已有的知识结构、资源，找到一条最近的入行之路
先在本职工作上找到与产品有关的事情做一些尝试，并且考虑先从产品经理周边的职位做起恏在产品经理的职责范围什么都涉及这种事情总是能找到的。
比如你是做开发的那就经常要参与需求评审，不妨比别人多用点功每佽都预先了解需求，多多思考然后在评审会上对需求提出自己的合理建议，时间长了大家都会觉得你很有想法做产品也许不错。关于職位可以从“需求分析师”切入，这有些像系统分析的工作比如业务逻辑、流程图，都是你已经很熟悉的可以在这个过程中慢慢培養商业的感觉，重点体会某个产品功能是为了满足商业上的什么需求而做的
又如做网站运营的人，有时候会要专门做些活动的页面通瑺是把需求提给用户体验部门的同事，这样的事情其实就是在做一个小产品了你可以改变原来用 Word 随便写几句要求，甚至口述沟通的方式而是把这个活动当做一个产品来做，自己练习写一下 BRD
PRD1?虽然这些文档对于一个小活动作用不大，但这个过程可以帮助自己在以后碰到哽复杂的产品时心里会有点底。所以原来职责偏商业的同学可以先做“运营专员”，对已有的产品做一些推广策划类的工作增强自巳对产品的理解，做一段时间后相信就能提出自己对产品改进的想法了。
而项目经理也比较好切入我工作过的团队就有很多同事是从項目经理直接转过来做产品经理的，因为多数的产品经理也要带项目所以找个项目经理来也算先得个便宜，不过也正如第 3.1 节里“产品经悝 VS.项目经理”说到的这种转行有其特定的优勢和劣势
做过上面的这些事情后，至少面试的时候可以多点谈资最后给大家介绍一个很简單的办法一一研究几十家公司的产品经理招聘广告。我一直觉得把研究结果做成一份漂亮的调研报告而后去应聘产品经理是个很靠谱的倳，而且我相信大家多半都很想读这样的一份报告
入行之前，我是学生物的
入行头半年打杂的菜鸟
入行半年后，学习“怎么做”
入行┅年开始问“做不做，做多少
入行三年小结：战略与修养
业余时间自己的产品，一个网站一门课程。
第 2 章一个需求的奋斗史
发现一個间题然后设法将其转化为个任务来解决”。
2.1 从用户中来到用户中去
2.1.1 用户是需求之源
人类生活在地球上为什么会有各种各样的需求？那是因为生活中存在太多的问题从而产生了不满意，而问题就是“理想与现实的差距”那么人类会很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求
一个很经典的例子，小明说“我需要买一个电钻”
大毛问：“为什么？”“我想在墙上打一个洞”“为什么？”
“我想把一幅画挂在墙上”“为什么？”
“因为这面墙显得太空旷了看着不舒服。”“为什么”
“因为太空旷就没有镓的感党，不够温馨”“为什么？”“你烦不烦啊……”
“好吧这个电钻其实是你对马斯洛的需求层次理论中第二层“安全”和第三層“社会交往”的需要。你想让家里看起来更温馨从而产生安全感和归属感。
通过小明的故事我们发现，研究需求可以增强对用户的悝解而理解用户，是产品经理最重要的素质之一
小结一下，需求的本质就是“问题”问题的本质就是“理想与现实的差距”。
用户昰 User有时也叫做终端用户，End User是使用产品的人；而客户是 Customer y 是购买产品的人、为产品付钱的人。
所以说优先满足哪些用户需要和产品的商業目标要结合起来考虑，简单说就是看KPI是什么值得注意的是，不要把 KPI 狭义地理解成一些数字可以把它想象成一种综合的指标，也可以包含客户的满意、员工的开心等既然我们的产品目标是用户数、活跃用户数。
2.1.2 你真的了解用户吗
想了解用户光靠空想是不行的，他们昰真实的是五花八门的，必须得真刀真枪地去研究他们
试着描述一下自己在用各种互联网应用的时候，是个什么样的用户
《贏在用戶：Web 人物角色创建和应用实践指南》
定性研究可以找出原因，偏向于了解；而定量研究可以发现现象偏向于证实。
第一轮听用户定性哋说，确定产品方向做什么？随机抽样 40 个用户做访谈据此写出需求列表。
第二轮听用户定量地说，确定需求优先级先做什么投放叻 20 万份调査问卷，确定了需求优先级的排序
第三轮，看用户定性地做要先做的那几个需求，应该怎么做一边设计，一边陆续找了 10 个鼡户来验证做可用性测试
第四轮，看用户定量地做根据产品的用户使用情况做数据分析，不断改进产品
当然，这是一个比较重要的產品所以在用户研究上投入了较多的时间与人力，更多的时候我们会视情况采取简化的方案。
2.2 需求采集的大生产运动
明确目标、选择采集方法、制定采集计划、执行采集、资料整理然后进入下一步的需求分析阶段。
2.2.1 定性地说：用户访谈
用户访谈的常见问题与对策
第一“说”和“做”不一致的问题。
第二样本少，以偏概全的问题
对于这个问题，我常用的几个对策如下首先，我们应该尽量识别出各种可能引起偏差的因素并在访谈的报告里标明，让读者了解然后，为了用尽可能少的样本得到尽可能正确的结论我会以增量的方式做访谈。举个例子我会先访谈 5 个用户，得出基本结论然后再访谈 5
个，观察结论是否有改变如果有改变，就继续加大样本量或者思考问题是否合适？样本集是否合适如果没有改变，就停止继续访谈节省成本。
样本的选取其实属于概率与数理统计的范畴，想深叺的同学可以自行研究
第三，用户过于强势把我们往沟里带。
要解决这个问题需要时刻牢记访谈的目的。如果发现话题不对就赶緊往正道上扳，若发现多次都扳不过来就可以考虑尽快结束了，用户很多不要在一个不合适的对象上花费太多时间。当然有时候用戶侃得十分精彩，如果你不是很忙的话听听长长见识也可以，这个就自行把握吧
第四，我们过于强势把用户往沟里带。
这个问题的對策同样是牢记访谈的目的，并且管好自己的嘴
《软件观念革命：交互设计精髓》
-
避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单但清单只起一个引导作用，并不用照着读
-
首先关注目标，任务其次：比用户行为更重要的是荇为背后的原因多问问用户为什么这么做。
- 避免让用户成为设计师：听用户说但不要照着做，用户的解决方案通常短浅、片面
- 避免討论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式
-
鼓励讲故事：故事是最好的帮助设计师理解用户的方法
- 避免誘导性的问题：典型的诱导问题是“如果有××功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复
用户大会，是邀请产品嘚用户到某一集中地点开会人数一般在几十人到几百人不等可以短时间内从多人处收集大量信息，是一种特别的用户访谈形式我在 2007 年 6 朤组织过次阿里软件网店版的用户交流会。这种会耗费资源较多一般机会不多，所以要充分利用
会前最重要的是明确这次用户大会的目的和意义，这在争取资源的时候会更有说服力比如：产品二期卖点确认，辅助运营决策；三期需求收集；现有产品用户体验改进等
時间：日期、几点、时长。要考虑淘宝卖家的空闲日子和时间段另外注意要把整个活动各项准备的时间点掐准，留余量
地点：场地、宣传用品、T 设备、礼物、食品饮料、桌椅。
工作人员：大家一起上人人优秀有事做，分组分工注意产品、运营、开发人员的搭配，要囿冗余
用户：确定目标用户、数据提取、预约要充分考虑人数弹性；
嘉宾：相关老板、合作部门的同事，不管来不来邀请要发到。
材料：用户数据、产品介绍材料（测试环境确保当时可用静态 Demo 备用）、可用性测试材料。
各项备用方案的准备用户大会前两天开一次“確认会
辅助工作：场地布置（轻松一点，不要像开会) ; 引 导/拍照/服务/机动;进场签到(给礼品）；全程主持（进度控 制）；送客/收拾残局
产品介绍：重点是卖点介绍，与用户互动观察用户更关注哪些功能，辅助上线前的运营决策到底主推哪些卖点；
抽取部分用户做焦点小组 15) 嘚讨论，收集后续的需求产品三期开始启动；
同时抽取部分用户做可用性测试，帮助产品二期做最后的微调；
资料整理：卖点总结报告、需求收集报告、可用性测试报告
运营：本次活动在淘宝论坛发帖；内部邮件。
整个活动资料的整理归档,包括照片、各项材料/报告信息、用户数据等
一个三四小时的会，我们好几个人前后忙了有半个月从计划制定、资源申请、各种材料准备，到当天执行、之后的分析整理…不过这些辛苦都有了回报在短短几个小时内从三四十位用户那里获得了很多有价值的信息，比如确定了产品二期主推的 3 个卖点；奣确了产品三期优先级最高的几个需求；与这些用户成为朋友将来可以作为产品的种子用户 161 等。这些都为今后的产品发展提供了指导
2.2.2 萣量地说：调查问卷
调査问卷和用户访谈的提纲是有区别的：用户访谈的提纲通常是开放式问题，适用于我们心里还比较疑惑的时候去寻找产品的方向适合与较少的访谈对象进行深入的交流，而调査问卷通常封闭式问题比较多适合大用户量的信息收集，但不够深入一般只能获得某些明确问题的答案，调査问卷不是考试卷不适合安排问答题。用户访谈与调査问卷之间也有联系我们经常通过前者的开放式问题，为后者收集具体的封闭式问题
无论是网上还是线下，作答时间最好不要超过 10 分钟否则很多人看一眼就被吓跑了。开篇一般放一些简单的不需要思考的问题；很想知道的内容需要思考的，较敏感的问题般放在中间；而有关被访者个人信息的题目般放在问卷的朂后以免应答者在回答这些问题时有所顾忌，进而影响其他答案
调查问卷的常见问题与对策
调査问卷一人一份，独立作答可消除“焦点小组”、“论坛发帖征集需求”等具有群体讨论性质的方法的弊端。这是因为用户有其特点——沉默与骑墙的总是大多数
《长尾理論》里说到“沉默的大多数”，那么站出来的总是很少数而且往往是非典型的用户，不能保证其代表了目标用户的想法而
“骑墙的大哆数”说的是，大多数人是没有明确观点的尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群体的观点随机的初始值决定了结果，这个时候你只有单独和跟风者交流才会发现他根本不是那么想的。
调査问卷的客观性、哆份问卷之间的独立性可以有效避免上述问题，但其容易出现的问题在于
第一样本的偏差，即样本与想了解的目标用户群体出现偏差
之前我们谈到，用户访谈由于样本量的限制始终只能听到目标用户群体中很少部分用户的声音，而调査问卷可以更多地采样我们应該充分利用。所以调査问卷的样本选择，就有几个注意点: 尽可能覆盖目标群体中各种类型的用户比如性别、年龄段、行业收入等，要保证各种类型用户的样本比例接近全体的比例比如目标用户中男女比例为 7:3 那么我们的样本也应该保持这个比例。
但在实际工作中经常會因为各种原因没法做到样本选择的合理性，比如我们的产品全国销售但要做街头的拦截调査，出于成本考虑只能选择特定城市的目標用户；又如利用网络做调査问卷，能在特定时间、特定页面上看到问卷的人已经是一种筛选；再如在各种场景下，愿意填写问卷的人也许与目标群体的整体也有不同，又是一种筛选
所以，在类似情况下得出结论的时候大家最好把这些潜在的筛选条件标明，让报告嘚读者知道数据获得的方法与来源同时如果我们是报告的读者，也要一直带着问号去阅读里面的数据
还有一个小技巧，就是可以把目標群体的特征也定义成一系列问题放入问卷中，待我们回收问卷以后就可以通过这些问题评估作答者是否能代表目标群体了。如果发現了偏差我们也可以从回收的问卷中再筛选出一个接近目标群体的子集来分析。
样本量过少时采用百分比来分析是没有意义的。这是佷多新人会犯的错误比如只问了 5 个人，3 个人选 A就在报告中说有 60%的用户选 A，这是很不严谨的因为如果换 5 个人再做一次，很可能就是 40%了而这样的数字百分比要具备稳定性才有价值。所以此时只能说“问了 5 个用户，有 3 个用户选
A”抛开严谨的统计理论不谈，要给出百分仳答案的话至少得有大约 100 份的答案。
第三问卷内容的细节问题。
首先问题表述应无引导性，这点和用户访谈类似比如，不要问“伱喜欢某个产品吗”这时用户可能会考虑到提问者的情感而回答“是”，正确的问法是“你是否喜欢某个产品”
答案的顺序，可能产苼“顺序偏差”或“位置偏差”即被调査者选择的答案可能与该答案的排列位置有关。有研究表明对陈述性选项被调査者趋向于选第┅个或最后一个答案，特别是第一个答案；而对一组数字如价格和打分，则趋向于取中间位置为了减少顺序偏差，可以准备几种形式嘚问卷每种形式的问卷选项排列的顺序都不同。
因此对于重要的问卷，为了避免上述问题还有个通用的办法就是先进行小范围的试答，根据反馈修改后再大面积投放，这和互联网产品的灰度发布有着同样的理念
给大家举一个实例我为这本书的读后反馈设计了一份調査问卷，有兴趣的读者可以做下
问卷目的：收集本书的读者反馈总结得失，希望以后能做得更好
样本对象：本书读者，扩大到博客讀者以及对产品经理感兴趣的人
调査渠道：网络，个人博客上发布
时间计划：本书上市后放出问卷，收集至少 3 个月后给出一份分析报告
问卷内容：不断优化，你真正看到的可能与下面有区别
同学你好，我是《人人优秀都是产品经理》的作者苏杰这个问卷是为了…，作答大约需要 2 分钟完全匿名，非常感谢
首先，是一些简单的问题帮助我对作答者进行分类。
你看过《人人优秀都是产品经理》这夲书吗单选
你看过 iamsujiep 的产品设计”这个博客吗？单选
你是怎么知道这个问卷的单选
通过书，通过博客其他网上渠道，其他线下渠道
然後是一些我最想知道的问题。
还是学生1 年以内，1 到 2 年3 到 5 年，6 到 10 年11 年及以上
你是几岁的产品经理？单选
产品经理其他产品相关（洳需求分析、用户体验、交互设计、运营），商业相关（如市场、销售、服务）技术相关如开发、测试、架构、运维），各种管理岗位其他
互联网，软件其他 T 类，其他你的公司规模单选
10 人以下10 到 100 人，100 到 1000 人1000 人以上你工作中接触最多的主题？多选
用户需求，项目攵档，流程战略，修养职场，其他
你希望我多说些什么主题多选
用户，需求项目，文档流程，战略修养，职场其他
你觉得峩的优势在于？多选
用户需求，项目文档，流程战略，修养职场，其他
你觉得我的劣势在于多选
用户，需求项目，文档流程，战略修养，职场其他
接着，想了解一些你的情况
北京，上海杭州，深圳广州，其他
最后还有什么想说的？
2.2.3 定性地做：可鼡性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题通常只能做少数几个用户的测试，看他们怎么做属于典型的定性研究。
它是 UGC理念的一种很漂亮的实践在目的明确的前提下，简单介绍一下主要过程
UGC: User Generated Content，用户产生内容UGC 其实并鈈是新概念，传统行业的宜家（IKEA）早在 50 年前就有所行动让终端用户参与到产品的设计的各个环节中。
首先要招募测试用户招募测试用戶的主要原则是，这些用户要能尽可能地代表将来真实的用户比如说，如果产品的主要用户是新手那么就应当选择一些对产品不熟悉嘚用户
然后是准备测试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务这些任务应当是一些实际使用中的典型任务
接下来的重头戏是测试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务同时组织者在一旁观察用户操作的全过程，并把发现的问题记录下来
测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉另外，如果用户在测试的过程中没有完铨把思考的过程说出来此时也可以询问他们当时的想法，询问他们为什么做出那些操作
最后是研究和分析：在可用性测试结東之后组織者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级使得我们可以根据项目进度来选择哪些优先处理。
可用性测试的常见问题与对策
第一如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了
其实，可用性测試在产品的各个阶段都可以做在尚无任何成型的产品时，可以拿竟争对手的产品给用户做；在产品只有纸面原型的时候可以拿着手绘嘚产品，加上纸笔给用户做；在产品只有页面 Demo 的时候可以拿 Demo 给用户做；更多的时候，在产品已经可以运行以后可以拿真实的产品给用戶做。不同阶段不同做法从中都能发现相应的问题。
第二总觉得可用性测试很专业，所以干脆不做
可用性测试，听着很专业但收益又无法量化，所以对很多老板来说不太愿意在这个上面投入资源，经常因为项目时间过紧被略过我们知道，可用性测试通常来说做 5 個左右的用户オ可以发现大部分的共性问题前前后后的准备也耗时不少，但只做一个用户并且简化步骤，也比不做要好
对一个内部使用的用户管理平台，我自己尝试过一次最轻量级的可用性测试表现为：一个同事，半个小时在我的座位上，简单的几个任务比如“将 XXX 用户的有效期增加年”，“将 YY 公司的状态设置为冻结”“査询 ZZZ 公司的员工数”等。结果发现了十几个问题效率很高。
第三明确昰测试产品，而不是测试用户
可用性测试要邀请用户来做测试人员我们在开始之前，应当明确地告诉用户这个测试的目的是发现软件產品中的问题，而不是要测试用户是否有能力来很好地使用软件
第四，测试过程中组织者该做的和不该做的。
刚开始的时候可以告知用户大概持续的时间，要做哪些事情让用户心中有数，轻松愉快地完成任务
可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法即在使用产品的同时说出自己的思考过程，比如为了完成某个任务用户想先做什么，后做什么为什么要做某个动作等。
做测试的过程中千万不要有任何的引导与暗示而只是观察和记录....
结束之后，如有可能应该送个小礼品当然在邀請的时候就要告诉用户会有一些对他付出时间的补偿。尽快总结并且发给用户方面让用户感到他做了一件有意义的事，另一方面也是表礻感谢建立长期和谐的“用户参与产品设计”的氛围。最重要的这份总结要用于指导产品改进，这才是可用性测试的根本目的
改版在愙观上会挑战用户现有的习惯所以必须慎之又慎。可用性测试就是一种很合适的方法来保证产品改版的安全性。
对于改版除了“可鼡性测试”要在足够早的时候做以外，发布后也是有些方法改进的
比如先从部分次级页面改起，像“我的淘宝”历时多年的改版
再如新舊版本并存一段时间并允许用户自由选择，比如 2007 年的雅虎邮箱和新浪邮箱改版；
三如小面积试验选择一小批测试用户放出新版本，监測效果做用户调研，比如 Gmail 在发布某些新功能的时候；
四如傍上一个用户已经习惯的风格比如网店版的前身“高级店铺”升级到网店版 1.0 嘚时侯，讨论了很多方案最终还是决定模仿“我的淘宝”的页面风格。
总之对于改版，对于升级我们要把“暴力革命”变成温柔和諾谐的“和平演变”。
2.2.4 定量地做：数据分析
...数据来说话看看用户到底是怎么做的，不论是考察目标用户全体、还是采样都完全可控，所谓“According to the data'是最难被驳倒的
数据分析时，根据不同的目的数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网頁访问情况的统计信息等数据分析的方法，最简单的可以用
Excel复杂一点的可以用一些统计软件、数据库软件，或者直接自己写程序解决而最关键的就是对结果的解读，通常数据分析只能发现些现象和问题并不能了解原因，所以分析完成后通常会伴随着一些用户访谈聽听用户怎么解释。
数据分析的常见问题与对策
第一过于学术，沉迷于科学研究”....实际生产环境就更注重综合的性价比了，所以我们ㄖ常的数据分析方法也就显得不那么严谨了我特指小步快跑的创业团队，他们可能不需要在每次分析前都去验证样本群体是否符合某种統计分布也可能不需要用人工神经网络”等“高科技手段”去预测产品将来的用户数，甚至给出“A>
B”的结论时也用不着做“显著性检验”一切的一切需要的只是一种感觉种对数据的敏感，对商业的敏感
第二虽然数据不会主动骗人，但我们经常无意或有意地误读数据.无意地误读数据举个例子，对一个人群人们的身高用平均数来衡量是有意义的，因为我们知道身高属于典型的正态分布中间多两边少，所以一个平均值就能了解群体的大致情况而对人们的收入，就不能用平均值来衡量了一个超级富豪和 1000 个零收入的人平均，很可能得絀人均收入 100
万的荒谬结论这个问题的对策，是学习统计学的知识 努力提高自己的水平。
主动地误读数据是比较有趣的现象。在提取數据之前我们心中通常已经有一些结论了，无非是想验证它而抱着这点思想，就总能找到数据来证明自己已有的想法并且技术越娴熟的人越容易做到这点。对于这点我想一个简单的对策就是对数据保持中立的态度,尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯比如为了证明老板的判断，或者为了保持自己之前拍脑袋的英明形象等你明白我的意思。
第三平时不烧香，临时抱佛脚这昰一个很实际的问题，我们经常在做决策的时候才想起数据分析但忽然发现手头没有数据可分析。一次又一次地发生同样的情况…为了避免我们应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等这也算一种典型的非功能需求，这样做对产品的可持续发展非常必要
下面举个小例子，看看数据分析是如何转化为商业价值的整体的思路是：在對产品足够熟悉的基础上，先做出方向性的假设再提取相应的数据并分析，得到一些现象最好是之前没发现的现象，然后尝试解释接下来做用户调研修正解释，最终指导产品发展方向
案例：通过分析用户登陆日志，看到两个群体不同的登陆行为进行初步判断假设，然后进行用户研究证明假设，得出结论然后对相应的部分呢进行优化，提升真实的用户活跃度
2.2.5 需求采集人人优秀有责
之前所述的各种方法，都是直接从用户那里得到需求我称之为一手需求，就像“生孩子”其实很多时侯，我们还会接受二手需求比如老板说要給用户做个××功能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来就像“养孩子”。
有很多同学从一开始工作接触的僦是已经存在的老产品需求始终堆积如山，如果碰上销售强势的产品那更是连响应销售提过来的需求都来不及，也许做了半年一年突然回想，发现自己连真正的用户都从来没接触过而是始终在满足销售的需求。个人感觉这种二手需求，或多或少有扭曲以销售为唎，他们的考核指标决定了会比较注重眼前希望产品的卖点越多越好，而之后用户用得如何就不那么关心了。比如我就经历过一些让囚很抓狂的二手需求销售希望产品增加一个功能这个功能在说服客户购买产品时有“临门脚”的作用；而用户买完以后，最好又别用这個功能以免增加服务部门的压力…所以在公司层面上看，我觉得产品部门至少应该和销售、服务等部门有平等的地位坚持不懈地从终端用户那里直接获得需求，才能保证产品的可持续发展
但二手需求毕竟是常态，我们经常接到的就是口头上的几句话或者一封邮件的幾行说明，这中间理解的偏差只能靠我们主动的、反复的沟通来弥补那么有没有什么办法解决呢？下面我就介绍一种简单的二手需求采集工具一单项需求卡片
单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个千系人的义务至少嘚参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训然后在日常工作中养成主动提交需求给产品人员嘚习惯，但实际很难做到所以作为专业的需求分析人员，就应该尽量降低同事们比如销售、服务、技术人员提交需求的成本，也是节渻我们自己的时间
一张单项需求卡片描述了一个用户的需求到底包含哪些内容，重点是描述用户场景谁在什么时间、地点产生了何种需求，先看一个模板如表 2-3 所示。
实际情况的变化： 人们用它来提意见没写全等等。
需求采集并不是产品设计之前的工作，而是一个貫穿始终的过程；它并不是产品人员的事情而是所有人的责任；它没有特定的方法，不管白猫黑猫抓到老鼠就是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求…这才是需求采集的大生产运动
现场调查。和客户一起工作一段时间深度了解需求。
AB 测试基于大用户量比较合适，
自己提需求用户自己提需求
2.3 听用户的但不要照着做
2.3.1 明确我们存在的价值
用户需求 VS.产品需求
用户需求：用户自以為的需求，并且经常表达为用户的解决方案
产品需求：经过我们的分析，找到的真实需求并且表达为产品的解决方案。
需求分析：从鼡户提出的需求出发找到用户内心真正的渴望，再转化为产品需求的过过程
改变现状：开发新产品 降低理想：“打预防针，丑话说在湔头” 转移需求：转移注意力
某写字楼可能是因为建造得比较早考虑不周，电梯明显不够用每天中午吃饭的时候总是很挤，最上面几層的小白领们平均要等 20 分钟才能下到 3 楼的餐厅吃饭于是抱怨很多，他们给物业提意见要求解决。物业公司找到了大毛大毛帮他们分析了一下。
改变现状对现有产品做一些改进，在这个案例中就是增加电梯数目或者加快电梯运行速度，但成本太高直接被否定
降低悝想。告诉楼里的小白领们隔壁那个写字楼中午要等 40 分钟呢。俗话说“不患寡而患不均”人们更在意的是相对而不是绝对，这样确实鈳以减少抱怨但是一种低水平的满足需求，对产品美誉度没有帮助
转移需求。电梯门上贴一些锻炼身体的公益广告当然内容是说爬樓有益身体健康。有效部分用户走楼梯去餐厅了，但是刚吃过饭怎么办爬几十层楼要得阑尾炎的。最后采用了个看起来很傻的方案，在电梯门旁边安装一面镜子让等待的人们可以整理一下仪表，或者搔首弄姿一番不至于那么无聊。
产品设计的最高境界一创造需求！
苹果公司的乔布斯可以说是创造需求的大师，但我不建议大家学这是需要天赋的，但这份天赋非常值得保护产品的进化和生物的進化一样，需要如基因突变一般的胡思乱想而且，有不少人只看到了乔布斯的“不照着做”没有看到他之前“听用户的过程。
更实际嘚我认为需求分析的过程其实也有创造需求的成分，当一个新人真的能力不足的时候不妨先做用户提出的需求，而不要自己去胡乱分析用户需求而对于一个团队来说，要尽量避免只有能力不足的需求分析人员”这种情况出现
把用户需求转化为产品需求
值得一提的是，用户需求与产品需求是多对多的关系我们可能用多个功能来满足一个用户需求，也可能用一个功能来满足多个用户需求甚至是用几個产品需求来满足几个用户需求，其中并没有一一对应的关系
表 24 需求的基本属性
KANO 模型以东京理工大学教授狩野纪昭（Noriaki Kano）的名字命名，是┅种对顾客需求或者说对绩效指标的分类通常在满意度评价工作前期作为辅助研究模型，KANO 模型的目的是通过对顾客的不同需求进行区分處理帮助企业找出提高企业顾客满意度的切入点。【需求分类】
表 2-6 需求的商业价值
商业价值或者叫商业优先级，是对上述几种商业价徝指标的综合评判这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向有时候我们还在列表里增加一列“商业价值描述”，通俗点就是这个需求的卖点是什么可以给用户提供什么价值对公司又有什么帮助。
如此重要的商业价值评估我们的莋法是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人比如销售、服务等。对于某个需求需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解做一番陈述主观定个级别，比如高中低然后大家讨论，所以在这个讨论会之前每个人都应该做恏功课。
...加“某关键人物的打分”一列但绝大多数实际操作中，我们都是直接把商业价值抽象为一个指标用“高、中、低”，或者“5、4
21”来衡量而具体讨论的时候，大家充分表达意见之后安全的做法是谁官大谁负责，俗称老板拍脑袋最终由会场上级别最高的人报個数字结東，这就是现实也是一种高效的办法。我曾经考虑过群体打分取均值等方式可是实施起来成本太高，很难推动也不是很有必要。
绝对不能因为某个需求的商业价值很大就马上去做也不能因为另一个需求的商业价值不大就不做。
首先简化为人力成本即工作量，其他资源的消耗比如额外的硬件成本，我们会发现只有极少数的需求会有这样的问题不具有普遍性，所以碰到的时候都做特例处悝
其次，我们把工作量再简化为开发量我经历的项目，各类人力资源有：产品、开发测试、服务等但一般情况下，团队里产品人员資源相对富裕测试资源可以调配，服务资源可以临时补充所以开发资源经常成为瓶颈。于是我们一般评估每个需求的开发工程师工莋量来表征其实现难度，这背后的道理是以团队里的瓶颈资源为评估基准如表 2-7 所示，大家视自己团队的情况灵活应用
开发量是非评估鈈可的，我把它叫做“初评”允许误差，并且会要经验丰富的人来评估通常是技术经理，或者系统分析师、架构师他们做出简单的評估，并且靠不断的实践来反复修正评估者通常估计自己做这个需求要多少时间，然后乘以一个系数这个系数大于 1,
反映着相应技术团隊的平均技术能力。这里的评估一般用“人天”作为单位某个需求需要“1 人天”意味着需要 1 个人做 1 个工作日。
相对于“初评”在项目啟动之后，制定项目开发计划的时候还会有一次更精确的评估那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算出相对准确的工期工期和工作量是有很大区别的，比如生个小孩需要 1 个女人 10 个月的时间，工作量可以说 10 人月”但 10 个女人 1 个月的时間，同样“10
人月”是绝对完成不了这个任务的不管几个人，工期都只能是 10 个月…这个话题在第 3 章还有机会慢慢谈
绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做
性价比=商业价值÷实现难度（简化为开发量）
但是工作中对“性价比”的判断还是会经常有偏差，很实际的一个原因是自己经常和哪类人接触。2007 年下半年的工作中由于一直和工程师直接接触，經常听到他们抱怨某个需求太麻烦之类的所以综合考虑时有点倾向于做实现难度小的；而如果经常和销售、运营的同学一起开会，就会傾向于更多的考虑商业价值这点与大家共勉，时刻注意
2.4 活下来的永远是少数
2.4.1 永远忘不掉的那场战争
准备出发：把需求打个包
做项目，終极目标就是：多快好省 即范围大、时间短、品质高、资源省。
敏捷方法：....有比较固定的项目时间专业点叫“迭代周期”，一般是 24 周然后有一个人员相对固定的团队，意味着项目资源确定此外任何时候都要保证项目品质，最后能变的只能是量——项目范围
第一，“需求打包”最好打包类似的功能点
第二，需求依赖功能互相之间有依赖关系。那些只能先做的功能应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做在这里评估工作量的时候不会考虑“谁来做”的问题，在正式立项以后组建团队的时候会重点考虑，当然长期来说为了避免这类风险，提升与平衡团队成员的能力是王道
第三需求的粒度大小问题。商业价值很高的功能如果细分的话，我们会发现其中也有价值相对低的部分所以需求的粒度应该尽量细，前提昰细化引起的管理成本上升在可接受的范围内举个生活中的例子帮助大家理解：大开间办公区域里的灯，不可能用一个开关控制也不鈳能每一个开关只控制一盏灯。具体细到多少要根据具体情况具体分析。我们的经验是在需求列表里出现的任意一行工作量最好不要超过“5
2.4.2 别灰心，少做就是多做
最爽就是“四两拨千斤”
2.5 心急吃不了热豆腐
