人人都是产品经理——iamsujie

同样的一堆信息摆在面前，展现方式设计的好坏可以让用户感觉差异多大？为什么同样的一个“任务”，一天也能“完成”，一周也可能没法“完成”？

这个例子是我2007年从Google的一位产品经理那里听来的，任务的目的是展示美国的几个城市在不同月份的平均降水量。很自然的，一开始我们就会想到用一张表格，如下图，横轴是一月到十二月，纵轴是城市名称，分别是San Francisco、Seattle、Chicago、New York、Miami，表格中每个元素就是某城市在那个月的平均降水量，单位是“英寸每月”。

上图已经把所有的信息都展示出来了，但重点不够突出，各种信息都用一样的字体让人不知道一开始看哪里，而下图就优化了很多。首先各种文字用了不一样的字体，图表的标题最明显，让人一眼就知道这个图表是说什么的，月份与城市信息稍微弱化以突出数据内容，特别值得一提的是这里用了不同深浅的颜色来突出数据，让人很容易解读出某个城市全年整体的降水情况，降水季节分布等信息。

我常说“字不如表，表不如图”，再回忆一下上面的图表，你还能记住Miami在8月的平均降水量么？我是不能，但我记得Miami在夏季的降水量很大。这给了我们启发，其实要传递的并不是具体的数字，而是每个城市在全年的降水量整体情况与分布，数据只是给极少数做科学研究的人，在需要的时候可以查到就可以了，在表现形式上，我们可以处理成鼠标悬停在某个水滴上的时候，就展现出相应的数字。于是，我们进一步优化出下图，用很符合读者心智模型的水滴大小、颜色深浅来表示不同的降水量区间。现在更加一目了然了，San Francisco最干，冬天稍微好一些；而New York全年降水很平均……

还可以优化么？是的，还可以。上面几个城市为什么会有这样的降水情况呢？我们可以如下图，把它们放在地图里，从地理的角度得到解释，比如San Francisco “因为三面环水，并受太平洋加利福尼亚寒流影响，旧金山是典型的凉夏型地中海式气候”，所以夏季降雨极少，冬天经常下雨。而Miami则“拥有温暖、湿润的夏雨型暖副热带气候”，所以降水充沛。下图把时间轴做了个动态展现，拖动时间轴，我们可以看到几大城市，甚至可以推测出全美国在一年中各地的降水情况。当然，如此炫的表达也有其弱点，那就是没法如上图一次性看到所有信息了，这个需要我们来权衡利弊。

有个细节差点忘记，上图中左上角的logo，有没有让你想到什么？对了，flickr，同样的配色，同样的字体，同样的故意拼写错误，我想这应该是产品经理、产品设计师一种典型的闷骚表现吧。

项目中，测试最开始一段时间，Bug总是不断的蹦出来，Bug指缺陷或故障，区别在于项目发布之前发现的叫缺陷，项目发布之后发现的叫故障，通常故障会对用户造成伤害，团队里也制订了相应的惩罚机制。这次不妨从Bug的角度来说说项目，下图是我们使用过的一份Bug级别定义，一般来说对一个Bug的描述有以下几个关键点。

缺陷级别（Severity）：即上图中的5级别定义，一般大于等于III级的Bug被认为是严重的问题。

所属产品、项目：有的人需要同时处理很多产品、项目，这个属性可以用来筛选。

Bug名称：一个短句，此Bug的简单说明。

Bug描述：写成如下形式，“执行某操作，期望出现什么情况，实际出现什么情况”，还可以添加截图、文档等附件。

其实其他属性还有很多，不过我觉得非必须，经常不填，也就不说了。

我们的测试过程使用了Mercury Interactive公司的Quality Center来管理，它是一个基于 Web且支持测试管理的所有必要方面的应用程序，更小的团队，用Excel来管理Bug也未尝不可。作为PD，也是会经常提Bug的，PD做测试的时候主要是模拟用户的身份使用产品，而测试人员会更多的按照TC执行。当发现一个Bug以后，我们会提交给相应的开发工程师，如果认为是需求问题也会提交给对应的PD，这时候Bug的状态为Open，之后的状态改变，可以用下图表示。

Bug状态流转图（图中defer拼错了）

收到Open的Bug，确认并修复，状态变为Fixed；否认，也许提出者理解错了，也许不打算修改，状态改为Rejected；或者认为不是自己的问题，可以把Bug转交（Assign to）给别人。

测试验证状态为Fixed的Bug，没问题了就Closed，否则可以Reopened。看到Rejected的Bug，发现是自己理解错了，就可以Closed，仍然认为是Bug的可以Reopened。对于Deferred的Bug，意味着本项目中暂不修正，可能是因为技术做不到，时间不允许，性价比太低等，必须慎之又慎，通常由能负责的人，比如是测试经理、项目经理最终同意才Deferred。

