第一章  写给-1到3岁的产品经理

1.1 我们为什么要做产品经理？

我们生活中离不开产品，电脑、音箱、鼠标，台灯等等，产品的好坏直接影响到我们生活体验。好的产品使用起来给人以舒畅感，例如台灯灯光的多亮度调节，而坏的产品给人生活带来麻烦，比如没写推拉的一扇门。产品经理是不断改进产品，给人们更好的产品体验的人，比如垃圾桶分类从多一种颜色识别到直观的标明易拉罐等东西是否可回收，简化了人们使用该产品的思考深度，让用户更加省心。产品用户分为新手、专家和中间用户，因此产品设计者要考虑到用户的层次，一个重要的设计准则就是无需阅读说明书就能上手。

书籍推荐：《点石成金-访客至上的网页设计秘笈》

1.2 我们到底是不是产品经理

产品是用来解决某个问题的东西，其满足的需求包括两个：用户需求和公司需求，产品经理要在用户目标和公司目标之间寻找平衡。

产品经理源于宝洁，传统产业的产品经理和互联网软件行业的产品经理有较大的区别：

1.传统行业形态比较成熟，大多是实体产品，工作的重点在于营销类创新；互联网企业大多是虚拟产品，工作重点在产品的从无到有，偏重研发类创新，需要产品经理对市场发展趋势有敏锐的洞察力，注重产品需求分析和设计细节。

2.传统行业产品生命周期长，而互联网产品生命周期端，推崇敏捷方法，经常需要在产品质量和目标完成度之间进行协调。

3.传统行业大多靠卖产品盈利，互联网产品大多免费，通过多元化的方式实现盈利。

4．传统产品替代成本略高，包括用户的时间成本等，而互联网产品替代成本低，要求产品更注重用户体验。

书籍推荐：《产品经理的第一本书》和《产品经理的第二本书》

 1.3我真的想做，怎么入行？

产品经理重要的一点是思维模式，就打飞机游戏而言，用户思维是如何快速升级和得分最高，而产品经理思维是如何控制飞机数量增加用户粘性。

1.4 一个产品经理的-1到3岁

对初入职者，应保持好学的态度，主动去熟悉工作中需要的基本知识和技能，去了解产品的各个方面，包括功能、用户、技术等，去与工作上有联系的部门进行交流。

先跟着前辈学怎么做，再开始自己决定做不做，做多少。由于资源的有限性，不可能完成所有的需求，就要按照需求的优先程度进行取舍。

产品经理要接触多方面的工作，不可能所有工作都亲力亲为，要保证产品离开产品经理同样运行，应该把工作规划法、流程化，使更多的工作可以让团队来完成。

图1 全书结构图

第二章  一个需求的奋斗史

图2   一个需求的奋斗史总布局

2.1 从用户中来，到用户中去

需求来源于理想和现实之间的差距，用户大多时候会把需求描述成需求的解决方案，比如为了找到温馨的感觉，他可能会管你要一幅画，所以在确认用户需求的时候一定要刨根问底。

产品应以用户为中心（User-centered Design UCD ），然而很多产品的用能并不是来自于用户，而是来自老板，因此产品经理不能只顾“造反”，而是要尽可能地帮助老板明确问题和需求价值，为其决定方向提出参考建议。

不要试图满足所有用户，那会让产品臃肿不堪，优先满足哪些用户要和产品的商业目标结合起来考虑.。

用户在基层之中，所以要想真正了解用户的需求，不能空想，必须真刀真枪的去研究他们。

描述用户应该用人物角色（persona），来更深入的了解用户的特征。

图3 人物角色

用户研究包括定两个维度：说做和定性定量。

图4 用户研究的维度

横向：怎么说表现了用户的目标和观点，怎么做反映了用户行为。用户怎么说和怎么做经常是不一致的，既要看用户做了什么，又要通过说来寻找用户行为的依据。

纵向：定性研究可以找出原因，偏向于了解；定量研究可以发现现象，偏向于证实。

