《人人都是产品经理》之谈需求-谈项目-谈团队-谈战略-谈修养

前言

• 苏杰用他的产品经历讲述的生动的描绘出做产品的一生，以第一人称的方式表达了自己的想法和经验。
• 全书精确到二级目录：
  
• 简单来说，全书无非是从谈需求到谈项目、再到谈团队、再到谈战略、最后谈修养 这一过程。
  
• 那么，究竟什么是产品？
  产品就是用来解决某个问题的东西。

谈需求

• 用户是需求之源
  

• 用户研究的方法
  

• 常用的需求采集方法
  
  这里说和做不一定是一致的，可能用户说喜欢黄色，但却最后选择了黑色，所以做用户研究还是有必要的。

• 不要试图满足所有用户，因为有时用户只站在他的角度考虑问题，不要把用户需求照搬为产品需求。

• 用户需求 VS 产品需求
  用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
  产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
  需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

• 给需求“打包”
  魔方计划的业务逻辑图
  形成商业需求文档，Business Requirement Document，简称BRD，它也是我们参加资源争夺战的武器。

• BRD怎么写，都包含哪些内容？
  项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
  商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
  功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
  非功能需求描述：提一下重要的非功能需求，如果有的话。
  资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
  风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。
  从BRD中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的商业价值。

• 管理好每个需求的去留
  在这个过程中，需求会越来越多，永远做不完，就像工作永远做不完一样。而我们要做的事情是，在资源限制下找到最有价值的需求，然后把它做好。那么，新的问题产生了，我们得找个办法把越来越多的需求管理起来。
  一个需求的生老病死
  
  最后，一个需求的奋斗史详图，上图：
  

谈项目

做产品 VS 做项目
我们从三个方面来比较“做产品”和“做项目”。

• 第一，从生命周期的角度来看。
  做产品的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。而项目有特定的目标，所以生命周期较短，通常在项目开始以前就有明确的起始和结束时间，通过验收则表示项目生命周期就算完成了。
  我们要开始做一个产品的时候，没法明确这款产品何时“结束”，一般会随着时间的推移、市场的变化、公司战略调整等因素，渐渐走向“生命周期完结”。所以，会有一个已经“结项”的项目，但不可能有一个已经“完成”的产品（只有不断完善中的产品，除非它被新产品替代）。
• 第二，从具体要做的事情来看。
  做产品的过程，会有更多的探索，随着各种内外部信息的变化，产品负责人需要不断地修正自己的判断，给出适宜的创新；而项目在开始时就已经有明确的目标，更注重计划与控制，项目的过程很像是执行一个任务。当然，也有很多事情无论是做产品还是做项目都必不可少的，比如与团队成员的协调沟通，对未来一段时间做出计划等。
• 第三，从产出物的角度来看。
  产品是可以批量生产，或者提供给大量用户的，所以相对通用，通常考虑用有限的资源去满足更多的、能有更多回报的需求；而项目只进行一次，意味着每次都是定制的、个性化的，通常为了满足特定的需求，产出物也比较个性化。这就意味着，项目要满足那个特定的需求；当然我们会看到有的项目产出物经过改造，成为更通用的产品，或者有的产品也可经历“个性化定制”（即做项目）。

产品经理 VS 项目经理

我们接下来很自然就会想到产品经理和项目经理，他们有何异同？
一个是Product Manager，一个是Project Manager，工作都需要跨团队，工作范围也有重叠，简称还都是PM，工作中我们自己都经常搞不清在说哪一个。

• 产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。
• 项目经理——靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。

用我自己的话总结，就是：一个内部驱动，一个外部驱动。

评估“工作量”并推算出“工期”。
常用的方法是“三点估算法”，即评估出最乐观的工作量、最悲观的工作量、最可能的工作量，然后按下面的公式估算出工作量：
“工作量 =（最乐观+最悲观+最可能）/3”
或“工作量 =（最乐观+最悲观+最可能×4）/6”