整个过程中，Bug的每次状态改变都可以添加注释说明，我们更鼓励有争议叫上当事人面对面的交流，而不是在系统里不停的纠缠。

到了项目发布之时，我们要求所有Bug的状态必须是Closed或者Deferred，当然对I、II级的Bug，有时候并没有这么严格。

使用Quality Center比Excel的好处，在于每个Bug重要的状态转换点，系统都会有邮件通知到相关人员，防止遗漏；项目中每个人在系统里的角色不同，权限不同，防止误操作，甚至一些恶意行为，比如开发人员就不能把Bug状态改为Closed；所有操作都有记录，谁在何时做了什么，便于追溯。这些都有效的防止了人为因素导致的问题。

PS：很久都不发带图片的文章，是因为picasa，我终于打算放弃，转投flickr了。。。

几天前刚说到《非典型产品经理》，但还是有朋友觉得这些并不是“真正的产品经理”，比如这篇转帖的，找不到原作者，能搜到的最早出现在2009年4月，但也明显不是原文，我觉得作者的部分观点稍显绝对，大家看了有疑问的尽管讨论好了。

很多论坛都在探讨何为产品经理，产品经理该干什么？

多人也处于不明白产品经理为何物的蛮荒时代。

我本人从市场研究做起，后来是可用性测试，然后是产品设计师，再后来是产品经理，我自认为我对产品经理的理解强于大多数人，可以为你们解答疑惑。

背景：很多人的title都是产品经理，但是我要说的是真正意义上的产品经理，这种产品经理责任重大，能力超强，待遇超高。就算你目前不是这种产品经理，那么这也应该是你努力的方向。我下面说的产品经理指的都是这种产品经理

一、判断一下此人是不是产品经理

定义：产品经理，顾名思义，该人能够对产品负全责。

判断方法： 看指标、 看责任、看工作方式

1.看指标：以用户数（极个别时候用PV）作为考核指标，否则一定不是产品经理！产品的意义就在于留住用户，所以用户数是评价产品的最核心标准。你对产品所做的一切努力都会体现在用户数上。

2.看责任：产品经理需要对产品负全责。我举个例子，如果产品出现技术问题，比如奥运期间访问量大增，造成服务器负载过大，以至于当机，影响了用户访问，领导第一个骂谁？骂你？恭喜，你是一名真正的产品经理。产品经理显然应该了解服务器的最大载荷以及在中国各地的分布情况，网通和电信、铁通、校园网等链路的具体情况也理所当然的应该是产品经理的职责范畴。

3. 看工作方式：产品经理会一直运营一款（最多两款）产品，如果你看到一个人以项目的方式参与产品的某个阶段，工作完后就去做另一款产品 ，那么毫无疑问，此人非产品经理也。

二、产品经理的职责

对产品负全责，谁都会说。但是怎么才叫负全责呢？所谓的负全责是对“整个产品生命周期负责”。从市场调查、产品规划、概念设计、功能设计、产品逻辑设计、原型设计、交互设计、界面设计、技术环节的沟通、项目管理、产品上线、上线后的运营管理、产品推广、对外合作、产品改版升级……总之，从产品诞生开始一直到产品推出市场，再到市场运营，再到改版，知道产品退出市场。这一切都应该是由一名产品经理全权负责。他对产品的方方面面都很了解。一个PM在一款产品上做3、5年是很平常的。

三、产品经理的典型工作

我随便罗列一些我的日常工作吧，尽量按照产品生命周期写。

1.规划阶段：竞品分析、产品整体规划

2.设计阶段：产品一期概念设计、功能、交互、原型设计、技术可行性分析、可用性测试、形成需求文档

3.开发阶段：项目排期、项目跟进、产品一期单元测试、产品一期上线

4.运营阶段：产品一期运营（内容运营、技术运营、运营人员工作安排，周末值班人员安排）、市场营销与推广（寻找合作机会，参与合作谈判——通常与市场部合作，签署合作法律文件——通常与公司法务部合作，监督合作推广的执行，分析推广效果ROI等等）、运营数据分析、一期改版意见、产品二期概念设计、产品二期需求文档草案

5.产品二期设计阶段：产品二期需求文档、产品二期技术论证

6.产品二期开发阶段 …….

四、哪些职位被误认为是产品经理：

1.UE设计：这个东西最害人。产品设计师绝不是产品经理，请大家务必记住这一点。产品设计师管理的是设计过程，而产品经理管理的是整个产品的所有环节。目前有很多UE从业者——多是设计师——最容易将二者混淆