推荐书籍：《赢在用户：WEB人物角色创建和应用实践指南》

产品调研可以遵循以下步骤进行：1，听用户定性地说，确定产品方向，列出需求列表；2，听用户定量的说，大量发放问卷，确定需求优先级；3，看用户定性的做，针对先做的需求进行可用性测试；4，看用户定量的做，根据用户使用产品反馈进行数据分析，不断改进产品。

2.2 需求采集的大生产运动

1.定性的说：用户访谈

用户访谈对象较少，每个用户身上的问题比较多，用户访谈用来了解目标和观点，对新产品的研究方向进行预判。

在用户访谈过程中，要注意“说”和“做”不一致的问题，用户可能因为各种因素造成心口不一；要防止样本过少带来的以偏概全的问题，应通过增加样本数量来验证先前结论；防止和用户聊与访谈主题无关的问题，应平等的对待用户，不要把访谈做成产品推介会。

2.定量的说：调查问卷

调查问卷可以更多的搜集用户数据，但要注意“沉默的与骑墙的总是大多数”，防止后来者因为先前人员的引导而做出错误判断。防止样本偏差、样本过少、问题带有诱导性等问题的发生。

3.定性的做：可用性测试

可用性测试是指让用户实际使用产品或圆形方法来发现设计界面中的可用性问题，用户参与数量较少，在用户测试的过程中要观察用户操作的全过程，并记录发现的问题。

可用性测试避免做的太晚，导致问题发生时已经无时间更改；可用性测试要5个左右的用户进行测试才可能发现问题；测试过程中，用户应采用“发生思维”，对自己的行为进行说明，而测试者不应给予任何引导性信息。

产品改版的几种方式：修改次级页面；新旧版本并存，用户自主选择；小面积试验；沿用已有用户习惯。

4.定量的做，数据分析

数据分析要注意时效性，不要过于学术化；多方面解读数据，防止出现解读误差；平时应注意数据搜集，不要造成无数据可分析。

数据搜集应从多角度进行，既要一手数据，也要销售等人员的二手数据，使用二手数据时要注意数据提供人员可能出于自身目的提供带有偏差的数据。

采集数据会用到单项需求卡片，样本如下：

图 5 单项需求卡片

2.3 听用户的但不要照着做

用户需求和产品需求是不一样的，只有经过需求分析，才能将用户需求转变为产品需求。

用户需求：用户自以为的需求，并且经常表达为用户的解决方案；

产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

真正的需求分析师的价值就在于无视用户想要的东西，去探究他内心真正的渴望，再提出更好的解决方案。如果注重短期利益，那么用户想要什么就可以给什么，如果注重长期利益，那么最好给用户真正想要的东西。

需求的DNA检测：确定一个需求的属性

图6  一个需求的DNA

需求DNA检测过程为：需求转化→确定基本属性→分析商业价值→初评实现难度→计算性价比

需求转化是将用户需求转化为产品需求。

确定需求属性包括需求编号、提交人、提交时间、所属模块、名称、描述、提出者、提出时间、bug编号。

需求可分为新增功能、功能改进、体验提升、bug修复和内部需求等类别，包括基础需求、拓展需求和增值需求三种（可参阅KANO模型）。

分析需求的商业价值包括三个维度：重要性、紧急度和持续时间，其中在持续时间上，有些产品寿命比较短，比如为国庆节而涉及的产品。商业价值（商业优先级）是对上述指标的综合评判，是需求列表中最核心的部分。

初评实现难度：实现难度一般用工作量来表示，而在互联网软件行业，开发量往往成为项目进度的制约瓶颈，因此实现难度往往用开发量来表示。由于初始需求并不十分明确，因此初评开发量的时候可以有一定弹性。

性价比=商业价值/实现难度（简化为开发量）

2.4 活下来的永远是少数

产品经理为争夺企业开发资源，需要通过商业需求文档向领导表明自身需求的重要性。商业需求文档（business requirement document BRD）包括项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策几个方面。其中商业价值和资源评估是最主要的方面，资源评估要评估PD（产品设计师）、UE（用户体验师）和开发工程师的工作量。

