不断地对用户、对需求、对功能、对流程进行思考与总结，是成为一个成功的 PM 必不可少的
不同公司对PM的职责以及其在公司产品流程中具体作用的要求都有所不同，但是，无论在哪个公司，不断地对用户、对需求、对功能、对流程进行思考与总结，是成为一个成功的PM必不可少的。这，也正是这本书字里行间最宝贵的东西。
version1.1升级说明
不是每个人都能以产品经理为业，但在我看来，产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理。至少，你已经是自己的产品经理，这才是“人人都是产品经理”的真谛。
我与本书的局限性
我们应该养成一个习惯，当看到一个观点的时候，就有冲动去寻找与之矛盾的观点，然后通过对不同观点的分析找出背后的原因，从而更全面地理解某个事物。一个人成熟的标志之一就是心中可以容纳各种不同的思想而无碍行事。
1.3 我真的想做，怎么入行
应聘这类职位主要看面试，要是我来做面试官，最在乎的是应聘者有没有激情，是否够机灵、好学，逻辑思维是否清晰，沟通表达是否顺畅等。其他的都会次要一些，比如对行业的熟悉，既然是招应届生，这块不会很看重，关键是看潜力而不是看能力，有类似职位的实习经历，只是一个加分项。
1.4 一个产品经理的-1到3岁
此刻，我已经入行三年。越来越觉得对于一款产品，早期的决策无比重要，所以很想参与产品初期的战略规划，幸运的是公司也给了一线员工这样的机会。早在2007年，我就参与过两次“物流平台”的可行性研究，通过产品的早期研究，我知道了公司其实想做的东西很多，而真正开始实施的只是其中的一小部分，面对那么多极具诱惑的产品，果断地放弃变得很重要，而放弃的原则与依据，就是价值观、战略这些内容
2.1.2 你真的了解用户吗
说和做、定性与定量，合理的搭配组合使用，才能发挥最大的作用，下面的这个产品调研的小例子，就是用了各种用户研究方法来交替解决问题的。
第一轮，听用户定性地说，确定产品方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。
第二轮，听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。
第三轮，看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。
第四轮，看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。
当然，这是一个比较重要的产品，所以在用户研究上投入了较多的时间与人力，更多的时候，我们会视情况采取简化的方案。
2.2.1 定性地说：用户访谈
避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。
- 首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。
- 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。
- 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。
- 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。
- 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复
2.2.2 定量地说：调查问卷
《长尾理论》里说到“沉默的大多数”，那么站出来的总是很少数，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”说的是，大多数人是没有明确观点的，尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群体的观点，随机的初始值决定了结果，这个时候你只有单独和跟风者交流，才会发现他根本不是那么想的。
2.2.3 定性地做：可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
每一个优秀的产品（Gmail、豆瓣（douban.com）、微信也许是），都是靠着不断的升级、优化、改版才逐渐获得认可的。改版的初衷都是为了产品升级，更好地服务用户，但改版在客观上会挑战用户现有的习惯，所以必须慎之又慎。可用性测试就是一种很合适的方法，来保证产品改版的安全性
2.2.4 定量地做：数据分析
主动地误读数据，是比较有趣的现象。在提取数据之前，我们心中通常已经有一些结论了，无非是想验证它，而抱着这点思想，就总能找到数据来证明自己已有的想法，并且技术越娴熟的人越容易做到这点。对于这点，我想一个简单的对策就是对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯，比如为了证明老板的判断，或者为了保持自己之前拍脑袋的英明形象等，你明白我的意思。
2.3 听用户的但不要照着做
有的用户很“危险”，在提意见的同时还说你们应该做成什么样子，这时候产品经理一定要头脑清醒，用户提的解决方案往往是站在自己的立场上考虑的。
2.3.1 明确我们存在的价值
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程
2.5 心急吃不了热豆腐
没有产品是生下来就完美的，一天又一天，一月又一月，我们的产品反复地经历着需求采集、需求分析、需求筛选的过程，不断进化。我们不要想一口吃个胖子，很多案例表明，追求一步到位的产品经常像陷入沼泽的巨兽，挣扎着一步步走向死亡，用户甚至根本都不知道它曾经存在过。
在这个过程中，需求会越来越多，永远做不完，就像工作永远做不完一样。而我们要做的事情是，在资源限制下找到最有价值的需求，然后把它做好。那么，新的问题产生了，我们得找个办法把越来越多的需求管理起来。
3.1 从产品到项目
产品的定义在第1.2节中的“产品到底是什么”里和大家分享过，所以这里特别针对互联网、软件产品领域，给出项目的定义：
只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。
从这句话里看出，产品是一个解决问题的东西，而项目是一个过程，根本是两个不同层面上的概念，可人们经常说“做产品”、“做项目”，其所做的事情确实有几分相似，所以我们有必要把它们放在一起比较一番。
“做产品”和“做项目”也是分不开的，“做产品”的过程，正是通过做一个又一个项目实现的，但并不是项目的简单累加。在产品渐渐满足目标用户群体的通用需求后，继续做下去的话，会使产品成为项目的集合体，臃肿不堪，因此我们就需要细分市场，这时候产品可能升级为“产品线”，按不同的细分市场，推出不同的产品，表现形式上叫版本、模块、增值服务，什么都行，本质上是通过合理地安排项目来实现产品的规划。
产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。
项目经理——靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。
对产品经理来说，最重要的是判断力与创造力，产品经理决定做不做、做什么、做多少，保证方向正确。他是产生一个想法，“我要把它实现！”
对项目经理来说，最重要的是执行力与控制力，项目经理决定怎么做、谁来做、何时做，保证方法得当。他是接到一个任务，“我要把它完成！
一个产品经理可能想要增加非常多的功能和特征以满足获取到的用户需求，但是项目经理却想要尽可能小地控制工作范围，以保证项目在规定时间与预算内完成。好的产品经理和好的项目经理能在冲突中找到平衡。好的项目经理明白，一个项目真正的成功并不是看它是否在规定的时间和预算内完成，而是它是否达到了拟定的目标。好的产品经理则明白，如果项目被不断延期并且从未投入市场，又或者因为大大超过预算而被结束，那么所有的产品功能特征都会变得毫无意义。
3.2 一切从Kick Off开始
项目管理的新手总是认为可以通过加大资源投入来缩短项目时间，一般来说，如果各个任务相对独立，则可以更多地并行，通过投入资源来缩短时间，比如给一大片果园摘苹果就可以采用此方式；但如果任务互相依赖严重，就只能更多地串行，这时候加人也往往无能为力，就像我之前提过的那个“十月怀胎”的例子，更坏的情况，是在软件项目中，经常因为“延期、加人、老人带新人耽误时间、更加延期”，而进入恶性循环。
从项目开始直到结束，我们无时无刻不需要沟通，由沟通问题导致的项目不顺利也占了极大比例，常见的情况有“干系人权责利不明确，出工不出力，心不在焉”；“对需求的理解不一致总是到最后一刻才发现，不能防患于未然”，“遗漏了利益相关方，导致项目考虑不周，不能发布”等，所以有必要一开始就约定好项目的沟通方式。
项目沟通方式各有不同：
- 周期：以“日”或“周”为单位，主要取决于项目时间的长短及变化的频率。
- 渠道：会议、邮件等，需要在成本和效率之间取得平衡。
- 发起者：一般由项目经理、开发经理、测试经理主导相应的沟通。
- 参与者：发起者确定参与者，不要遗漏项目边缘的同事。
项目背景
- 我们在哪里？说过去，做项目之前的“悲惨境地”，明确为什么要做这个项目，以让听众“痛下决心”为终极目标。
- 项目意义、目的与目标 我们去哪里？说将来，做项目之后的美好前景，解决什么问题就算成功了，以让听众“面带桃花”为终极目标。
- 需求、功能点概述 我们怎么去？说现在，具体用什么方法促使“过去”到“将来”的转变，以让听众“跃跃欲试”为终极目标。
做项目的目标无非是多快好省：范围大、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的，有理智的老板们也都明白这一点，所以我们通常是在上述4个要求中做平衡。 上面所说的目标对比经典的项目TRQ：项目时间（Time）、项目资源（Resource）、项目质量（Quality），几乎一样。一点小区别就是Q（质量），我觉得把Q解释为“Quality + Quantity”（品质+数量）更准确，而我所经历的项目，Q更多的是表达Quantity（除非有特殊情况，“品质高”这点是不会舍弃的，所以可变的是项目范围）。 综合一下，我们做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
3.3.1 真的要写很多文档
先从整体上看一下PD们都要写哪些文档吧。几年前看一个叫“Michael on Product Management & Marketing”的博客，它讲述了产品设计中的几种核心文档，我结合实际工作整理之后，形成了我心目中产品从抽象到具体的过程主要产出的文档：BRD、MRD、PRD和FSD。
BRD：Business Requirements Document，商业需求文档。这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、赢利预测等，通常是给大老板们演示的PPT，比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要为了获得认可，争取资源。
MRD：Market Requirements Document，市场需求文档。获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级等。实际工作中，PD在这个阶段常见的产出物有产品的FeatureList、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。
PRD：Product Requirements Document，产品需求文档。PRD是对产品功能的进一步细化，是PD新人写得最多的文档，也就是我说的“需求开发”过程。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述，更多内容在下一节详细讲述。
FSD：Functional Specifications Document，功能详细说明。比较像我们常写的用例文档，经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左、中、右对齐？保留几位小数等，有点像“概要设计”。与此同时，硬件系统的设计、数据库设计、表结构设计等工作，也开始由架构师、系统分析师们编写了。
4.1.1 产品之大
创新者（Innovators）：新鲜感强，消费能力强，但是忠诚度不高，需要新鲜的东西不断刺激。这批人都有Geek气质，乐于探索。产品刚上市，甚至未上市的时候，主流用户往往是创新者。
早期追随者（Early Adopters）：观念比较新，但是需求目的性很强，需要迅速能够解决其问题的产品。他们是信息达人，可能很早就知道产品了，但不会盲目试用，而是先从其他渠道主动了解这个产品是干什么的，反复验证，确认对自己有用以后才会尝试，好在这批人如果开始用了会比第一种人忠诚度高很多。
早期主流用户（Early Majority）：是产品大规模产生商业价值的用户群，他们是典型的实用主义者，也是生活中最常见的一批人，偶尔被动地听到过新产品，但觉得正在使用的老产品也能解决问题，就不会更换，但心中还是对新产品存在期待，希望有机会试一下。
晚期主流用户（Late Majority）：这部分主流用户和早期的区别也许是心态上的。早期主流用户对新产品有尝试的愿望，而晚期主流用户对新产品心存抵触。他们直到老产品已经渐渐地出现明显的劣势，才会很不情愿地使用新产品。
落伍者（Laggards）：最后一批用户，他们的附加值已经比较低了，如果我们实际一点，就可以更注重眼前利益，在不违背道德标准的前提下，赚一票是一票吧。这时候，产品渐渐退出，市场也渐渐萎缩，或者说转移，因为必定有新产品成长起来，长江后浪推前浪，前浪必然死在沙滩上。
非常明显，Google是技术主导的团队，从一位在Google做过市场工作的女生那里了解到，工程师在Google拥有绝对的话语权，而市场人员的地位相对较低；Apple则是无可争议的产品主导型公司，它的设计已经拥有了一种气质，它的产品几乎件件都是艺术品，就算现在Apple做个手电筒，叫iTorch，我相信也能卖出不少；而Alibaba就是第三个方面——商业主导的了，商业的强势也说明了阿里为什么不招技术很强的应届毕业生，而Business Sense，商业感觉是在真实的商业环境中工作磨炼出来的。不过个人感觉，这两年阿里开始体会到技术的瓶颈，已经在加大技术方面的投入了。
4.1.2 设计之大
设计里的学问很多，我们作为新人很容易思考不全面，甚至自作聪明，就像上例，国内的设计师希望“取其精华，去其糟粕”，但根本没分清哪是精华、哪是糟粕。我建议同学们有必要先看几本入门的书，学习华为的任正非引进新的管理体系时所用的策略——“先僵化、后优化、再固化”，慢慢找到最适合的设计方法。
范围层：明确“做多少”，对于软件类产品，是确定功能范围；对于网站类产品，则是确定内容范围。这时候要做好需求的采集、分析、筛选、管理、开发工作。复习一下第2章的主要内容，先要“尽可能多地收集”，灵活运用多种用户研究的方法，不要遗漏，再“尽可能多地放弃”，因为我们的资源有限，只能做最有价值的，先做的“收集”不是为了“放弃”，而是防止遗漏任何“有价值的”需求。
结构层：考虑产品的各个部分互相之间是什么关系，上一步相当于把一桌子菜的原料都买来了，这一步就开始确定哪些原料组成什么菜，具体是蒸是煮是炒是炸了。对于软件类产品，主要工作有交互设计，对于网站类产品，主要工作有信息架构。这一步常见的产出物有软件的业务逻辑图、网站的站点地图等。一般来说，技术部门在这时开始全面介入。
框架层：到了这一步，才出现用户真正能看到的东西。对于软件类产品来说主要的工作是界面设计，对于网站类产品则是导航设计，两者都有的是信息设计。大家经常看到的网页，是上下结构，还是左右结构，导航条在哪里，分几级，都是这个时候设计的。对新人来说，常见的错误就是认为从这里开始才算设计，接到一个任务马上就开始想网站的页面应该长成什么样子，而忽略了上面的几层，这样在大前提没思考清楚的情况下做出来的产品必然会成为一个悲剧。
表现层：最后一步的主要工作包含了视觉设计和内容的优化，比如页面的配色、字体字号等，这里的表现决定了最终产品的气质。这部分是最有意思的，但好的设计师一定要理解商业和用户的目标才能做出正确的设计，毕竟我们不是艺术家。解释一下，设计师和艺术家的区别就在于要满足的对象不同，一个是“你！你！你！你！你！”，另一个是“我！我！我！我！我！”。
产品设计的这五个层次，从整体看是抽象到具体的过程，是从概念到实现的过程，又有一点从商业到产品到技术的感觉。
2008年夏，我看了Donald Norman大师的两本书，一本是《设计心理学》，另一本是《情感化设计》。诺大师是先写了《设计心理学》再写《情感化设计》的，从中我似乎看到了一位认知心理学家、一位宗师从现实主义到浪漫主义的升华。
诺大师把设计的目标分为三个层次，即本能水平设计，行为水平设计，反思水平设计，有观点说是对应了心理学里人脑的三种不同的加工水平：本能的、行为的和反思的。本能水平就是纯生理的视觉冲击，就像“第一眼美女”，看上去就喜欢，没什么好说的；至于行为水平，我认为就是《设计心理学》一书的主要内容，主要讲的是产品功能、用户与产品交互层面的设计；而反思水平则是诺大师思想的又一次升华，通过《情感化设计》一书，把纯心理需求也纳入了产品设计的考虑范围。
4.3.2 我们还能做什么
商业感觉，只能随着工作经历的丰富不断提升，而不是通过上几年学、看几本书就可以学到的。所以，随着阅历的增加，对于商业团队的事情，我们可以做的也越来越多。
4.5 容易被遗忘的角落
刚从学生变成一个职场人士时，总会保留一些习惯，比如把老板当做老师，总是心存敬畏。几年下来，我的体会是，不要怕老板，或者仇视老板，而是要把老板当做最好的资源，“利用”他们促成自己不断成长
4.6.1 所谓团队文化
很多人都在讲企业文化、团队氛围，阿里在这个问题上备受争议，外界有人觉得这种文化很好，可以让人有激情，有战斗力，也有人觉得是在洗脑，会迷失自我，对此颇为不屑。任何人的观点都只能是管中窥豹，但我知道，如果一个团队里的每个人每天都开开心心，就是很好的。
4.6.2 虚无的无授权领导
大中之小不如小中之大：送礼的时候后，在一个不太昂贵的礼物类别中选择一个比较贵的礼物，要比在一个比较昂贵的礼物类别里选一个比较便宜的礼物收到的效果更好。比如送一条1000块的围巾效果好于送一件1200块的衣服，我们应该尽量找一些高级的小玩意。
有用的不如无用的：最好的礼物应该是吃不掉、用不掉、送不掉也扔不掉的东西。比如有纪念意义的水晶奖杯，刻上他的名字，千万不要是几瓶酒、几条烟，能喝掉、能抽掉、能送掉。
需要的不如想要的：你应该把人们想买却舍不得买或者想买却不好意思买的东西送给别人做礼物或作为奖励。比如5星级酒店1000块一顿的高档餐券，更多的是心理满足感。
有选择不如无选择：奖励或送礼的时候最好不要让接受奖励或礼物的人自己选择。不然的话他会有“我放弃了另外一种选择的感觉，患得患失反而不开心”，经典反例就是：奖励团队“海南游”或每人“现金2000元”。
小奖不如没奖：人们做事往往是出于自己的内在动力，而一旦与奖励挂钩，就变成了一个经济交易，做事的人会开始衡量投入产出的物质性价比，所以给小奖反而不如不给奖。惩罚也是如此，受到小的惩罚后反而会让人感觉心安理得，还不如没有惩罚。
晚说不如早说：在期待的过程中，让员工的快乐最大化，从而增强激励的效果；让朋友在期待的过程中提前享受到礼物所带来的欢愉。比如尽早宣布奖励大家去海南玩，如果可能的话，在项目开始前就给出承诺。
一次送不如两次送：如果你打算给别人两件礼物的话，那么最好分两次给。因为快乐也是边际效用递减的。同样的道理，有很经典的结论：好消息要分两次说，坏消息要一起说，大的好消息与小的坏消息一起说，小的好消息与大的坏消息分开说。
公开不如不公开：工资体系最好还是不公开的好，以避免员工互相比较而心理不平衡，也就不必用涨工资的方式来进行协调了，因此避免了整体工资水平的提高。
涨工资不如发奖金：涨工资不如发奖金给员工带来的快乐大；同时，发奖金有比较大的回旋余地。对于这类物质激励，一般效用期比较短，发奖金是一次性的，涨工资是长期的，涨了就不好降回去，从第二个月开始，激励效果就微乎其微，孰优孰劣一目了然。
要记住，奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你。最后，
作为产品经理的你，请把本节标题想成“如何让用户更开心”，再看一遍上述的几条，独立思考，批判吸收。
5.1 触及产品的灵魂
我觉得做产品经理、PD，或者说产品设计师都有三个境界：
第一层，产品帮助我们。这时候，我们的思想还不是很成熟，做什么产品，只能被动接受安排，且可以在做的过程中迅速提高自己各方面的能力。
第二层，产品与我们互相帮助，共同提高，我们仍然离不开产品，不同于第一层的是，这时候产品也离不开我们了。
第三层，我们帮助产品。我们开始占据主导地位，能够帮助产品开拓局面，如果觉得高层的方向不对，有能力和意愿去寻找，甚至创造自己信仰的产品。
第6章 产品经理的自我修养
我试着总结出了四大修养，分别是：爱生活、有理想、会思考、能沟通。这四节，谈到了四个方面，它们也有递进的关系： 爱生活让我们充满动力； 有理想让我们目标明确； 会思考让我们方法得当； 能沟通让我们团结前进。
最先需要的修养就是热爱生活，因为“爱生活，才会爱产品”，这其实是一种心态的修炼。爱生活并不难，因为生活的点点滴滴中本来就充满着可爱的东西，而且“用户创意无限”，处处都是我们设计产品的思路源泉。而有了爱生活的心态，我们会发现身边的人和事愈发可爱。
心态好了，也不要无欲无求，毕竟我们都是年轻人，接下来几十年总得做点什么，与其漫无目的地走一步看一步，最后回顾一生发现没什么值得骄傲的，不如找到自己可以做一辈子的事——理想。这节里谈到了“个人品牌建设”和“我的理想之路”，我想告诉大家“有理想，就不会变咸鱼”。
接下来，努力做到“会思考，活到老学到老”。思考能力、学习能力，是“学校里没教的东西”，我们的教育告诉了我们太多问题的答案，却忘了生活中很多问题是“只有方法，没有答案”的。只会做不会想，我们最终只能沦为一个工具——作为一个有理想的人，这点显然是不可接受的。
最后，我们要“能沟通，在什么山头唱什么歌”。从“我的沟通哲学”谈起，说明我们不能活在自己的世界里。个人觉得，在任何价值链里，与人沟通的事情都要比与机器沟通要复杂，也更有挑战。能沟通的话，就算不做产品经理，对个人发展也有很大好处。
6.2 有理想，就不会变咸鱼
我觉得一个人与一家公司一样，最重要的，做事应该是内驱而不是外驱的。内驱的人是鲜活的，外驱的人更像是一个物化的工具，只会接受任务，成为别人实现理想的工具。小学老师教的“不是要我学，而是我要学”，是同样的道理。而内驱的动力，就是理想，就是你想到达的“彼岸”。对热爱生活的人来说，理想显得尤为重要——没有目标，没有方向，不知道自己想成为什么样的人，那么热情满满地做事是为了什么？事情永远做不完，怎么知道该做哪件？到处横冲直撞，怎么知道是不是在向“前”走？
6.5 产品经理主义
不是每个人都能以产品经理为职业，但在我看来，产品经理是一类人，而不是一个固定的头衔。任何人，只要能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去维护，跟踪这个产物，那么，这个人就是产品经理。