2.项目经理：项目经理的职责是保证项目顺利按需求上线，别的不管。而产品经理要自始至终的管理一款产品。

3.产品运营：运营是产品经理最主要的职能，但不是全部

五、产品经理的核心技能

“控制”是产品经理的核心技能。

要对产品的一切细节了然于胸，要对产品涉及到的方方面面有所了解，要能够控制产品团队（设计、技术、运营等一切环节），要有高超的沟通能力和技巧，要有极强的成功欲望和非常主动的做事态度。

六、总结

所以真正意义上的产品经理是很难得的，压力是很大的，待遇是很高的，人才是很稀有的

头顶产品经理title的人99%不具备产品经理的资质

也许你认为我写的这些要求太高了，但事实上一名合格的产品经理的确应该具备的基本素质。

希望大家共同努力，朝这个目标发展。

压力是巨大的，困难时巨大的，成就是巨大的:0

重申一遍，产品经理管理的是产品，不是人！

产品经理没有直接管理业务支持方（包括美工、技术、客服、市场）的权利，这是产品经理制度的管理学基础，这个是不能动摇的。如果产品经理有权利支配支持方，那是事业部制度。而事业部制度的核心是独立核算，自己是一个独立的利润中心 + 成本中心。但是产品经理制不是这样的，产品经理只是利润中心，不是成本中心。即便是有了产品管理团队，他们一般那也是和其他业务共用基础性资源：如美工、技术开发、市场合作等。但是不排除个别产品使用一些成本性资源，但是那不是常态。比如我们有一个产品招了个专职BD，但是大家都知道这个BD是临时归产品经理管，他最终还是会被市场部招安的。

这篇是将来那本书第一章某段的初稿，之前一节的内容是《我们到底是不是产品经理》的改进版。大家看着会不会觉得语言生硬了很多，-,-bbb

我们可以看到，都叫产品经理，但做的事情已经发生了很大变化。不过，你可能还有一个疑惑和一丝忐忑——平时我只做上述谈及的一部分工作，这样也能叫产品经理么？不但是传统意义下的产品经理，就算是新概念下的产品经理的职责，也通常分给几个人或几个部门做。很少有真正的全能型产品经理，就算全能，也会因为个人精力限制，在某个时间段只会专注某方面的工作。或者只能是对每个方面都蜻蜓点水，而这样的角色只能是事业部的总经理，或者公司的CEO了。

于是，我们很多人成了新概念下的非典型产品经理。

这两天我又翻开《产品经理的第一本书》，试图在传统产品经理的框架下找到一些线索，果然在最后一章，也就是第十四章《产品管理总将走到尽头？》里，发现哥乔斯早就发现了这些问题，作者谈到了各界对产品经理、产品管理制度的质疑，提出产品经理制度仍需要不断修正，并指明了三大变化方向：产品管理团队、事业单位经理的任用、更专业取向。其中产品管理团队（product management teams，PMTs）顾名思义是用团队的力量来代替唯一的产品经理；而事业单位经理的制度则是从项目管理团队的概念发展出来的，把产品强调为一个事业单位，也就是我们经常说的事业部，而产品经理也就摇身一变成为了事业部的总经理，区别就在于总经理有了更大的权力，看到没有，CEO的学前班；更专业取向则比较像我的经历，书中说的也比较到位，摘录一段：

由于企业分派给产品经理的责任愈来愈多，有的公司开始质疑——对产品经理一个人来说，这样的负担是不是已经难以负荷。结果造成现在出现缩减产品经理的责任，让他更为专业化的趋势。至于要求产品经理专注的方向，则因公司或行业类别而不同。……

有时高科技企业会采取类似的做法，让产品经理专心处理产品在工程和技术方面的问题，而把大部分营销决定交给另外的职能单位来负责。在这种情况下，产品经理可能会变成产品技术/应用方面的专家，他最主要的工作就是支援、协助销售人员——至于了解市场和从市场了解产品利益等工作，则另有他人代劳。像这样把营销功能和产品开发活动分开来处理的做法也有风险：产品经理将失去和顾客间的联系，而且会因为对产品太过熟悉，以致丧失判断上的客观性。

不管企业想用怎样的专业取向，以便产品经理更容易地管理他的工作，很重要的一点是，请记住这个职位当初是为何而设——想要更了解产品与它面临的竞争情况，最终目的是要满足顾客的需求。

我想，不管你只是整天写文档、做Demo；还是成了没钱没权的项目经理；或是求完销售求工程师，最后只能欺负客服，到处不招人待见……前辈们似乎也认可——人人都是产品经理，非典型成了多数，也就变成典型。