这里的工作量粒度也会比初评的时候细，至少精确到“1人天”，短期项目甚至是“1人小时”，按照经验，我们的“1人天”通常等价于5～6“人小时”，而并不是按照一天工作8 小时计算，因为每个人都很难保证持续高效，并且不被其他事情打断。
而对于项目经理来说，需要在更大的粒度上把开发计划、测试计划、发布计划等合并成为项目计划，并确定项目的几个里程碑，也是监控点，通常是需求完成、编码完成、发布上线，在项目进行中，一定不要忘了这最初的约定！
做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。

产品需求文档，PRD
一份实际的PRD模板目录与结构示意图
Visio工具：
UML：类图、用例图、状态图、时序图、活动图及其他

用例文档，UC
UC模板

产品Demo
也经常被说成是产品原型、演示版。

• 用例里最多只能放Demo的截图，所以如果要表现更多交互和视觉的细节，Demo是必须独立存在的。现在应该有一些可以嵌入富媒体内容的文档方式，可以直接把Demo嵌入用例，不过我们没有尝试过，周围也尚未看到有人用。
• Demo最好是由用户体验部门的同学主导，当然你在的团队可能并没有这样一个叫User Experience，简称UE的部门，那么做这个事情的人也许叫用户体验师、交互设计师、视觉设计师，甚至是比较过时的称呼——美工。

Demo也会经历从低保真到高保真，从抽象到具体，从全局到细节的渐变过程。

产品不同，用到的Demo工具会不同（铅笔加A4纸、Visio、PPT、PhotoShop、Word、Axure、Dreamweaver）

日常需求发布流程

计划与控制，就是项目管理。
PD常用的文档模板

产生文档版本管理的本质需求是多人合作，协同办公。借鉴了工程师们对程序代码的管理方法，尝试过几种版本管理工具：

• SVN，对权限的控制比较精细，有几次保密项目用得挺顺；
• VSS，只在和微软合作的项目中用过，感觉更复杂一点。
• Wiki，主要有两种方式，一种是把任务做比较精细的切割，每个PD各自维护自己负责的文档并保持最新，上传到Wiki汇总整理，如有多人共同编辑的文档，养成随时去Wiki下载、及时上传最新版的习惯；另一种就更先进了，完全抛弃了Word、Excel等软件，直接把常见的PRD、产品需求列表等写在Wiki上，这样完美解决了多人合作的问题，可以告诉团队其他成员直接上Wiki阅读，随时看到的都是最新的版本。

流程是一种手段

• 长视者把目的当手段，短视者把手段当目的。
• 当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力。

敏捷也是一种手段
特点

• 有计划，更要“拥抱变化”；
• 迭代周期内尽量不加任务；
• 集中工作，小步快跑；
• 持续细化需求，强调测试；
• 不断发布，尽早交付。

敏捷沟通

• 从沟通扩大至整个敏捷方法，任何团队都在探索一个介于“无过程”和“过度过程”之间的折衷方案，使之给团队带来最大的收益。

“项目的坎坷一生” 详图

谈团队

大产品，大设计，大团队

产品之大

1. 时间之大：产品生命周期
   产品生命周期里的五种用户群体
   

2. 空间之大：商业、产品、技术
   商业、产品、技术的三角支撑
   

三角形是最稳定的结构，从产品与公司的发展角度来看，似乎也是这样。

• 商业，在公司里主要由市场、销售、服务等部门来考虑，他们决定产品的销售渠道、价格策略、促销策略、服务方式等。比方说，再好的产品，如果卖得太贵，目标用户负担不起，那注定要死掉。又如促销活动与产品库存的准备没有配合好，结果很多用户下单却无法满足，也会给公司造成极大的损失。
• 产品，此处是狭义的，由我们平时说的“产品部门”，包括产品设计、用户体验、产品运营等部门来考虑，他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。这些是我们最熟悉的，试想一款单制冷的空调，在夏天热得要死，冬天又冷得要死的长三角，是注定卖不好的。
• 技术，主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、Bug数量等特性。我在2003年前后曾经使用过一款摩托罗拉的T720手机，当短信的收件箱里有50条以上的短信时，再看新短信都出奇的慢，要等10秒以上，很快就让我无法忍受，换了手机，把它送给了收发短信都不太多的长辈。上面这个例子说明性能也会影响用户对产品的体验。
• 这三个方面共同构成了“大产品”在空间上的三个维度，我们可以理解成，他们的乘积构成了决定了产品最终成就的大小，任何一个维度上的提高对产品都大有好处，任何一个维度太弱对产品也都是致命的。