在确定项目的过程中很多需求会被砍掉，这是由于资源限制造成的。然而在确定需求的过程中，必须要经历需求从少到多再到少的阶段，这样才能更好的从整体上把握产品的需求。情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。

2.5 心急吃不了热豆腐

需求是有生命周期的，从一个需求的产生到最后被抛弃或者发布，都要进行记录，称之为需求管理。

需求管理还可以有附加价值，比如通过统计提交人、提交时间、发布时间、模块等维度的需求数量，来发现不同时期需求数量的增减变化，进而分析为何发生这些变化，为产品制定策略提供依据。

图7 需求的生老病死

 第三章 项目的坎坷一生

3.1 从产品到项目

产品和项目时不同的，产品注重创新，而项目注重计划与控制，产品通常是可以批量生产的，而项目一般只执行一次。

产品经理靠想，重点要有创造能力，属于内驱；项目经理靠做，要有执行能力，属于外驱。

产品经理和开发经理都有可能成为项目经理，而二者的目标是有区别的，产品经理可能想要增加增多的功能来满足用户需求，而开发经理想尽可能地少做工作。良好的产品经理在做项目的时候注重产品功能和项目完成度之间的权衡。

3.2 一切从kick off 开始

Kick off指的是项目启动大会，在项目结构中，项目经理并非是项目的顶端，而应该组织一个“项目督导委员会”，由项目的老板担任，这样一方面可以让他们随时了解项目进度，另一方面可以更方便的争取资源。

项目进行中，除了需求搜集中BRD给出的工期之外，还要对工期进行细化，将工期细化到1人天，1人天约等于5-6人小时。工期的公式为：

工作量=（最乐观+最悲观+最可能）/3

或“工作量=（最乐观+最悲观+最可能*4）/6”

项目开始要制定好项目的沟通方式，比如沟通周期、沟通渠道、发起者和参与者。

KO会议包括项目背景、项目意义与目的、需求功能点概述、项目组织结构、项目计划（项目的时间点与里程碑以及各时间段所需要的资源）以及沟通计划。

做项目的目标是多快好省：范围大、时间短、品质高、资源省。也有TRQ之说，即时间、资源和质量/数量。

项目中应进行任务分解，即WBS（work breakdown structure），有经验的项目可以自上而下，无经验的项目可以自下而上，列出最小的任务点进行汇总。随着项目越做越多，应该形成自己的wbs模板，以后再遇到相似项目时可以快速进行任务分解。

3.3 关键青春期，又见需求

产品经理要写很多文档，主要有：

BRD ：商业需求文档，内容涉及市场分析、销售策略、盈利预测等，给老板看。

MRD：市场需求文档，有更细致的市场竞对分析，包括可以通过哪些功能来实现商业目的，功能、非功能需求，功能优先级等。这是从商业目的到技术实现的关键转化文档。

PRD：产品需求文档，是对产品功能的进一步细化，包含整体说明、用例文档、产品demo等。

FSD 功能详细说明，这里会有较多的技术内容，产品界面、业务逻辑细节等。

其中PRD是产品同学经常需要的文档，样板如下：

图9 PRD模板

 修订历史：修订的版本号及日期等信息；

项目概述：项目背景、意义、目的、目标等；

功能范围：PRD的业务逻辑图，重点描述系统中的角色与职责、与周边系统的关系、全局的商业规则等。

用户范围：本PRD涉及的角色和系统；

词汇表：本PRD专有的词汇和术语；

非功能需求：数据监测等；

UC（user case）即用例，PRD要将各用例可视化表示，并说明各用例之间的关系，一般有类图、用例图、状态图几种。用例的制作要用到UML（unified modeling language），即统一建模语言，用于规范图形的制作（推荐书籍：UML基础案例与应用）。

UC整体说明表述各用例之间的关系，不涉及用例的内部细节，常用的图有类图、用例图和状态图。