下面是重点：

• 上述三方面，任何一个公司必然有它的强项和弱项，它不可能也没有必要在这三方面都很强，一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗，所以更重要的是找到自己公司、或团队、或产品的那个突出的刀尖，也就是所谓公司的DNA。
• 非常明显，Google是技术主导的团队，从一位在那里做过市场工作的女生那里了解到，工程师在Google拥有绝对的话语权，而市场人员的地位相对较低；Apple则是无可争议的产品主导型公司，它的设计已经拥有了一种气质，它的产品几乎件件都是艺术品，就算现在Apple做个手电筒，叫iTorch，我相信也能卖出不少；而Alibaba就是第三个方面——商业主导的了，商业的强势也说明了阿里为什么不招技术很强的应届毕业生，而Business Sense，商业感觉是在真实的商业环境中工作磨炼出来的。不过个人感觉，这两年阿里开始体会到技术的瓶颈，已经在加大技术方面的投入了。
• 通过上面这段简单的分析，大家可能也发现，一家公司哪方面更强，其实也是和其产品的特点有关的，所以说到底，这些方面都可以看作产品经理需要关注的事情。

设计之大

用户体验要素

• 战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。

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

• 结构层：考虑产品的各个部分互相之间是什么关系。对于软件类产品，主要工作有交互设计，对于网站类产品，主要工作有信息架构。这一步常见的产出物有软件的业务逻辑图、网站的站点地图等。一般来说，技术部门在这时开始全面介入。

• 框架层：到了这一步，才出现用户真正能看到的东西。对于软件类产品来说主要的工作是界面设计，对于网站类产品则是导航设计，两者都有的是信息设计。

• 表现层：最后一步的主要工作包含了视觉设计和内容的优化，比如页面的配色、字体字号等，这里的表现决定了最终产品的气质。

团队之大
如何设计各种职位，让各种人（职员）与各种事（职责）互相匹配。
我个人的思路是这样的：我们做任何产品，或者说公司需要做各种各样的事情，由于事情越来越多，而分工可以使效率提高，所以我们把要做的事情分解成了各种职责，比如开发、测试，再细一点，比如功能测试、性能测试——这是相对容易分析的。然后，老板去找拥有相应能力的人组建团队，于是，由各种各样的人，即职员组成了团队，每个人都有特定的能力，比如有的人喜欢钻研技术，有的人喜欢和人打交道。所以简单想一下就会发现，只要职员的能力都可以和要做的事匹配，那就OK，一个人做一件事是正常的，一个人做几件事是正常的，几个人做一件事也是正常的。到现在为止，“职位”的概念还没有必要出现。

接口人存在的价值

• 不管是客服还是其他部门，接口人一般会让相关部门中比较资深的同学来担任，他起到了问题过滤的作用，可以解决大部分一般同学搞不定的问题，并对相似问题进行合并。
• 后来，我体会到接口人还有个好处，就是缓解“办事要靠脸熟”的问题，一般让沟通能力比较强、已经和公司里多数人很熟的人来做接口人，事先明确了他们的职责，通过他们来连接多个部门的陌生人，可以减少部门合作时，陌生人之间的沟通成本。当然，最好能在公司里培养起“对事不对人”的文化，那会使得沟通成本大大降低。

我身边的矩阵型组织
任何一个超过几十人的团队，就必然脱离“一个班长带几个兵”局面，产生自己的组织结构，常见的有职能型组织、项目型组织和矩阵型组织。组织结构是对项目、产品等的支撑，组织结构的设计也可以看作一种很高级的产品设计。

• 职能型组织是把相同职责的人划分在一个部门里，有利于同类资源共享，互相学习提高，但公司的目标在分解到各部门之后，很容易不一致，而且每个部门唯一的客户就是“上面”，都只对“上面”负责，导致没有人对真正的客户负责。这种形式比较适合大规模运作型的公司或部门，适合计划经济，比如大多数工厂的车间，人真的可以当作可替换的“资源”的情况。
• 项目型组织正好相反，是把各种职责的人组成一个个的项目组或产品线，团队目标一致，有利于快速推进项目，但是会资源浪费。项目组发展下去就是事业部，甚至分公司。说明一下，从组织结构的角度讲，项目型组织的头是项目经理或产品经理（为了方便起见，这一段下面单说产品经理），和职能型组织的头——部门经理相对应。
• 矩阵型组织则是上述两种组织结构的融合，如下图所示，就是前两年某段时间我身边的组织结构，横向是产品线、业务线，为了对客户负责；纵向是资源线、行政线，为了资源共享。如果说职能型组织比较适合防守型的业务，项目型组织适合进攻型业务，那么矩阵型组织就是全攻全守。但它也有很明显的问题：对员工来说，一面是部门经理，另一面是产品经理，这样的“双头领导”总是很让人头疼，那么这两种职位可以通过兼任来解决矛盾么？
  答案是否定的。
  矩阵型组织
  

游走于商业与技术之间

产品团队简图

• 把产品经理当作中心，依次讲述围绕在周围的各种团队。
• 首先，从产品团队出发，讲一下我心目中的几大主要职责，涉及大家经常听到的职位，如：产品经理、产品规划师或产品设计师、需求分析师、产品运营师、交互设计师、视觉设计师、用户研究员、前端工程师，等等。我会按照产品从概念的规划到最终成型的顺序来说，这也是一个从抽象到具体、从商业到技术的过程。
• 我认为，谁做什么事其实并不重要，重要的是我们对周边同学的职责必须有所了解，知道要做哪些事，并且保证这些事都有人做。

心思缜密的规划师

• 狭义的产品团队，具体是指产品经理及其带领的产品规划师、产品设计师和需求分析师，通常在团队中，都被简称为PD，但各人的具体分工会稍有不同。产品经理和产品规划师，更偏向于产品前期的规划，比如产品的市场定位、各个版本发布的时间计划等，在这个层面上，商业目标、用户需求是思考的焦点，当然，公司的管理层也会充分参与这个过程，较大的决策通常由老板们最终拍板。产品设计师侧重于做功能级的设计，编写需求文档，在某个模块上，他们很像一个小产品经理。
• 总的来说，狭义的产品团队所做的事情，最符合互联网、软件行业产品经理的招聘广告里的描述，他们有大局观，逻辑严密，理智而冷静，我们不妨叫他们为“心思缜密的规划师”。

谈谈产品的概念设计与信息架构。

• 产出概念图应该是在需求采集之后，需求筛选之前，基本和需求分析属于同阶段的任务，在纷繁复杂的各种用户需求之中，我们需要通过概念图来理清思路，找出到底应该“做什么”，并将这些打算做的需求整合为一个合理的系统。

产品概念图简单一些的做法？我们常用的是以下两种。

• 第一，在思维导图上改画出概念图。用户需求采集上来，我们或简单转化为产品需求，或直接画在一张思维导图里。然后，开始整理这堆“乱七八糟”的东西，比如把各种需求做简单的分类，把一些条目打上各种标记，把相关的需求连几条线，写一些注释，就算完成最粗糙的概念图了。
• 第二，是找个会议室，用马克笔在白板上画出自己对将来产品概念的想法，完全不要受拘束，然后大家一起讨论改进。这样手绘的概念图很酷，大家可以试试，画完了拍下来，存到电脑上，有必要的话可以重新画成更漂亮的电子版。

这步做完，产品相当于有了整体的业务架构，下面就可以进入需求筛选阶段，大家来决定先做哪一部分、后做哪一部分了。所以说，概念图其实描述的是整个产品的内外关系，形式并不重要，重点要表达出下面两点：