类图（class diagram）描述系统中出现的各对象之间的关系，以及和外部系统的关系，让人明白此系统是做什么事的。下图为小明与菜之间的联系方式。

图10 类图

用例图（use case diagram）描述用例之间的关系，下图表明小明进饭馆后可能进行的行为：

图11 用例图

状态图：（state diagram）表达系统里实体状态的转换，贯穿多个用例，下图表明小明状态的转化：

图12 状态图

UC正文讲述单个uc的详细状况，是需求人员给开发人员的一种最基本的文档，理想状态下，一个UC代表了产品需求列表里的一行，但实际上并不绝对，也可能一个UC满足一个产品需求，或者一个UC涉及多个产品需求。UC模板如下：

图13 UC模板

其中：

前置条件表明触发这个用例的前提是什么；

后置条件说明用例完成后续动作是什么？比如服务员接受订单去厨房。

界面描述：通常给出截图，界面上也种元素的说明，并且会和demo结合起来。

业务规则：表述整个用例的通用规则，比如限制小明不吃辣等，界面规则和流程规则不应放在这里。

流程描述：分主干、分支和一场三种，描述用例发生过程中有什么事件触发，系统与用户事件的交互步骤等。

UC一般只描述功能性需求，非功能性需求写在PRD的总体说明里。UC对语言要求比较高，需要做到无歧义、完整、一致可测试等。

UC内部也许他用到UML，包括时序图、活动图和协作图等，用于描述业务规则和流程。

时序图（sequence diagram），描述事物变化在时间维度上的先后顺序，表达对象的交互。

图14 时序图

活动图（activity diagram）描述各种动作如何引起系统变化，善于表达泳道较多、分支较多的情况。

图15  活动图

推荐UML的工具：Visio，当然，如果团队里其他人看不懂UML，不要强推。

产品demo的制作在产品会议开始之前就可以开始了，有可能的话在BRD中展示出来，很可能成为争取资源的加分因素。Demo最开始可以用纸画一个简单的，后面可以用Visio、PPT等制作，最后可以用Axure、Dreamweaver等软件来制作出具有交互效果的页面，当然，这可以与UE的同学一起做。

评审是项目中不可缺少的环节，包括需求评审、设计评审和测试评审三个阶段。需求评审是对PRD、UC和demo评审的总称，设计评审由开发工程师把对需求的理解以设计文档的形式说给PD、测试听。测试评审称为TC，是在TC编写完成、测试开始执行之前由测试工程师把对需求的理解说给PD、开发听。

评审的原则是“改动较多的话必须再次评审，异议不大的可以通过”，在需求评审的过程中一定要叫能做决定的人和与此项目有关的产品接口人参与，防止与其他系统有冲突，导致后面来不及修改。

从项目中看一个需求的生老病死如下图：

图16  项目中一个需求的生老病死

3.4 成长，一步一个脚印

在完成项目之后，要写项目总结，说一下项目心得体会以及经验教训。项目总结并不非要等到项目结束后在写，而是在项目进行过程中以日报和周报的形式来记录。

3.5 山寨级项目管理

互联网软件项目中几个关键问题：文档管理、流程管理、敏捷方法

文档是手段

项目管理人员应建立自己的文档规范，并定期省级整理，PD常用的文档范围如下：

图17 PD常用文档模板

 其中WBS（工作结构分解）可以用WBS Chart PRO 软件来制作。（本书模板已下载）

画脑图可能用到的工具有mindmanager、freemind 、xmind等，软件推荐Visio（画图）、outlook（邮件管理）、project（安排计划）。

流程也是手段

流程存在的好处是人走了，事儿还能做，减少特定的人的影响，当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事情的时候不会太无助，这点上，规范、模板的作用也类似，这就是团队的核心竞争力。流程对产品有利，但对于个人成长或许不利，因为他只让人接触到工作的某个层面，缺少对大局的把握。

敏捷更是手段