• 产品与外界的关系：把产品整体看作一个系统，描述它与上下级系统、并列系统的关系，可能的话，勾勒出产品所处的产业链结构；
• 产品内部的关系：产品有多少模块、模块之间的关系如何，不用涉及数据流等细节，重点描述清楚不同的角色在系统里的身份。

PD团队

• PD之前做什么不重要，我们必须是一个通才而不是专才。
• 从PD团队的角度来看，成员组成就应该尽量丰富，商业、技术等各种背景的同学都有会比较合理，这样可以优缺点互补，考虑问题更加全面。

激情四射的设计师

• “激情四射的设计师”，指的是用户体验部门的同学们。
• 可以这样来区分，规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品“从无到有”；而设计师更多的是“形象化表达”，保证产品好用，能让用户用起来舒服，让产品“从有到优”。两支团队齐心协力才能让产品内外兼修。
• 设计师是一群追求完美的人，所以在最后，我们再讲一个细节话题——文案设计。
  我把文案问题分为三个级别。
  低级阶段：错别字，病句，错误标点。比如常见的错别字：把“登录”写成“登陆”，打开一个网页可以算“登陆”这个网站，而输入了用户名、密码之后才是“登录”了这个网站，用英文Landing和Login就容易区分了；语句逻辑关系混乱，这属于小学的时候作文练得不到位，没事儿乱“因为、所以”、“如果、那么”；中文与英文的标点混合不分，陈述句最后没有句号，等等。这些错误没啥好说的，要极力避免。
  中级阶段：用词不统一，不准确。比如“创建”与“新建”，其实结果都是一个意思——New，用哪个本无所谓，但是在同一个产品中不统一的话，会给人不专业的感觉；导航菜单用词的主谓、动宾结构不统一，经常看到同一个产品中同时出现主谓结构的“系统配置”和动宾结构的“管理客户”等菜单；又如“保存”、“确定”不分，一般来说前者是伴随信息的提交，系统有写入数据库的动作，而后者只是让用户肯定刚才的行为；再如“邮局”、“邮箱”、“邮件”等近似词语的不准确使用。
  高级阶段：语言风格不统一，产品气质不统一。我们经常会发现，产品里同时存在由开发工程师随手写的“成功、出错提示”，和前台小妹帮忙写的“欢迎、促销信息”，所以用户在使用产品的时候，一会儿看到“数据库错误，CorpID不能为空”这种过于专业的术语，一会儿又看到“哦”、“啊”、“”结尾的感情丰富的句子，这两种明显不同的风格同时出现在文案中，简直是让用户冰火两重天。所以由一个人最终来统一语言风格是很有必要的，而语言风格又是由产品想传达给用户的气质决定的，比如聚友（myspace.cn）可以在用户登录后的欢迎词里写“好久没见，你是不是忙着去拯救全人类了？”（如图下所示），我们看了会会心一笑，而这句要是出现在Oracle的财务系统里，那简直就要让人崩溃了。
  

用户体验部门各种职责的细分，通常主要有如下几种：

• 用户研究员（User Researcher），一看就知道，是做用户研究工作的，他要利用各种方法进行用户研究，给产品决策提供建议。
• 交互设计师（Interaction Designer），他要负责人机交互界面、用户操作流程的设计，典型的工作有导航设计、信息设计等，必须要了解很多商业的内容，理解功能的商业价值。
  举个例子，比如在商业目标是“注册用户数”的前提下，去设计注册流程是一页搞定还是分几个“下一步”，出错提示如何处理，等等。
• 视觉设计师（Visual Designer），在很多小作坊被简称为“美工”，他与交互设计师的界限也挺模糊的，他们主要做视觉设计，即用户第一眼看到的效果，比如页面结构、配色方案、字体字号、按钮的形状、颜色、大小、质感，等等。
• 前端工程师（Web Developer），互联网行业特有的一个偏技术的职位，要运用前端技术进行Web页面的开发，实现产品体验的良好传达。我们在网页上看到的各种很炫的效果，通常都是他们的杰作。

“阴险狡诈”的运营师

• 如果说规划师是产品的父母，把产品生出来；设计师是产品的老师，把产品教育好；那么运营师就算是产品的老板吧，他们要把产品卖出去，让产品从“叫好”到“叫座”，让更多的人愿意使用产品。

产品与运营的战与和

• 客观地看，不论是高层、运营，还是产品团队做的事情，都是在平衡短期与长期利益。有时候产品与运营共同承担商业指标会好一些，但运营的同学总会显得急一些，他们希望尽快看到效果，而产品的同学则热衷于练内功，好在大家的根本目的是一致的，只是这个度需要双方共同寻找平衡点。

商业团队，冲锋陷阵

• 前线的团队，主要任务是市场、销售，需要负责产品价格策略、促销策略、销售策划、渠道管理等；另一块任务是服务，也有细分，比如客户服务、技术支持、服务策划等。
  商业团队简图
  

好产品还需市场化

• 因为公司里有专门的商业团队，所以很多工作PD平时接触得并不多。
• 销售有两大模式：直销 VS 分销。
  分销要通过渠道，渠道又分代理和经销。他们的区别是“代理”赚佣金，没有产品所有权和库存风险；“经销”赚差价，产品所有权发生转移，比如批发商。

产品的版本细分有两类。

• 一种是做功能区分，打细分市场，这个同学们都比较熟悉，比如笔记本的高中低端产品、手机的各种型号，不用多说。
• 另一种是为了促进销售，利用消费者心理，纯策略性地做出“炮灰版”。

技术团队，坚强后盾
技术团队简图

有这样两种工程师

• 一类是技术痴迷者，常见于工作不久的新人，或者少数工作很久且一直醉心于技术的牛人。
• 另一类是实用主义者，常见于工作过一段时间的老人，或者只是把技术当作工具的工程师。

如何与工程师合作

• 第一，综合大家的需求，大家最看重的居然是一个很大的话题：“流程”，但仔细想想就一点都不奇怪了，一群超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管理而不是被人管理
• 第二大的问题就是“沟通”，这是团队合作必不可少的一个环节。站在PD的立场上，我们会把自己作为产品的中心，这个角色注定要和各种各样的人交流，客户、老板，以及开发、运营、测试、客服、合作等部门的同事。
• 第三点是PD要不断提高自我修养，大家希望PD给出的文档在质量上更进一步，准确、全面、简洁，即时更新、保持最新。

支撑团队简图
容易被遗忘的还有默默奉献着的法务、财务、行政等，他们和老板们一起构成了产品的支撑团队。

如果产品经理是管理职位，必然既有优势也有劣势。
优势在于：

• 管理岗位利于拥有话语权；
• 管理岗位利于获取信息；
• 管理岗位利于争取资源。

劣势在于：

• 管理岗位有很多行政工作；
• 管理岗位会让人脱离群众。

其实产品经理是不是管理者并不重要，重要的是公司应该创造出一个良好的环境，让上述几点优势可以发扬，劣势可以避免，这样产品经理才能发挥出最大的作用。看到这里，你可能想到了解决办法，其实很多公司都想到了：设计管理、专业两条晋升线路，让优秀的产品经理在专业线路上拥有高级别；对于产品、业务的决策有充分的话语权；可以参与管理会议的业务讨论；可以拥有临时的资源支配权，并给管理层提供同事的考核建议；但不负责管理者的行政工作，而是继续和同事打成一片，用产品证明自己。

“我的产品，我的团队”详图

要想“我的产品”好，就要对“我的团队”好。

谈战略

触及产品的灵魂
我觉得做产品经理、PD，或者说产品设计师都有三个境界：