敏捷的入门书籍有《敏捷迭代开发-管理者指南》和《敏捷估计与规划》。敏捷模式的特点如下：

1.有计划，更要拥抱变化，要在计划中给予一些弹性；2.迭代周期内尽量不加任务，在一个迭代周期内如果需要增加东西，可以延伸到下一个迭代周期；3.集中工作，小步快跑，工作群体应少于十几个人，推行站立晨会，加强交流沟通；4.持续细化需求，强调测试，需求要在测试过程中不断细化，而不是一开始过分细化；5，不断发布，尽早交付，让需求方尽早的看到结果并给与反馈，先解决最核心、风险最大的部分。

敏捷沟通是敏捷方法里的重要部分，沟通方式可以是im群、邮件列表、项目看板等。

第四章 我的产品，我的团队

图18 我的产品 我的团队

4.1 大产品，大设计，大团队

产品之大可以从两个维度分析：时间之大和空间之大

图19 产品生命周期

产品的时间之大是从产品生命周期角度来讲的，《公司进化论：伟大的企业如何持续创新》和《跨越鸿沟》两本书对产品生命周期进行了介绍，产品生命周期主要包括五个部分：

创新者：新鲜感强，消费能力强，为了新技术而使用某产品，忠诚度较差，需要新鲜的东西不断刺激。

早期追随者：为了解决某种需求而使用某产品，会给产品提出很多意见，这些人可以发展成产品的种植永不，不断给产品提出改进意见。他们可以自主的研究产品的用途，因而称为专家用户。

早期主流用户：产品大规模产生商业价值的用户群，实用主义者。他们不主动探索新产品的使用方法，因此产品应该做得简单易用，为“中间用户”和“新手服务”。

晚期主流用户：对新产品心存抵触，直到老产品不能满足需求的时候才很不情愿地使用新产品。在此时不能仅靠产品的功能竞争来获得用户，而是市场营销发力的时刻。

落伍者：附加值较低，产品逐渐退出市场。

从产品生命周期角度，我们应该清楚现在主打哪种类型的市场与用户，他们的特点是怎么样的，然后再决定产品的特点与功能。

产品的空间角度是指产品商业、产品和技术三个方面。

商业决定了产品的渠道、定价策略、促销策略和服务方式等，包括市场、销售和服务部门。

产品包括产品设计、用户体验、产品运营等部门，决定了产品的功能范围、交互流程、视觉表现和运营手段。

技术主要包括开发、运维和测试，决定了产品的稳定性、性能和Bug数量。

在上述三方面中，公司可以维持其中一个作为强项，三方面都强范围会造成公司内耗增加。

设计之大包括设计的五个层次，推荐书籍《用户体验要素》：

图20 设计的五个层次

战略层：明确商业目标和用户需求，找准方向，平衡二者关系。

范围层：明确“做多少”，软件类产品应确定功能范围，网站了产品应确定内容范围，这时应做好产品的需求采集分析、筛选、管理和开发工作。

结构层：考虑产品各部分之间的关系。

框架层：这时用户看到的东西，软件类产品的主要工作是界面设计，网站类产品是导航设计。

表现层：包括视觉设计和内容的优化，表现了产品最终的气质。

设计类的书籍推荐《设计心理学》和《情感化设计》，书中将设计水平分为三个阶段：本能水平设计，也即纯生理的视觉冲击，看上去就好看；行为水平讲的是产品的功能、用户与产品交互层面的设计；反思水平的设计将纯心理需求纳入产品的涉及范围。对于面向普通用户的产品，本能水平、行为水平和凡是水平应逐个满足：本能水平设计是基础，产品要有用；行为水平的设计是保证，产品要能用；反思水平的设计是升华，产品要好用。

团队之大包括产品制作过程中各种不同职位团队的存在，包括职能型组织、项目型组织和矩阵组织。为加强团队之间的交流，应该设计团队接口人的存在，接口人应选择资历比较深的同学担任，可以起到问题过滤的作用，解决大部分同学搞不定的问题，并对相似问题进行合并，提升交流效率。