• 第一层，产品帮助我们。这时候，我们的思想还不是很成熟，做什么产品，只能被动接受地安排，且可以在做的过程中迅速提高自己各方面的能力。
• 第二层，产品与我们互相帮助，共同提高，我们仍然离不开产品，不同于第一层的是，这时候产品也离不开我们了。
• 第三层，我们帮助产品。我们开始占据主导地位，能够帮助产品开拓局面，如果觉得高层的方向不对，有能力和意愿去寻找，甚至创造自己信仰的产品。

以价值观为根基

• 产品的灵魂，或者说企业的灵魂是什么，探到最深处，是由价值观（Value）决定的，而企业的价值观就是：企业决策者对企业性质、目标、经营方式的取向做出的选择，是员工所接受的共同观念，是长期积淀的产物。

阿里巴巴的价值观
有价值观（Value）作为企业做事的最基本指导原则之后，我们就需要思考公司或产品的使命（Mission）和愿景（Vision）。Mission是指“我们为什么而存在，要做什么事情”，必须是一个持久的事实。
产品的灵魂——战略，它取决于公司的愿景与使命，表现为团队的文化与价值观，受到公司高层的影响，反过来又体现在公司里的每一个部门、每一个人身上。

可行性分析三部曲：

1. “我们在哪儿”：我们在什么位置，有哪些资源、能力、优势、劣势。
   整个行业如何——市场扫描；
   竞争对手如何——竞品分析；
   自己情况如何——自我分析。
2. “我们去哪儿”：目的是什么？用户是谁？
3. “我们怎么去”：怎么达到目的？怎么接近用户？
   解决这一步的问题，浓缩成两个字就是“策略”，各种各样的“策略”：定价策略、推广策略、渠道策略、服务策略、财务策略、技术策略……各种正确的策略保证了我们是在“做正确的事”。

着手去做

产品路标规划

• 对一个产品来说，最大的计划就是产品路标规划。路标规划是一个产品，乃至产品线层面上长期的时间规划，路标规划上最小的单位，可能是产品的一个版本或相关的一个重大活动，细化以后都要通过好几个项目来实现。

靠谱的会议

• 把握“大会决定小事，小会决定大事”的原则，其中的“大小”指的是参会人数，比如全公司的会议，是没法讨论事情的，只能传达信息。
• 要想让会议不流于形式，就要把会议本身变成形式。

会议记录的模板

仰望战略会议
俗话说“高层定向，中层分解，基层执行”，务虚的战略会议是经验丰富的人在掌握了极多信息的基础上做出的预测与判断，并不只是海阔天空的闲谈。只有这样的“找出问题、发现机会”的过程才真正体现出人的价值，从某种程度上讲，这才是最最不可替代的事情，或者说没办法自动化之后交给机器做的事情。

• 如何准备战略回顾会议上的演示，总体来说我觉得围绕大纲的13个问题可以分为四部分。
  第一部分：
  1.上次会议讨论的重点问题是什么？
  2.关于这些问题我们达成了哪些一致意见？
  3.上次会议中哪些问题由于缺乏信息考证，具有不确定性因素等原因而未能解决？
  4.上次会议哪些执行计划通过了？对于这些执行计划我们有哪些主要设想？
  上面四条都是回顾上次会议中的信息，把大家带入状态，这些细化的问题可以让我们在做演示准备时不会漏掉任何重要的内容。
  第二部分：
  5.自上次讨论会议后外部发生了哪些主要变化？
  6.自上次讨论会议后采取了哪些重要行动？以及这些执行对战略和财政产生的影响？
  7.上次会议后我们搜集了一些参考信息，根据这些信息考虑是否要对当初设想的执行计划作些调整。
  继续回顾，但是重点变成了上次会议结束到本次会议开始这段时间内的问题。
  第三部分：
  8.我们今天讨论的重点是什么？
  9.你们提议的执行计划是什么？最初的设想和决定的理由？
  10.我们怎样实践这些设想和确定减少潜在的不确定因素。
  11.今天要讨论和做出的决定是什么？
  面对这么多回顾的信息，今天要做的事情则是重中之重，每个问题都需要很多的工作来支撑。
  第四部分：
  12.从上一轮的战略回顾中我们学到什么？怎样在下一轮中学到更多？
  13.怎样改进战略回顾会议和会议进行方式？
  持续改善，考虑如何将“战略回顾”这件事情做得更好。