4.2 游走于商业与技术之间

产品团队是游走于商业与技术之间的团队。

狭义的产品团队指的是产品经理及其带领的产品规划师、产品设计师和需求分析师：产品设计师桂花茶农定位、发布时间等，聚焦于商业目标和用户需求；产品设计师侧重于功能级的设计，编写需求文档；需求分析师偏实现、技术，即UC，做系统设计。

产品概念设计是产品设计的起始，产出是产品概念图。首先在搜集的需求的基础上将需求分类，确定需求之间的关系，在思维导图的基础上画出概念图。产品概念图有两个重点：产品与外界的关系、产品内部模块之间的关系。概念设计推荐书籍《Web信息架构》。

PD可以通过多种岗位转化而来，PD成员组背景应该尽量丰富，实现优缺点互补。

产品规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品从无到有；而设计师更多的是“形象化表达”，保证产品好用，用起来舒服，让产品“从有到优”。

产品demo的制作应由PD和UE共同完成，保证大家对商业目标理解的一致，确保界面上每一个细节设计都有理有据，包括区域位置、长宽和字体、字号大小。

产品中文案设计并非长篇大论的宣传文案，而是产品页面上的说明文字，文案问题分为三个级别：

低级错误：错别字、病句、错误标点。

中级阶段：用词不统一，不准确，如既有新建，又有创建。

高级阶段：语言风格不统一，如既有卖萌的，又有严肃的错误提示等。

产品与运营之争由来已久，运营只能把人带来，而留住用户则需要靠产品了，运营同学背负着更直接的商业指标，因此在一些活动中可能采取治标不治本的方式。

4.3 商业团队，冲锋陷阵

商业团队包括销售、服务和市场团队，负责产品的定价与促销，销售与渠道等。互联网软件行业常用一种“炮灰版”的销售策略，比如添加一些没必要的功能做一个高价的“炮灰版”，或者删掉核心功能做一个低价的“炮灰版”，其核心都在于利用心理学让人们购买正常版。

产品与销售应该相互配合。对产品来讲，产品研发之前就已经确定了目标用户，对销售来讲，为了增加销量可能并没有卖给产品最初的目标用户。因此当一个产品制定出来，原有目标用户并不买单的时候，可以通过销售改变目标人群。

4.4 技术团队，坚强后盾

技术团队包括开发、运维和测试。

产品的需求是一直在变，因此产品与工程师交流时最大的障碍就在于“变”。

4.5 最容易被遗忘的角落

这部分图团队包括行政、财务法务和老板。

在公司中，老板是最好的资源，不要老板或者仇视老板，而应利用他们不断成长，在自己发现问题并获得良好的解决方法的情况下，请示老板获得授权。

第五章 别让灵魂跟不上脚步

5.1 触及产品的灵魂

产品经理在成长过程中，要经过三个阶段：第一层，产品帮我们，我们被动接受做产品的安排，从中学习。第二层，我们与产品相互帮助，共同提高。第三层，我们帮助产品，我们占据主导地位，帮助产品开拓局面，创造产品。

价值观是创造产品的基础，是产品的灵魂。产品经理很重要的观念是“大局观”，也即从整体上看待局势的能力。如果我们感觉公司战略有问题，不妨去问一下老板公司进行某种战略的原因，找高手解惑本身就是一件对自己提升很大的事情，培养自己的大局观可以以更广阔的视野看待问题。

5.2 可行性分析三部曲

可行性分析包括我们在哪儿、我们去哪儿和我们怎么去三个阶段。

我们在哪儿是在明确公司愿景、使命和价值观的基础上，进行市场扫描、竞品分析和自我分析。市场扫描指的是宏观环境的分析，常用的方法PEST分析。竞争对手分析常用的是APPEALS分析法，主要的信息来源有网络收集、研究报告（主要报告的客观性）和请第三方公司调研，请公司有经验的老板拍脑袋而定也不失为一种有效的方法。自我剖析常用的方法是swot分析。