KPI

• KPI，即Key Performance Indicators，关键业绩指标，它是在分解企业战略目标的基础上，分析并建立各子目标与主要业务的联系之后提出的。可见，KPI是企业目标的具体表现，所以不一定只是常见的营收、利润、用户数，也可以是客户投诉率、员工满意度、社会贡献等。
• 企业战略往往很难让每一个员工都充分理解并为之奋斗，自上而下的分解并设定每个基本战斗单位的KPI，是一种很好的简化方案。

谈修养

四大修养，分别是：爱生活、有理想、会思考、能沟通。这四节，谈到了四个方面，它们也有递进的关系：

• 爱生活让我们充满动力；
• 有理想让我们目标明确；
• 会思考让我们方法得当；
• 能沟通让我们团结前进。

爱生活
爱生活，才会爱产品。
我们发现自己产品的用户们也很热爱生活，要不我怎么老说“人人都是产品经理”呢，这个世界就是因为有了这么多有爱的人而变得越来越可爱。

有理想
有明确理想的人，会过得很开心，也会很让别人敬佩和羡慕。一个人活着的终极目的是获得内心的安宁，我的理解是：做事可以follow your heart，感觉这辈子过得不后悔。只要为理想努力过、付出过，在通往理想的路上不停地走，最终是否走到已经不重要。所以，我觉得有理想的人，本质上还是为了自己。

个人品牌建设

就业保障会降低一个人的竞争力，职业保障可以提高竞争力，假设有一天，公司突然不需要你了，这时候你不用去找工作，而是有一堆公司马上排着队请你去，这才是真正的保障。

个人名片设计实例
正面：

反面：

会思考
了解一下教育的本质，以便激发自己思考与学习的能力。
那么，我们教育的欠缺主要表现在以下几个方面，而这几个方面，对于产品经理来说都是致命的。
第一，教知识不教思维。
第二，教解题不教选题。
第三，教努力不教取巧。
第四，教受教不教施教。

任何事情，需要同时有能力和意愿才能做好。“活到老学到老”，需要激情与理想做支撑，思维方法做指导，才能不断前进，产品经理这个岗位涉猎的知识领域太多，只有保持不断学习的习惯才能胜任。

能沟通
我的沟通理念

• 理论上严格意义的“充分沟通”是不存在的！
• 沟通不是为了说服，而是为了更好地认识世界。

职场中的点对点沟通

四种一对一沟通方式比较

• IM：成本最低，适合不紧急不重要的沟通。
• 电话：成本适中，适合紧急不重要的沟通。
• 面谈：成本最高，适合紧急且重要的沟通。
• E-mail：成本适中，适合重要不紧急的沟通。

职场中的群体沟通

• 群体沟通正好对应前面说的单点沟通方式，它也有四种方式：IM群，电话会议或视频会议，会议，群发邮件，从“紧急、重要、成本”三个维度上看与点对点沟通类似。

---

我觉得产品经理应该是通才，本行功夫自不必说，要能出彩，更重要的是外家的功夫，所谓“功夫总是在诗外”。

---

有14个模板，它们的名称及在书中出现的位置如下：
1、第2章提到的
① 人物角色（Persona）实例：2.1.2
②用户访谈实例：2.2.1
③ 调查问卷实例：2.2.2
④ 单项需求卡片模板：2.2.5
⑤ 商业需求文档（BRD）模板：2.4.1
⑥简易需求管理模板：2.3&2.5 2
第3章提到的
① 项目组织结构模板：3.2
② 产品需求文档（PRD）模板：3.3.1
③用例（UC）文档模板：3.3.1
④ 项目日报周报模板：3.4
⑤ 项目发布通知模板：3.4 3、
第5章提到的
①产品路标规划实例：5.3.1
② 会议记录模板：5.3.2
③ 其他书中未出现的
④ 个人日报周报模板
（已上传资源）