我们去哪里是指考虑产品细分市场、目标用户等问题，常用的分析方法有安索夫矩阵、波特五力模型，BCG矩阵、GE矩阵等。

我们怎么去说的是用什么产品怎么满足用户需求的问题，包括定价策略、推广策略、渠道策略等。

5.3 做吧，准备出发

出发指的是通过制定产品计划，向既定目标前进的过程。对产品来讲，最大的计划是产品路标规划，是针对一个产品长时间的规划，包括产品发展方向、时间点和里程碑等。最小的计划是执行计划，计划最重要的作用是提前准备，以免出现紧急情况时我们手足无措。

会议是计划过程中不可少的项目，有效地会议包括以下几点：1.不要试图在一个会议中解决很多问题；2.提前准备，确定所需资源和与会人员，提前给与会人员发出会议资料；3.会议主持人要把握均衡发言，控制会议进度，做好会议记录；4会后要整理会议记录，表明会议决定和遗留问题。

图21 会议记录

5.4 KPI

KPI的存在是将公司战略分解为每个员工可衡量的指标，要符合SMART原则：S代表具体，不能笼统；M代表可度量;A代表可实现，避免目标过高或过低；R代表现实性，绩效指标要实在，可证明和观察;T代表时限，注重完成指标的特定期限。

KPI可能造成员工过分关注数字，而忘记了数字背后的目的，因此不要把KPI当成目的，它本身只是一种手段。

第六章 产品经理的自我修养

产品经理的自我修养包括爱生活、有理想、会思考和能沟通四个方面。

6.1 爱生活，才会爱产品

一个人只有有乐观积极的生活态度，才会有爱，才会发现生活中的美，才会有好奇心和创造力，愿意研究生活中的产品。因此生活中要保持对产品及其背后设计逻辑的好奇心。用户可能对产品开发出一些延伸功能，比如MSN的签名做广告牌等，关注用户创意，可能对产品功能改进有很大的帮助。

6.2 有理想，就不会变咸鱼

人与公司的成长应该共同进行，不能为了自身发展损害公司利益，也不能为了公司发展限制自身发展。在工作过程中应通过不断积累经验创造职业保障，增强自身的职业竞争力。

6.3 会思考，活到老学到老

产品经理是一个对思维能力、学习能力要求很高的角色，每个人都需要补课。我们的教育交给我们知识但没有交给我们思考问题的方式；交给我们那些好而不告诉我们为什么另一些不好，产品经理是要在多种需求之中做出选择的；交给我们努力而不教取巧，产品经理有时还要在资源很少的情况下完成任务，必须取巧；交给我们受教而不施教，而教别人的过程中可以学到更多的东西。

6.4 能沟通，在什么山头唱什么歌

产品经理要和多种人沟通，然而由于信息的不对称，并不存在完全的“充分沟通”，因此我们要明白沟通的意义不是在于说服别人，而是通过沟通交流更好的理解彼此的意见，达成一致的协议。

职场中沟通方式有IM、电话、面谈和email等，根据重要程度和紧急程度可以做如下划分：

适合IM沟通的事儿：两三句话就可以说明白的事儿；不用讨论只是告知的事情；不急的事情；上不了台面的事。

面谈最大的优势是人们不喜欢当面拒绝。

Email最大的优势是可以留下证据。

针对客户，交谈的时候可以事先搜集客户资料，根据然后尽快找出对方感兴趣的、熟悉的、擅长的并且自己也知道一点的事情开始聊天。

6.5 产品经理主义

产品经理的思路是：为了什么？做什么事，解决了什么人的什么问题？何时做？谁来做？效果如何？

“为了什么”是大前提，是公司的战略层面；“做什么事，解决了什么人的什么问题”是用户的目标和需求，以及转化完成的产品需求；“何时做。谁来做”是项目和团队，着重讲计划、执行和控制；“效果如何”是事后总结，是持续改进和提高的基础。