产品经理 - UCD大社区

优秀产品经理所需具备的7种能力

TingPeng — 2011-12-01 23:12:31

大家好，这篇文章是我让刘奕彤翻译，然后经过我加工，并加上了几句我对产品经理这个角色的理解，发给大家共享。这里所说的七种能力，是指你成为了一个合格的产品经理后迈向优秀的产品经理所需具备的能力。

而你在看这篇文章之前，请问问自己，有没有达到“合格的产品经理”这个标准呢？

欢迎大家在下班时间跟我探讨这方面的问题。请胡晓代为转发晓春和颜彦。

一、沟通能力

成功的产品经理必须是优秀的沟通者。

从我所认识的优秀产品经理们分析来看，他们所具有的最共同特征是“在工作中具有优秀的口头及书面沟通技巧”。

为什么沟通很重要？在许多公司，产品经理最为一个决定性角色扮演着沟通枢纽的角色，如下图所示。

而在不同角色间有效沟通能力，往细了说，就是与不同的个性类型沟通的能力，即在用不同角色沟通的时候讲不同的“语言”。对于有效沟通来说，重要的是你使用目标听众的“语言”。

例如，大多数工程师倾向于是“内向型”，而大多数销售/市场专员倾向于“外向型”。这意味着，与工程师沟通相较而言，和市场专员沟通时需要使用“另一种语言”。同样地，当你和主管沟通时，相对于“树的级别”而言，你必须把更多的表述重点放在更高层次的“森林级别”，然而许多产品经理却错误的依然跟主管们在谈论着这颗树是多么的美丽。

二、没有权力的领导

成功的产品经理拥有在没有正式的权力下也能成为优秀的领导的能力。

多数公司，产品经理被期望在多个领域扮演“领导角色”。这包括领导项目团队，领导产品策划和路线图，领导跨部门沟通等。

然而，在多数这样的情况下产品经理并没有统筹这些部门的权利。

没有权力如何领导别人？我想说，使用联合影响，谈判，关系网和其他类似技巧。

没有权力是否可能领导？我对此的想法被这个问题总结的很好，我的回答是个反问：甘地和马丁·路得金有多少权力？

三、学习技巧

这点，用我彭毅的话来说，就是优秀的产品经理擅长做不擅长的事。

优秀的产品经理必须具备快速学习的能力，市场变化很快，新技术总是拔地而起。 “差异化产品”在今天不到6个月内产生，有时甚至更快。

我认为多数公司在雇佣产品经理时会犯的一个错误是－他们看重“强悍的专业知识”。

举个例子，一个做软件安全的公司，他们寻找一位拥有5年以上软件安全方面工作经验的产品经理。我认为这是一个错误的方法。

更好的方法是，寻找一个拥有软件工程方面工作经验的产品经理，并且拥有快速学习的能力。这种方法对我来说实现的很好，我手下那些最好的产品经理在被雇佣以前，都没有他现在所从事工作的专业知识。

四、商业敏锐度

成功的产品经理对基本的商业原则也有很好的理解。

他们了解如何辨认市场机会，竞争分化的重要性，创造成功产品的策略，定价，促进，合作，分析，声明，及其他。

这并不意味着他们需要工商管理硕士学位。实际上，我接触过的多数成功的产品经理并没有工商管理硕士，但是他们对商业基本原则都有着充分的了解。

五、热爱产品

成功的产品经理对产品有一种固有的爱。

他们因跟上市场上新产品的步伐而高兴，和他们的到手的一样多。他们注册了大量的“betas”网站，下载最新版本的软件并使用，等等。

他们为设计好的产品而高兴，即便并不是他们公司制造的。他们讨厌设计糟糕的产品，即便是自己公司制造的。

他们热爱创造伟大的产品，无论它是一个全新的产品，还是改进现有产品。

六、观注细节

任何事务是由细节组成的，关注细节,是创造伟大产品的必要基础。

Steve Jobs曾经说过：

iMac不仅仅是颜色或是半透明或是外壳的形状。iMac的本质是使每一个元素集中在一起成为最出色的消费电脑。在我们最新的iMac，我坚定我们摆脱了风扇，因为使用一个不会一直嗡嗡作响的电脑工作让人更愉悦。

扔掉风扇不仅是Steve一个固执的决定那么简单，他背后需要一个巨大的工程，计算出如何更好的处理电源功耗，以及如何更好的通过机器散热。这是我们产品出发的核心点，顾客购买我们，就是为了让我们去解决所有这些细节，所以他们容易和喜欢使用我们的电脑。

成功的产品经理观注细节不仅仅是提到产品性能，并且在竞争力分析，项目计划，和几乎每个他们主要负责的活动。

我的话：同样，这种细节体现在你所做的报告中、计划中、任务策划书中。在内容上，请尽可能的描述到实施细节；在表现上，请尽可能的体现一个产品设计师的UI设计细节。如果一个连报告都不能让人愉快阅读的产品经理，怎么指望做出来的产品能有优秀的用户体验。

七、常规的产品管理技能

一个产品经理需要这些技巧来完成日常任务。他们包括写市场分析报告和需求分析报告，执行竞品分析，创造产品路线，陈述产品性能和利益，定义用户界面，等等。

每个公司都需要这样的技能。这一技能放在最后，是因为我认为拥有上述六点的产品经理很容易学到这些技能。

相关话题：产品经理源地址：http://isnewme.com/?p=1050

不做让开发人员讨厌的产品经理

Mrlee — 2011-05-10 15:02:10

首先，没有人会无端讨厌一个人，除非你身上有让人讨厌的臭毛病。而有些臭毛病，自己是可能不认为很严重。这是由于人类自我认知的障碍造成的，无法避免。不做让开发人员讨厌的产品经理，需要首先弄清开发人员究竟讨厌的是什么？于是，我在知乎上问了一个问题：开发人员最讨厌产品经理的哪些臭毛病？

让人意外的是，这个问题引起了业界很多认识的讨论和关注，并跟风产生了设计师最讨厌产品经理的哪些臭毛病？、产品经理最讨厌开发人员的哪些臭毛病？、产品经理最讨厌设计师的那些臭毛病？等问题。不难推测，在互联网公司，不同角色的人员在共同完成项目的过程中，实现天衣无缝的合作总是很有挑战的事情。

诚然，这些挑战可能是由于参与人员的能力问题，这无可避免。但我更愿意相信，沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。知乎上的几个问题的讨论，可能会对各不同角色的人之间进行换位起到一定的帮助作用，无疑，这是一件对各方都有积极意义的事情。

产品经理作为贯通各环节的中心节点，避免一些让人讨厌的臭毛病显得尤为重要。从知乎的回答中，我将这些可能成为臭毛病的行为归纳为以下几种情况：

短时间内可以完全避免的：

需求不清晰，当开发人员问PM需求的时候，发现PM也弄不清楚，这样的问题是一定要杜绝也完全可以杜绝的，如果PM自己都不清楚需求，的考虑这样的工作是否适合自己了。

干预纯技术问题，例如：这个code应该这么写。避免之道:对于纯技术的问题不要干预，如果他的技术实现真的有问题，自有相关的人去负责，产品只需关注他最终是否实现了预期的功能。

交付的方案不确定，开发人员讨厌“其实这样也可以”，“要不就这样吧”的言论，他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候，PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时，再将备选方说出来。

没有必要的预留时间,”这个我们修改一下，明天提交新的版本，一看，列了一大堆增加的功能，并不是仅仅是修改。coder真的不是神，增加的功能是需要测试的。pm给自己留时间同时，可怜可怜攻城湿，留点时间思考吧。”这是一位工程师的原话。Pm要对进度负责，压力很大，但是预留时间是一定要的。

不能完全避免但短期内可以改善的：

需求变更，这是回答中出现平率最高的一个词汇。但是，要让开发人员失望的是，因为种种原因，这个问题并不能完全避免，PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到，使可能发生改变的需求讲到最少；另外一个就是要杜绝需求的往复性变更，不要让从方案A改为方案B之后觉得不行，又改回方案A。

口交次数太多：要避免口头交代，显然不现实，再完美的文档也无法代替口头上的直接交流。但频繁的口（头）交（流）可能会打断工程师的思路，延缓进度。PM可以做一是尽量完善你的文档，第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情，从而减少次数。

需要长期积累或锻炼才能改善的：

缺乏个人魅力：是的，缺乏个人魅力也成为工程师讨厌PM的一个原因了。但是个人魅力这个东西，确实很难在短期内得到改善。甚至，对于个人魅力的判断，不同的工程师会有不同的标准。

经验不足：或者说资历不深，要改变这样的现状，恐怕也非可立竿见影的。

以上，以自勉。

谁驱动公司？上帝赐予食物，魔鬼送来厨师

旁观者 — 2011-02-09 17:04:40

“God sends meat and the Devil sends cooks. 上帝赐予食物，魔鬼送来厨师”——John Taylor

老熊最近跟这个问题较上了劲：

“从目前看到的资料，google、FB都是开发工程师主导的开发模式，而国内的baidu、QQ、360都是推崇产品经理主导，为何会这样呢？”

这个问题估计一万个人看了会有一万个哈姆雷特。

先按下这个问题不表，表一表百度的PM：

百度的PM驱动

其实很多人都曾指出，甚至百度校园招聘时也会强调，百度的PM不是Product Manager，而是Product Marketing，它对应的部门叫XXX产品市场部。

关于PM的定义，百度的@ChenChangming说：PM就是指以用户与市场为导向的产品设计人员。一般主要包括产品和运营两部分，负责产品的整体发展把握，提出对产品升级的需求和活动推广的需求，同时，产品内容的管理和维护也是重要工作之一。（出处：引自推特）

白鸦也就这个问题，撰文指出：“PM就是至高无上的王，不能给他安排婆婆更不能有人垂帘听政”。他引用@bian的话：“（PM就得是）产品经理、市场经理、UI设计师、交互设计师，4 IN 1”。（出处：絮叨“产品”02）

Product Marketing驱动的优点当然很突出了，但缺点就是对PM要求极高。这种级数的PM要么早已占山为王，要么被巨无霸公司们囤货了，江湖上漂着的、挂单的寥寥无几。

那淘宝是什么驱动呢？天涯社区呢？这又要说到四种驱动了：

四种驱动

运营驱动：

典型代表是如今鹊起的团购网站们。淘宝和天涯社区都属于运营驱动。当然你也可以认为产品驱动让一个互联网应用诞生、广为人知并进入成熟期，接下来一定是运营驱动。

产品驱动：

典型代表是腾讯。当年的移动SP们也算是产品驱动。

产品市场Cross驱动：

即前面百度式的PM驱动。这属于跨界了。正是因为大公司矩阵管理复杂，市场部、运营部、产品部大家都是VP，谁也不鸟谁，所以必须得找一跨界的，两边都特懂，才能震得住四方、综合考虑问题。

工程师驱动：

工程师驱动还得细分。第一种，工程师（及其技术团队）拥有一整套技术解决方案，所以手中握有“锤子”，满世界寻找“钉子”。这种你可别认为举锤子找钉子不靠谱。举一个例子，下村脩对生物发光非常感兴趣，于是课题选择了研究水母发光，两年间杀了成千上万只水母。终于他从一万只小水母中纯化出5毫克发光蛋白，同时还分离出一种“绿蛋白”，在紫外光的照耀下会发出绿色荧光，这时是1962年。但为了更深入地研究这种绿色荧光蛋白（GFP），他需要在一个夏天抓2.5吨也就是5万只小水母，于是妻子儿女齐上阵，抓了N年。终于在1974年，他纯化到了这种蛋白。然而在之后的几十年里，无论是科学基金还是业界，都认为这种蛋白没有应用价值。直到1994年，华人钱永健，第一位致力于改造GFP的人，终于让它有了实用价值。通过使用DNA技术，研究人员现在可以将GFP与其他令人感兴趣、但经常肉眼无法看到的蛋白联系在一起，GFP这种发光的标记工具使研究人员可以看到被标注的蛋白的运动、定位、互动。研究人员在GFP的帮助下可以跟踪各种细胞的命运。毕生抓了85万只水母的下村脩，他的GFP锤子在三十年后终于砸到了钉子。

第二种工程师驱动，具有极强动手能力的技术工程师，又能非常感性地总结第一手需求，最终制作出天才的作品。最佳例子就是Gmail。（QQ邮箱应该算是产品驱动，这一点可以参考《我在QQ邮箱的这四年》一文来看，“（Foxmail的作者张小龙）在QQ邮箱的整个发展过程中不是以技术人员的身份在指导，如果要用一个最合适的身份来形容他，我觉得是产品经理”）

“We all live in a house on fire, no fire department to call, no way out. 我们都生活在火宅之中，没有消防队可找，也没有出路可逃。”——Tennessee Williams

工程师驱动的问题

一，既理性又感性的engineer在中国大陆很少，拜我们僵化的教育所赐。

二，中国大陆60、70、80年代出生的engineers受生活所迫，对社会生活的接触面较窄，不太容易体会到普罗大众的第一手需求。他们更擅长把自己的第一手需求变成现实，如万能五笔的邓世强，Foxmail的张小龙，超级解霸的梁肇新，FlashGet的侯延堂。

但，幸运的是，程序员喜欢玩游戏的铺天盖地满大街都是，也因此在游戏行业，大量的技术驱动公司顺势而生。所以，说句玩笑话，工程师驱动比较适合宅男领域。

我经历的各种驱动

我最开始入行是在传统软件项目公司，在几个微软顾问的指导下开展项目管理工作，所以对MSF很熟悉。在MSF里，一个项目分成六个角色：程序管理（一般叫项目经理）、产品管理（一般叫产品经理）、开发（一般叫开发经理）、测试、部署、用户培训。在传统软件项目中，程序管理角色，也就是项目经理，这个角色肯定对技术门儿清，所以可以视为工程师驱动，虽然这个工程师驱动更强调计划、进度和协调。

由于对运营和产品感兴趣，想学习一下商业公司具体是怎么运转的，所以到了当时如日中天的移动SP公司，见识了产品驱动的模式。

几年后做玩聚网，研究语义技术，研究mashup，有时候属于第一种工程师驱动，有了锤子想找钉子（比如股市风向标“宝聚”）；有时候属于典型的第二种工程师驱动（如玩聚SR）。

现在呢？估计马上就算运营驱动了。

最后回到引子的那句名言：“God sends meat and the Devil sends cooks.”，作为产品出身的你，也许会认为上帝让你创造了一个好的产品设计，但魔鬼给你送来了一堆垃圾工程师；作为研发出身的你，你也许会想魔鬼带来的这个产品经理，需求改得那叫一个子龙大战长坂坡七进七出，把兄弟们折腾得不善。所以，强者为王。

产品经理如何推进团队执行力

seraph — 2010-08-11 09:43:44

按，前天参与了一次Podcast的录音座谈节目，其中聊到如何推进团队的执行力，略有心得分享，整理以记之：

1、产品经理首要确定的工作原则：战略决策产品，产品驱动开发；

2、结合实际情况，设计可执行的工作流程，明确各职能环节的工作成果输出（原型/界面设计，需求文档/思维导图或流程图）；

P线：产品管理，产品设计，界面设计，交互设计，及其它
T线：项目管理，技术架构，技术Leader，开发人员（前端，页面，后端，服务端，数据端，运维等）

3、尽可能的明确可度量的工作成果标准，由P线经理提供需求要点纲要，表明要做到什么，不用做到什么，T线经理根据需求与相关人员共同设定工作目标和标准；

虚拟示例：某功能模块，进行V2版本优化，2周为一次迭代周期，共2个周期

需求要点是：功能性流程与V1版本相比无增加点，重点是实践前后端分离的开发模式重构该功能模块的实现代码，交付给用户更有惊艳效果的操作流程，强化每个操作环节的引导或提示体验

第一个周期的关键是：需求明确，各职能角色的充分交流

第1周目标是：P线成员完成产品细节需求策划，T线成员相关技术架构的预研
第2周目标是：需求策划完成交付，二个关键展示页面的技术功能性开发完成

第二个周期的关键是：保证质量，在进度内完成既定目标

第1周目标是：所有技术功能性开发完成，关键业务流程可以走通无误

第2周目标是：所有需求策划细节开发完成，重点是用验设计、界面设计无损实现

此产品开发组团队共4人：责任产品经理1人，技术骨干兼项目经理1人，相关技术开发人员2人；周边支撑资源：界面设计、、交互设计、页面制作，约6人/天

4、抓住一切机会点，在团队内告知及说明工作原则和流程标准的重要性，特别关注对老板的告知；

5、对于执行过程中的各职能环节协调问题，保持高度的敏感，最及时的处理此类问题；

6、对不同职能角色的沟通技巧，产品经理本身需要在思考上有相当的弹性来去适应不同的角色思维模式，老板，技术Leader、成员，界面设计、用户体验、前端开发、客户等

在和P线角色沟通时，要适当的讲解技术实现相关原理，能做为什么，不能做更要为什么，并在满足需求本质的前提基础上，提出妥协或更合理的解决方案；

在和T线角色沟通时，尽可能说明该功能需求的来源，用户反馈次数和态度，分析其合理性，以具体案例和模拟用例来推演出合理性；

虚拟实例：项目管理=》项目成员管理与授权功能=》产品提出需要可以增加部门为项目成员

已有功能流程：进入项目成员管理，可选择部门下拉框=》员工下拉框，点加入成员

产品的思路：选定部门后，即可直接将该部门加入项目成员，让项目经理操作减少，当部门员工离职后也无需再取消该员项目成员身份

技术的思路：该需求技术可行，需要涉及到的功能点有，项目成员管理界面可增加部门，部门绑定的权限角色被授权，3个其它功能模块中类似的人员选择区做同样的处理，约2-4人/日工作量。

我的分析：能理解该需求思路，选部门的出发点在于减少项目经理操作次数，这个能认同，但一个项目经理在此项目里选了部门为成员以后，如果该部门有人员增加而又正好不是参与该项目的，岂不是还要再回来把这个项目的成员里去掉这个部门，再加上原有的员工；其二，这个漏洞虽然很小，用户实际操作中碰到的几率很低，但既然我们提供出这个功能，就一定会有用户使用到出现问题，那岂不是违反了我们做这个修改的目的：改善用户操作，获取用户认可。须知，对于用户而言，我们做的更好是应该的，大部分用户未必感知到，感知到的用户也未必会传播；但如果我们做了一个会出某问题的产品，大部分没出现该问题的还是沉默状态，出现问题的就一定会进行传播反馈（抱怨不爽投诉。。。），影响到本来没此问题的用户群体了。

结论：需求决策的原则：产品环节对没有问题的解决方案进行判断或优先级选择时，可以按关注用户几率的多少来进行，但如果有问题的方案，就不能按用户关注几率来判断，哪怕只有百分之1的用户有可能出现问题，就是致命。该需求应该寻求其它解决方案。

我的方案：项目经理选择部门后，人员下拉框里第一项是“加入该部门所有员工”，产品认为可以满足需求的出发点，技术认为需要投入的工作量约0.5人/日，达成共识；

7、以合理的方式展现团队的各阶段工作成果，一则收集需求反馈，二则收获公司及客户的认可提升团队士气；

综上，主体的思路是：确定原则，明确战略，设定标准，统一思想，持续沟通，修炼技巧，展现成果。此次主要是对设定标准和沟通技巧分享两个例子，其它的环节有机会再谈谈。

相关话题：产品经理源地址：http://user.qzone.qq.com/312950/blog/1280751839

我理解的产品经理

kent.zhu — 2010-08-10 22:09:26

本文，我从一个新手的角度去记录我所理解的产品经理是什么。仅代表个人观点，仅从一个没有UED支撑的从业者所思所想出发，肯定会有错误，欢迎批评探讨。

前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了……

首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。

1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。
2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。

第一种流派是目前几个大公司的产品经理流派，每个产品经理最终的发展方向不一样，有专注于设计的有以管理为方向的，然后P1、…、P12，M1、…第二种是我自己杜撰的，基于我自己的理解，个人为人第二种缩写的解释会更适合我理解的产品经理。

产品经理是永远从需求出发的立足于产品的有良好运营思维并擅于团队作战的狼首领。

记得早前在微博上有一条关于产品经理的微博流传甚广，被转发很多次，我是这样回复的：“我们只是：开发里面最懂UI的；运营里更注重用户的；战略中比老板更知道从细微着眼的；销售中比运营更了解产品的；比谁的权利都低但比谁都会运用权利的；产品做好了最容易被遗忘的那个小人物”。这是我对我理解的产品经理的第一次概括。下面详细说下

1、产品经理首先必须要对所从事行业充分了解，先是行业专家。深度了解这个行业的用户行为、行业规则、行业特点，或者至少是资深用户，才能培养自己的同理心，才能把握住整个产品的发展方向，最终去做产品。

2、产品经理是个立足与产品有运营思维的人。之前我说，产品设计师都是自负的，他们思考问题的方式在于这个事情应该是什么样子而不是他现在是什么样子；工程师同学永远都会先考虑功能实现然后考虑是什么样子；而市场运营同学考虑问题在于老板给我的预算额度是一定，我怎么分配这些市场费用能够达到收益最大化。所以，产品经理同学就必须兼备以上的思维，在做某个决定的时候同时“人格分裂”的从这三个方面考虑一遍。

在产品团队中，产品经理必须时刻记得问自己这样几个问题：我的核心用户是谁？他们在什么情况下有这个需求？这个产品的目标与期望值是多少？并且，要让整个团队的人都有问这几个问题的意识。需求，永远都是最根本的，如果产品经理搞不清楚这个事情，那么交互设计、视觉设计、工程师都会跟着错！产品经理草率的告诉交互设计师说我们需要上一个某某功能，交互设计师有责任有义务询问产品经理，为什么要做这个，给谁做？然后才是开始去做设计！否则就只是个工具。

3、产品经理要在团队中扮演寻找满意解的角色，而不是最优解的角色。如上图所示，产品设计、市场运营、工程技术3个部门关注的产品的点是存在重叠的，而产品经理就是去发现这个重叠的部分并很好的利用这个重叠的人。

满意解的意思在于，产品经理是基于“权益”的标准来进行团队沟通的，而不是基于权利或者权力，这个解需要平衡团队所有成员的权益。所以，我一直认为，“马化腾、史玉柱等是中国最好的产品经理”的说法是有问题的，他们应该被叫做“拜用户教”教徒以及“UCD型Boss”，他们算不上产品经理。

4、产品经理的核心技能在于沟通与控制。团队以及合作的观念必须时刻具备，当团队里每个人都受到鼓励、赋予了权利并且被尊重与信任的时候，团队就会有最理想的表现。从另一个层面上看，以团队意识为核心的结果往往会是没有核心，平衡了各方的利益之后，往往把本来最有利的部分完全抹杀了，敢于拍板和为自己的决定负责对产品经理来讲很重要，也就是要讲究控制，或者按照百度的话说叫做“和多数人商量，听少数人意见，自己做决定”。记得之前有位前辈给我推荐过一本书《只有偏执狂才能生存》，受益颇多。

你可以有某个领域不会，但是，你要有能力指使会的人去做。当然，也有必须什么都去做的产品经理。我把国内目前的产品经理分为两个类别：有UED支撑的产品经理（雌雄异体）、全能型产品经理（雌雄同体）。在有UED支撑的情况下，产品经理不太需要去关注产品具体的设计细节，产品经理更加偏重于如何去沟通，去解决问题；而没有UED支撑的产品经理更多的在于学会如何最大限度的利用资源，由于从设想到实现几乎都是一个人来做，所以，偏颇在所难免，寂寞是产品经理最要命的敌人。

5、产品经理一定是最爱自己产品的那个人，并且，我觉得只有自己一个人爱是不够的，同时还需要让整个团队的成员都植入这个观念。这种爱不是溺爱，我觉得有2个方面：擅于且敢于主动的自我阉割，开放的心态接受一切批评意见；不断的向大家介绍你的产品，并推荐之。为了爱产品需要有狼性，如我在微博上所说，产品经理应该明白，资源是靠“打砸抢”得到的，别指望别人施舍；社区的运营与产品设计者也应该明白，要做好社区就必须要有铁血政策，特别是在一个充满刁民的社区，当然，对部分意见领袖的怀柔也是必须的！

6、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。

没开始写之前我觉得我想的挺明白的，可是写着写着发现这些话好像是直接对我微博上说的过的话进行总结与摘抄，然后再读一遍发现好像都是废话…..不过，好吧，也许最难做到的就是那些正确的废话了，我还是记录下来了，我会不时回头看看我走过的路我思考过的痕迹的

相关话题：产品经理源地址：http://www.ikent.me/blog/3019

从技术层面面试产品经理

挑灯看剑 — 2010-06-26 19:04:11

豆瓣有个交叉面试的惯例，目前主要是在产品经理和工程师两个团队之间。作为技术团队的代表，我经常和来应聘的产品经理聊聊，从以下两个方面给产品经理团队参考意见：

1、面试者是否有足够的技术素质
2、面试者是否具备和工程师协同工作的能力

第1点，假设是：在一个以快速变化的技术为生产力的行业，如果技术方面的素质太差，能力会大受限制。

第2点，假设是：工程师有独特的个性需要尊重和理解，产品经理如果了解不够，会增加很多工作中的障碍，甚至摩擦。

相对来说，第2点是比较容易考察的，从主观和客观两个角度来看即可。主观方面，看他对合作过的工程师的看法、期望、评价。客观方面，看他和工程师合作的细节，如流程、工具、交付物、解决争端的方法。

比较难的是第1点，很长时间我一直拿不准分寸。工程师们不愿意和完全不懂技术、不理解技术开发的规律、听不明白技术问题、会做出违反技术原则的产品决策的产品经理合作，但是怎么能在短短的面试中发现这些潜在的问题呢？总不能要求人家会编程序吧！

在经历了若干次交叉面试之后，思路有点清晰了，大概应该从两个角度来看：
1、好奇心：平时是否关注技术发展，是否有从技术角度想问题的习惯
2、理解力：遇到一个全新的技术，能否快速理解，并说出它的优势、局限性、可能的用途

前者，可以用一些没有标准答案的开放性问题入手，看看他的思路会发散到什么方向去，有些人习惯于想到技术因素、领域，有些人总是回避技术，差别很明显。

后者，可以现场给他讲解一种算法、一个新出现的技术、一门新的编程语言、一种技术开发过程的常见问题，看他能理解到什么程度。

还是不完美，好在交叉面试只是提供参考意见，不是决定性的意见，我的压力没有面试工程师那么大。

相关话题：产品经理源地址：http://www.douban.com/note/77760672/

人人都是产品经理么？

songvision — 2010-05-31 09:31:57

很荣幸收到苏杰同学快递赠送的《人人都是产品经理》，除价值不菲的签名外，还附了长达三行半的留言。于是，我决定好好看看这本书，在这之前我没有翻过任何“产品经理”主题类书籍。

概括的讲，我认为《人人都是产品经理》做的很不错，在内容方面，刚毕业就能有这样的“积累”意识，并且开花结果，这其实是非常少见。这本书的用户群定位，以及前因后果，作者交代的比较清楚。但是我估计，还是会有很多“新手”误解，因为书的内容有些模糊。我写了这么多年blog，深有体会——绝大多数提不高的从业人员的问题，不是看的书太少，而是不擅长独立思考。顺便说一句，这本书不错的背后，我认为出版方“博文视点”的功力值得其他同行学习。

如标题，首先我本身对“人人都是产品经理”这个命题产生怀疑，我第一次看苏杰同学blog也在纳闷。因为“产品经理”这个定位是出了名的困难，同时大家也认可，目前互联网圈子里合格的产品经理也没几位。“人人都是产品经理”这样标题影响力越大，越容易造成大家误解“产品经理”的分量过重，越容易造成大家误解“产品经理”的门槛过低，3页上有我当时与苏杰讨论的一段话：

一是用户群，二是切入角度，两点结合把握好即可。是给理想主义者参考的精神启发？还是给普通从业者找口饭吃的普及教材？或者打算包罗万象、点到即止的大全？我理解的好书，思想永远走在时代的最前头。书的好坏往往在一开始就已经注定，只不过最后的成功需要筹码和时间的等待。

我认为做产品经理，首先与人的性格和思维方式有关，其次是知识背景，比如我就完全不适合（经常有人误认为我是产品经理）。做好产品其实需要各个维度去推动，相应需要各种擅长职能的人才。全书读完，我发现有两个问题特别模糊：

没有分清楚“产品设计师”和“产品经理”的定位区别？
没有分清楚“项目经理”和“产品经理”的定位区别？

比如115页，倒数第二段说了产品经理和项目经理的缩写都是PM，但是书里又出现了无数个使用PD代称“产品经理”的说法。到最后，我也没搞清楚，作者是认可PM还是认可PD？在我概念里PD是产品设计师(Product Design)的缩写。

产品设计师还是产品经理的问题，我在互联网产品设计师职业生涯有过详细的阐述，我认为管理(Managment)和专业(Professional)还是应该两条线并行。顺便提醒，47页（未具体其他）底部脚注的“UCD是User Centered Design的缩写”有误，应该是“User-Centered Design”，中间差个连接符。

以上两个问题现在不深入探讨，其实也是内业长期在讨论、争论的，基本上90%公司都很混乱。从专业角度讲，我理解苏杰早期是做产品设计师，升职到了产品经理，可能再被迫兼了项目经理职能。我知道这在阿里集团的价值观里，叫“拥抱变化”。

我不是否认这本书的价值，我做过书，了解做书的艰辛。每个人都有不同的阶段，任何经过发酵的积累，必然可以受益于一大批人。当然，这本书如果叫《人人都能做产品》，副标题“中国特色互联网产品实践”，我想那就不会造成误解了。

让我想起之前在个人知识管理经验中写过的一句话——知识积累需要时间来沉淀，只要找准一套方法，深入尝试必然有结果。苏杰同学很有想法，是位有潜力的产品经理，他的积累态度值得所有互联网从业者学习，尤其值得所有还在迷茫的互联网新手们参考。

相关话题：产品经理源地址：http://blog.rexsong.com/?p=10431

产品经理，请澹定的走下去

江洋 — 2010-07-11 11:47:20

产品经理这个职位似乎在国内还是在互联网和软件公司里比较普遍，但世界上第一个有产品经理职位的公司确是传统行业—保洁公司。但因为国内的其他传统行业发展慢，以及大多处在体制内，所以可能有这种职位的比较少，而中国的互联网行业，或是整个的IT行业，历史短，且发展初期就是与国际接轨。当然，传统行业中的产品经理和互联网或是IT行业的产品经理概念和意义不太一样，也不能放在一起讨论。

我理解的产品经理是这样，这里的“经理”并不是传统意义上的经理，所谓产品经理是指要对产品负责的经理，包括对产品初期从无到有，到整个生命周期跟据都要负责的经理；此处不讨论产品经理工作范围和内容……

也许你和我一样，认为产品经理和产品设计师和用研分析师根本就是不同的职位，你认为产品经理只是UED团队中的一个成员，但在大多数公司里一个产品经理可能要做整个UED团队中除了界面设计及前端开发的所有工作，甚至还要他娘的做数据统计工作。

也许你和我一样，根本不爱听销售人员天天和你讲用户体验，根本受不了他们希望页面上充满广告，也根本受不了BCD思想左右着你的设计。

也许你和我一样，为了自己热衷的事情，把一款产品当做自己的孩子，而不顾及加班到深夜，倾尽自己全部。

也许你和我一样，也会看到在这个圈子里的其他职位似乎过的都比自己好，混了4年的编辑，已经是主编，每周都有这么几个会，每月都能出个差，都能拿上不算少的车马费，随便写点东西也有稿费；混了4年的销售，也已经积累了大量的客户关系，工资可以忽略，一单大的提成顶你干上半年；混了4年的市场，已经取得领导信任，搞搞活动，做做PR，自己压点回扣，老板也挣一眼闭一眼……。

也许你和我一样，自命不凡，觉得自己是一个产品甚至一个网站的灵魂，认为是这个产品的乔布斯。

也许你和我一样，以前是工科计算机出身，会点代码，有点逻辑，但又都忘了，与工程师沟通时，觉得自已似懂非懂，又想表达自己：我是懂技术的！

也许你和我一样，无奈的时候，会想到上面这些。

诚然，上面这些情景可能很多是不正确的。

但我相信你和我一样，这是一个年轻和有希望的职业，我们是一个年轻的群体；我们是一个公司中没有权力，但又涉及业务最多的人员，我们不仅需要与各个职能沟通100遍，沟通1000遍，回来还要闷头干上十几个小时甚至更长时间。

此文纪念自己工作4周年，我周围的产品经理也好，产品设计师也好，所有与产品相关的兄弟姐妹，我们要不断学习，共同努力，我们要做出让更多用户有用，可用，好用的产品。

让我们一起澹定的走下去。

相关话题：产品经理源地址：http://pcuseman.com/?p=155

产品经理的核心价值

思域 — 2010-07-14 23:45:40

在足球场有那么一群人，他们凶狠的拼抢不断的传球、他们思维敏捷视野开阔、因为处于兵家必争之地所以往往血溅当场、他们是球场上的发动机，控制着全场的节奏、他们调配团队的资源，把球精准的传送到最有机会的队友脚下，这群人就是中场核心，西班牙的中场核心，大师级人物—哈维。

在现今的互联网行业中也有这样一群人，他们被称为“产品经理”。

互联网并不像世界杯具有80年的历史，所以团队中的人员分工和定位相对模糊。特别是近几年才在互联网出现的产品经理这个工种，已经有越来越多的人参与到讨论产品经理的核心技能、核心职能、核心价值是什么的问题中来。

在此，仅和大家讨论一下产品经理的核心价值，我想，只要认清了自身的价值所在，其他的迎刃而解，或者根本无需解。不管黑猫白猫只要能抓到老鼠就是好猫，无论你用什么方法、无论你是否有职权。

此文较长，看完估计得15分钟。

用了大量的内容来把产品经理的核心价值一层一层的剥开。

首先，整理一下互联网中的产品生命周期都会经历哪几个阶段。

需求收集、设计规划、开发、上线、运营推广或者市场销售、在市场和运营过程中产生新的需求、新功能的设计规划、开发、上线…… 一直迭代下去。“产品经理往往需要贯穿在产品生命周期的这整个流程中。”这是现在很多产品经理的理想。

好的，我们继续往下剥。将产品的每个阶段逐个分解，看看产品经理在这个过程中所起的作用。这是很重要的一步，所以我会说的尽量详细。

一、需求分析

在这一步，很多的产品经理花大量的精力去承担文案撰写的角色，这是误区！因为还有更重要的事情需要产品经理在这个时候去做。

1、了解公司的战略目的

也许“战略”这个词有点冠冕堂皇，可是产品的未来与这一步息息相关，所以不妨提到这个高度来讲。以我的经验，互联网公司要推出一款产品的动机大致四种

A复制：看到市场上同类的产品比较成功，结合自身的资源觉得可以效仿。对于这类产品公司仅能看到眼前利益，远景不明朗，需要一边做一边调整，结果多数是大起大落。例如最近狂热的团购。

B干扰：商场如战场，很多企业会玩声东击西的策略，用一些无关痛痒的产品吸引竞争对手的注意，以欺骗或者干扰对手的注意力，掩护自己的核心业务平稳的发展。此类产品往往成为炮灰。

C打圆场：对于上市公司而言，为了给资本市场一个好看的答卷，经常会用一些莫名其妙的产品来滥竽充数，虽然对用户和行业没有任何意义，但是可以让股东和股民看到企业的产业链条是圆满的。此类产品多数是企业的纯消耗品，因为没有实际的盈利模式，所以都是其他产品在养着他，其结果是没有地位。

D战略性产品：很多互联网企业从大众市场纷纷开始进入细分市场，这就要求企业敢于创新，在创新的过程中往往伴随着很多改革，企业会从新定义市场、制定新的目标，推出新的产品，希望改变现有的盈利模式和业务框架、市场格局。这便有了所谓的战略性产品，例如腾讯的拍拍、百度的有啊、新浪的博客、阿里的支付宝，其中有的成功、有的还不明朗，这也正是此类产品的特性。创新和改革的路上异常艰难，很可能这个产品与现有的很多业务冲突、与现有的部门利益不协调。而且企业不会像中央政府那样搞十一五计划给你5年时间，也许你只有半年，所以这要求产品经理要具有很强的把控能力和坚强的毅力。

作为产品经理只有去了解这些才能预想到今后的工作中可能遇到的问题、可能争取到在资源、可能投入的精力、可能组建的团队规模、可能遇到的瓶颈和坎坷，未雨绸缪才成为可能。

所以，不建议一开始就埋头设计精美的PPT、华丽的demo，应该去了解公司做这个产品的目的和动机。

2、了解市场需求

这里也有个误区，很多产品经理通过所谓专业的分析方法例如swot和大量的百度搜出来的数据做出来一个东西，就算交差了。而很少去考虑为什么要去做市场分析，如果我们每天把很多时间花在应付那些不知道为什么做而做的事情上，将很容易被淘汰。

我认为的目的有三个

A、试探自己的思路与公司的思路是否有偏差，适当的在公司原有的想法上做扩展，加大公司对产品的兴趣。

B、给相关部门吹风，特别是业务团队和运营团队，他们手上正在卖或者正在推的产品可能有很多，你的产品市场优势在哪里？也许不能让他们马上兴奋起来，但是至少应该让他们关注或者积极的反馈意见。

C、自我梳理，写的过程就是想的过程，想的过程就是辩证的过程，很多思路会在写的过程中迸发出来。

所以，市场分析可以包含以下内容：产品对于行业的价值、在市场发展的环境下产品可能的生存空间、产品在市场价值链中所处的环节、预期的市场回报。

关于用户需求这里就不多说了，有很多这方面的文章。

到这里，需求分析阶段算是尾声了，总的来说，产品经理在这个阶段最大的意义就是给产品建立意识形态，有点类似军队出征前的誓师大会，虽然很虚，但是对将来的工作很有帮助。

二、设计规划阶段

在这个阶段，开始有越来越多实在的交付物出来，例如：产品规划方案、产品demo、需求文档等等。

1、产品规划方案

无论这个方案是不是由产品经理本人来做，产品经理都应该要求这个规划方案中说明白几个问题：

（为什么做）产品背景和需求说明
（做成怎样）功能说明
（如何实施）里程碑和时间计划
（回报）投入和产出比
（如何经营）运营策略
这是产品从虚到实一个很重要的过渡，把之前天花乱坠的产品思路通过这个方案告诉大家如何实现，并且是有计划有里程碑式的实施。

如果把产品经理比喻为一枚陀螺，这个方案BOSS拍板的一刹那将成为陀螺的分水岭，在这之前鞭子缠绕着陀螺在蓄力，拍板声一响鞭子猛的抽开，产品经理就开始疯狂的忙开了。

2、产品demo

有了需求，自然就有了功能，各种功能组合生产了功能模块，功能模块就搭建起一个产品的框架，在这个产品框架下有哪些系统提供支持，最终画出产品大概的样子。于是功能模块、产品框架、系统架构、低保真原形打包起来就生成了一个产品demo。

产品经理可以拿着产品demo去评审验证了。听取交互设计师的意见、听取视觉设计师的意见、听取前端工程师的意见、听取开发工程师的意见、听取业务和市场的意见、听取用户的意见，陀螺陀螺疯狂转吧！

如果你发现这群鸟人，之前鸦雀无声，现在忽然噼里啪啦的开始拍砖，不要觉得奇怪。眼见为实，大家只有看到你产品的样子才能发表各种意见，而且这些意见还多数是在抠细节。听取意见的过程中，产品经理不会忙于辩解，思维像陀螺似的转起来，意见是否采纳，更多的决定权还在于产品经理，所以你要能够识别各种意见的出发点。有的人会从专业角度、有的人会用改变功能实现方法减少自己的工作量、有的人会站的自身利益的角度、有的人会站在伪用户的角度。如果你应付不来，可以把大家的意见记下来，回去好好的考虑。如果一些问题非得会上就定结果，先明确轻重缓急，实在不行就中场休息借机场外求助。陀螺陀螺效率的转起来吧！

关于需求文档，这个就不用说了吧！

在这个阶段，产品经理除了协调各方，还应该想办法建立一种沟通机制，让团队高效的工作。在很多互联网企业，产品是没有独立团队的，都是线条式的贯彻在各部门。

三、开发阶段

这里的开发是广义的，包括UI设计、前端制作、程序编写、运维支持

这阶段提几个建议：

做设计和开发的都不是好惹的鸟，要么极具个性、要么孤傲、要么执拗。其实这和他们的工作性质有关，创意是需要时间和空间的，建议产品经理们能尽量的满足他们，也许时间是公司敲定的，但是一个良好的发挥空间还是可以提供的。在上面说的广义开发过程中，产品经理往往会遇到很多新的需求，要么是BOSS直接发话、要么是市场部门临时兴起、要么是产品经理自己遗漏。怎么办？要不要加进去？衡量一下吧，如果是影响到核心功能的可以加，如果是边缘化的东西建议放在第二版再加，否则有新的需求就加，这个产品很难在原定计划上线，而且干扰了开发人员的发挥空间，好不容易安下心来思考，又忽然来了新的需求要做，谁都不乐意的，何必呢？相互多一点理解，就少很多抱怨的。

人无完人，没有哪个产品经理能把产品的方方面面想到100%的程度，所以开发过程中，开发人员会有很多问题需要确认，这些问题需求文档里面被遗漏了，所以产品经理需要留有足够的时间给开发人员，如果自己很忙也需要安排一个专人负责协调。

此时沟通的事情占用产品经理的时间不多，所以可以开始花时间考虑产品相关的文案了，这部分我在之前的文章《构建完善的互联网产品文案体系》中有讲到。这个体系的内容如下：

产品上线之后再做就耽误了，也许这些文案不用产品经理本人来做，但是需要把你的想法和对产品的理解灌输给做事的人。不是所有产品都需要这些文案，相信大家能区分。

四、测试阶段

相信有很多互联网公司没有专门的测试团队（QA），甚至忽略了测试这个环节，所以更多是要求产品经理在短时间内协调分工来完成。问题就产生了，没有专业的团队所以测试的结果可能会有遗漏、测试的周期很短所以有的问题即使发现了也需要放到产品上线后解决，这些仍然需要产品经理来协调和分工。

不要抱怨了，把精力放在解决问题上。这里有几点建议：

A、让自己专业起来：在没有专业的测试队伍之前，产品经理就是最专业的测试人员，只有这样要求自己，上线的产品才能做到尽量完善。

产品的测试包含三个重要的环节—功能测试、性能测试、用户测试

功能测试的内容有很多，曾经在某集团任职的时候，公司推出一个SNS社区，其中测试用例一共7130个，QA部门至少需要测试7130个功能点。朋友们可能很疑惑，觉得怎么会有怎么多的功能点需要测试呢？这里截个图了解一下专业测试团队是怎样测试的，特别是对每个测试用例的描述。

虽然专业，但是仍然无法避免问题的出现，所以微软的团队也在不断的在给产品打补丁。提这个的用意在于，不要因为测试的问题成为产品发展的牵绊。作为产品经理仅需要在五个方面做功能测试就差不多了：

A功能流程：根据之前定义的功能模块，以模块为单位分担出去，分担给谁？部门总会有些机动的人，如果没有可以找前端或者UI，引导他们在测试样式和界面展现的时候以功能操作为前提。系统的流程就不多说了，一个功能从头到位走一遍。
B前端与数据库响应：在我们的影响中，一定能够找出数据存储量最大最频繁的功能点，例如个人空间的日志、相册、视频、签名、好友动态等等。测试的时候需要做的仅是操作界面发布看看前端页面是否及时响应，如果之前要求的是同步，测试的时候发现延迟5分钟，说明前端提出数据的时候出现问题。
C浏览器兼容：万恶的浏览器，没有更好的办法，一个一个测吧，可以交给前端开发去测，谁希望自己辛苦做出来的页面用户看到是变形的呢？
D系统规则和机制：在产品设计的过程中，会有很多的规则和机制穿插其中，例如排序规则、录入和显示的字段最大长度、用户的积分经验值等等。注册几个账号开始模拟用户的角色测试吧。
E模拟用户角色：这里的用户是虚拟的，我们只需要关注其是否能达到目的，暂不去考虑过程的体验。

性能的测试，需要产品经理预估一个用户的峰值，然后可以让开发人员去做评估，看看在这个可能的峰值下系统是否还能正常稳定的运行。

用户测试不细讲，网上有很多相关文章。

在一个月黑风高的深夜，产品上线了！有的人告一段落、有的人兜里揣着项目奖血拼去了、有的人休假旅游，唯独有一个人，产品上线对他来说仅仅只是开始，他需要从一个战场转移到另一个战场，这个人就是产品经理。

这里出现了第二个分水岭，有的产品经理会在这里停下，回头负责另一个新的产品。而对于另一部分产品经理来说，公司给他制定的KPI不仅仅只是产品上线，还可能是诸如用户量、活跃度、信息量、转化率、购买率、续费率等等被量化的数据。所以这也成为产品经理积极讨论的问题。因为产品经理被细分了

A、规划型产品经理：只负责产品前期的规划，然后把规划交给需求部门梳理，完事！这类产品经理表达能力很强，无论是语言还是文字图表。但是因为无法参与产品核心的设计，所以往往成为BOSS的代言人。

B、需求型产品经理：更多的负责收集和处理各方面的需求，并且从设计和开发角将讲需求转化为需求文档，完事！这类产品经理协调能力很强，往往能成为产品对外沟通的枢纽。但是因为没有深入到产品的业务和市场方面，所以在需求的权重排列上会很踌躇和痛苦，往往成为背黑锅的人。

C、设计型产品经理：更多的负责产品的可视化设计，例如产品demo、交互设计甚至是UI设计等等，完事！这类产品经理善于把握细节，而且思维活跃。但是往往因为太注重细节和完美，导致很多想法被强势的业务和市场团队压制，很多想法无法实现，非常痛苦和挫败。

D、市场型产品经理：主要负责产品在市场环境下的运作，承担了大量的市场指标。这类产品经理拥有很强的市场嗅觉，而且市场资源丰富，产品上线之后交付给他们打理。但是因为此类产品经理在前期很少参与产品的设计和规划，所以其对产品的理念以及卖点与产品初衷会有偏差，而且会出现利益为先的情况，影响到产品长远的发展。如果此类产品经理把控能力不强，很容易出现产品频繁的调整方向，最终被其他业务合并或者被公司搁置。

从产品经理的分类来看，要找到产品经理准确的定位和定义，并赋予其核心价值真的不是容易的事情，何况每个企业都有自身的特点和组织架构。

我们把思路拉回来。产品上线以后就到了第五个阶段

五：运营和市场销售

我经常把运营分为四大块内容：

A、产品包装：产品要面向市场，就需要做包装，例如建一个网上展台（产品专题）阿里的诚信通 263的企业邮箱腾讯儿童频道。除了这些还有宣传材料（宣传彩页、海报、易拉宝）和公关软文。

B、对外合作：包括推广合作、数据对接、功能整合、利益分配

C、公关推广：媒体互换、寻找G点（市场的兴奋点）

D、策划活动：会议营销、网民线下活动

以上这些工作，也许不需要产品经理本人去实施，但是必须产品经理提出来，并辅助具体实施的人完成。

不是所有产品都有市场销售行为，因为有的产品更多的是支持核心的业务发展，例如论坛、公司内部OA、统计系统、CMS系统等等，但是对于业务要往外出售的产品来说，市场销售这个环节产品经理至关重要，有很多事情值得做。

A、植入业务体系：很多企业的业务体系并非只销售你这一个产品，所以如果利益关系不处理好，很容易出现好产品没人卖的现象。例如：公司给销售员的考核时每月30万，也许你的产品定价5000而且属于年费，而销售员卖一个广告售价10万，那么对于他们来说要完成本月业绩是去强攻3个广告还是卖60个你的产品呢？答案很显然。所以产品经理必须努力的推动产品最终深入到业务体系中去，调整产品的提成也好，捆绑打包也罢，总之好产品是卖出来的，而绝非设计出来的。

B、协同作战：与业务体系一起，找出产品的卖点，包括产品销售过程中的一些话术、容易遇到的问题、客户对产品的兴奋点，都需要产品经理去发现，并且努力做到可复制性。

C、参与制定产品定价：产品的价格能不能根据不同的客户类型进行分档，分档的依据是什么？功能如何区别？

D、建立市场需求反馈通道：市场需求的反馈有通道么？畅通么？如何应对这些需求？是定期和销售员沟通还是参与市场行为？如何识别哪些是客户的需求、哪些是销售员从自身利益出发的需求？

陀螺陀螺转啊转！

对于产品经理的核心价值，在这个层面我们剥了很多内容，朋友们是否隐约感觉到了产品经理核心价值所在？如果还不能确定咱们继续剥。

说完了产品生命周期中的几个阶段，现在提一下产品经理在这个周期中所要沟通的对象，关于这方面我在《产品经理的前世今生》一文中有较详细的说明。这里仅用一个图来说明

蓝色的线条代表了产品经理需要沟通的对象。这也是产品经理核心价值的一部分。

现在咱们回顾一下，产品经理在产品的整个生命周期中其实就做两件事情。

第一件事情是“合”：表现为收集各方面的想法、需求、资源、工作内容和节点

第二件事情是“分”：产品可能涉及到的部门和角落通过产品经理这根导管精准顺畅的传输出去，传输的对象可以是各部门、市场、用户、合作伙伴等等

“价值产生于合，能量释放于分。”这便是通篇所阐述的观点！

不要再纠结下面这张图了

相关话题：产品经理源地址：http://www.pmday.com/archives/300

我不是产品经理！

千鸟 — 2010-07-23 10:13:43

这个问题我说了N的平方那么多次，还是有很多人坚持肯定的褒奖我为“久经考验的产品经理”。最近有人找我去讲课，关于“互联网新的、发展前景的优势产品等”，我一听就头大，这不明摆着所谓产品经理们“战略咨询顾问”角色忽悠的事情么。他们想要什么我很清楚，我的成功也可以复制——类似的“实用主义”路数。

“但是无法粘贴。”有网友补了这么一句话，我认为用来描述中国互联网现状再贴切不过了。2008年1月我写产品经理的责任的时候，号称做“产品经理”的人远远超过做“产品设计师”，近两年应该在逐渐持平，但实际上还是不正常，真的需要这么多产品经理么？一个团队里产品经理与产品设计师的比例应该多少？

在我看来，国内超过80%的产品经理其实多少都在从事产品设计职能。我之所以强调自己是“产品设计师”，是因为我意识到产品设计质量对产品最终用户体验的影响被大大低估，并且将来是拼专业技术的时代。创意一流，设计九流的例子比比皆是，抄别人都抄不好难道还不值得所有人反思么？我希望国内所有从业者都看到老外同行们深厚的技术积累，而不仅仅风光的创意想法。

从职能上区分，产品经理的核心竞争力是对业务远景的把握，可以理解成商业规划能力，重点关心做什么？不做什么？先做什么？后做什么？产品设计师的核心竞争力是对最终实现的把握，可以理解成专业技术能力，重点关心怎么做？做成什么效果？做到什么程度？我坚持认为，搞不清楚产品经理和产品设计师的区别，意味着团队成员责权不分，在某个问题上很可能都认为自己最专业。这些状况在小团队里不明显，因为小团队可以依靠热情、感情来迅速推动，但在大公司大团队则容易形成普遍的“消极抗战”心态，以及谁拿钱多谁说了算的“官僚主义”思想。

为了更好的说明问题，把话题扩大到互联网产品团队，谈谈对团队的看法。我见识过很多创业产品初期只有两个人，设计师和工程师的孵化角色。产品到了一定规模，必然需要长期发展规划和短期监督执行，此时我也认为只需要四类人就可以：产品经理、设计师、项目经理、工程师。

注意是四类人，不是四个人，所谓四类人就是有可能成为四群人。其中产品经理和项目经理走M路线，设计师和工程师走P路线。走M路线的群体根据发展团队规模再扩张，比如产品经理往上可以设立产品总监，项目经理往上可以设立项目总监。走P路线的群体根据所需专业程度再细分，比如设计师可以细分信息架构、交互设计、界面设计、视觉设计等职能，工程师可以细分前端开发、应用开发、数据库开发等职能。

项目最终失败的原因多半是产品本身（而非运营、销售）没做好，而没做好的原因主要有四个。其一产品经理不及格，症状为产品没有市场竞争力；其二设计师不及格，症状为产品不能持续吸引用户；其三项目经理不及格，症状为产品总是不能按时上线；其四工程师不及格，症状为产品问题太多效率太低等。

归根结底，认为自己是不是“产品经理”不重要，关键我们所做的工作有没有对产品成功起到相应的推动作用，这是值得所有从业者扪心自问的问题。真正有效的发展必然有适应节奏，而不是拔苗助长式的去抄袭别人所谓的“成功”体系或者体制。

相关话题：产品经理源地址：http://blog.rexsong.com/?p=9339

中国式产品经理

千鸟 — 2010-07-27 18:24:46

继续探讨产品经理的话题，我看了很多回复，基本反馈的问题可以归结为两类：

老板才是真正意义上的产品经理，而“产品经理”们只是协调和执行者；
只有在“产品经理”位置上才能做产品设计，不然所谓设计可能只是部分交互设计。

产品初期，尤其创业团队做的那种小产品，老板就是产品经理的现象很普遍。而且根据“产品经理应该是对产品理解最深刻的人”的定义，我认为创业团队的产品经理非老板莫属，就得是创意和模式的发起人。

产品还没有上线，或者规模和影响力也足够小。所以老板有空闲有必要事必躬亲，甚至陪着创业团队封闭开发，主导产品的市场定位以及发展策略。但当产品发展到一定规模，需要扩展产品群的时候，此时老板的时间和精力必然会受影响。包括各种行业聚会、公关合作和圈钱座谈，也包括黑白两道来收保护费，都免不了大把时间吃饭喝茶。终于有一天，老板们开始觉得力不从心，最好能有个对产品理解与自己相当的家伙来代行产品经理职责。

挖产品经理通常是不太现实的，专业能力是一方面，忠诚度是另一方面。产品是公司的命脉，而产品经理则是产品成败的关键。比较靠谱的办法是培养产品经理，也就是在公司做产品所有职能的小弟小妹里精挑细选认真比对，能入法眼者用心培养并委以重任久经考验，最后光荣上岗。

原则上实行一位产品经理带一个产品的“终身制”，有两种情况可能需要调整。产品横向发展，在产品规模拆分扩大形成产品群的时候，需要更多产品经理加盟（大公司经常可见）。产品纵深发展，原有产品经理发现对此项业务的理解已经跟不上产品发展的脚本了，此时需要对此道更精通的产品经理来把控（小公司经常可见）。

以上基本就是“产品经理”在大小公司的发展状况。另外，我一直在试图把“产品经理”和“产品设计师”这两类职业给割裂开，不是完全断绝，起码各自的核心竞争力得清楚。观察国内早期小公司最普遍的产品线组织架构如下：

老板——实际在从事“产品经理”职能，提目标和策略。
产品经理——实际在从事“信息架构、交互设计”职能，做规划和方案。
设计师——实际在从事“界面设计、视觉设计”职能，美化页面。

这套方案在中国互联网碌碌无为的执行了很多年，直到某年某月，一群设计师高呼“以用户为中心”试图赶走牛鬼蛇神的时候，顺带想把做“规划和方案”的权利也霸占。产品经理们才猛然发现他们不可能触及“目标和策略”，于是气急败坏的冲设计师们喊“那还要我们干嘛？”问题的焦点汇聚到“到底谁做产品更专业”这个问题上，产品经理们认为“年轻的设计师没有太多互联网经验”，设计师们则认为“自大的产品经理们过于自信并忽略了用户感受”。

在权利和体制范围之内，每个层级的人都在试图把自己拔高，这类现象在国内司空见惯。社会上流行“产品经理”，于是某些人认为自己也“应该”是产品经理，先有目标再谈能力，先有理想再谈兴趣。还有些现象我觉得简直就是冷笑话，比如某公司“产品总监”下边管着一个人（姑且认为是为了名片好看吧）。记住，故意而为之往往都没有好结果，包括某些创业小公司也贴大字报招聘“交互设计”职位（此规模不需要细分设计职能）。

归根结底，还是大家对“做产品”和“做设计”认识的狭隘和理解不一致。绝大多数互联网从业者，早些年认为设计约等于美工，无非美化一下页面而已。这些年逐渐接受了新思想革命，认为设计还约等于交互，可以优化一下流程，仅此，但总算又进步了一点点。

这个问题我思考了很久，觉得不应该单独考虑提高设计师们的专业水准，而是得从上往下贯彻思想，让产品经理们对自己有个清醒认识。套用革命领袖的话，坚持“两手抓，两手都要硬。”

相关话题：产品经理源地址：http://blog.rexsong.com/?p=9639

中国式产品经理（二）

千鸟 — 2010-08-02 18:07:08

互联网产品经理的背景也是个有趣的话题，做事风格严重受影响，常见有三类：

商业出身，对设计和技术了解皮毛或者干脆不懂，可能对互联网了解也有限；
设计师出身，对技术了解皮毛或者干脆不懂，可能过于关注产品细节；
工程师出身，对设计了解皮毛或者干脆不懂，可能更关注项目管理。

三类人我都打过交道，经常碰到工作一两年的设计师、工程师兴致勃勃的讨论要转行“做”产品，我知道他们其实就是想做产品经理。有些人是真的发现自己性格特质不适合继续做P，而有些人纯属心血来潮（先有目标再谈能力，先有理想再谈兴趣）。根据我的经验，除了有行业经验和江湖个性先天优势的第一类人，第三类人工程师出身的优秀产品经理也不少，反正只要有模式就可以动手创业。对比之下，设计师创业经常只能先做出一堆原型，却无力开发。另外，设计师本质上都是比较宅的一类人，不善于主动沟通是通病，因此拥有资源和能力转行成功者极少数。

前文我的本意，如果老板愿意并且有能力来做产品经理，大家老老实实从事“产品设计”职能就行了。或者你虽然顶着“产品经理”的头衔，但自己心里应该清楚目前做的事情是什么？对应到产品生命周期的哪个点？否则你没有办法控制或者适应节奏。

个人认为产品经理的职位还是偏重执行，其一对老板所提目标的理解，其二对实现目标过程的规划。凡产品都有“大产品”和“小产品”之分，而就算产品再小，其执行也有“战略”和“战术”之别。国内很多产品经理对自己的定位都是“杂家”，就是什么都懂，什么都不精的角色。用设计师朋友的话说，现在的产品经理“什么都可以做一点儿，又给人感觉什么都不太专业。”

那么，产品经理的核心竞争力是什么？是那些虚无缥缈的理论，还是貌似专业的方法，又或神神秘秘的潜规则。似乎圈子里衡量某产品经理能力，HR评定某产品经理工资级别的唯一参考，就是他们的工作履历。虽然大家都心知肚明，东家知名度与员工无必然联系，甚至平庸混混的比例与公司规模成正比。所有一切的不对等和不真实，都有可能成为影响团队凝聚力，降低团队战斗力的定时炸弹。

之前谈到了小公司，在做事方法原则上，大公司与小公司差别很大。目前在国内互联网界比较有名的大公司，都组建了自己专业的“UED团队”或者“产品设计团队”来协助产品经理创新，典型如阿里巴巴、百度、腾讯三位巨头。观察这类较成熟大公司的产品线组织架构改变如下：

老板——战略层面的产品群商业规划。
产品经理——战术层面的各产品“信息架构”及“结构层交互设计”职能。
设计师——执行层面“框架层交互设计、界面设计、视觉设计”职能。

由此可见，“交互设计”在大公司可以是不同层面的职能，谁有能力都可以多做，产品经理与产品设计师争风吃醋大打出手多半也因为此。这里不细论“交互设计”职能的工作，个人理解交互设计只是加分题，无法改变产品本质。专业交互设计师的职责是让“交互”做的更好，这也是为什么在大公司才需要细分“交互”职能的原因。

经过岁月洗礼和人为淘汰，目前国内互联网产品经理的素质在逐步提高，其具体表现为有了几款不错的国货。但现实中百花齐放更典型的现象，“产品经理”博客里大谈产品设计、产品细节，而“交互设计师”博客里大量撰文讨论产品方向、商业模式，有时我确实很纠结这些家伙在做什么？以及他的职业规划是什么？或许是想证明自己既高瞻远瞩又事无巨细，无所不懂无所不通吧。

此话题写到最后，不妨悲哀和直接一点。我相信那些持“产品经理——博大精深无所不能至高无上”观点的同行们，并没有深刻理解互联网产品的可持续发展一定需要团队协作，产品经理负责产品的0到60分（有人用），而产品设计师负责接下来60到95分的提升（有人持续用）。

相关话题：产品经理源地址：http://blog.rexsong.com/?p=11193

谈一下互联网业务的超越

mileswen — 2009-12-08 20:55:20

在互联网行业做了几年了，做过搜索、邮箱这些基础互联网业务。感觉互联网行业的赛跑中，大部分还是先跑得还是抛在前面，后跑得还是跑在后面。也有个别的成功的赶超的例子，但是凤毛麟角。
很多赶超别人的市场经理或者BU负责人都会认为，如果要超越，一定需要公司投入大量的市场预算（或公司内的等价市场资源）。另外一些产品经理可能会把宝押在一到两个独特的功能上面，这背后可能是一些独特的技术在支撑。
这些因素确实很重要，不过我个人觉得，更根本的和重要的可能还是管理因素。
要是说推广资源，可能那个公司也比不了腾讯内部的推广资源。QQ这庞大用户群，每个月可以从上面挖掘的推广资源多的不得了。粗略估计一下，每个季度公司内部的这种内部推广资源的使用，可以达到4-5个亿左右。但是腾讯这些年做了这么多产品，被用户广泛接受的也只是一少部分。不能说他们成功那些产品都是公司给资源多的，不成功的就是公司给资源少的吧！因此说产品才是根本，没有好产品支撑是不行的。
那么靠一到两个功能可行吗？我觉得也不太靠铺。很多时候，你的竞争者的开发能力比你强很多，你好不容易想出那两个功能，开发了半年多，刚一上线，还没等你周知广大用户，竞争对手两个月之内给复制了。
其实上面这些问题，很多人可能都深有体会，也不用我多说了。那是不是我们就没有超越的机会了呢？这正是我今天想和大家分享的地方。
了解传统行业战略管理的人都知道，在传统行业的战略流派中，也有外因论和内因论的流派。当然也是由于特定的历史时期的一种产物。上世纪八十年代，刚刚改革开放，谁能生产电视机，谁就能挣钱，这个时候，速度是最重要的。但是进入九十年代，甚至新世纪，市场逐渐饱和，最后只能看谁的内力修炼的好，强调核心竞争力了。
互联网行业的核心竞争力是什么呢？按照我现在看到的这么多公司，我的总结就是：团队的执行力，是一个管理问题。刚才说到的竞争对手很快复制你的亮点。比如腾讯，现在网上很多人都在骂腾讯抄袭，其实他能在短时间内抄下来，而且还是批判的抄，这本身就是执行力。再比如刚才说的，你想到了一两个产品功能亮点，如果你能常年捕捉用户需求亮点，这也是执行力的体现。
那怎么能打造组织的执行力呢？这就涉及到很多管理问题，首先就是组织结构设计问题、人员配备问题、人员的培训问题等等。
组织结构设计一般是遵循 “a)技术工艺决定的职能———b)组织结构和岗位设置———c)人员配备———d)组织机器开动 ” 这样的一个过程。
没有从工艺流程中提炼出来的任务，你绝不可能涉及出一个好的岗位。没有好的岗位职责，就更不会有针对性的人员配备，进而培训和激励无从谈起。
具体到互联网行业，核心流程就是如下几方面：
1）用户研究：主要借助于市场调研、数据挖掘等方法，输出物是项目立项报告或可行性分析，指出产品的竞争力所在。
2）产品设计：产品的细节设计过程，页面布局和交互流程在此环节。输出物是产品需求文档。
3）项目开发：组织工程技术人员，将产品设计实现。
4）产品运营：和项目开发目标相同，共同实现产品竞争力。例如编辑工作、产品型BD工作。类似网页搜索这类产品，可能体现不明显。
5）市场推广：通过沟通手段，告知用户，告知的内容是品牌价值号召力。

以上这些职能，你单独说哪一块，找到优秀的人才，都不是难事。但是做为一个产品来说。需要将以上各个环节有机的协作起来，这就不那么简单了。
谈到协调，很多人可能会学过矩阵式组织结构，除了纵向的职能经理之外，还有横向的管理人员，有时候叫产品经理，也有叫项目经理。例如我知道的西捷硬盘的产品经理、精英主板的产品经经理，就是这样一种情况。据说精英主板的产品经理很多都在40岁左右，年轻时候也是一个个的研发工程师。也听说他们虽然都这么成熟了，也面对市场压力时候，还是要找人给他们培训培训市场推广。
在互联网行业，听说google也是要求产品经理的。不过年薪据说30万起。先不要说你能不能开的起这个价格，我觉得这种精通以上5个方面能力的人绝对是个稀有人才。具备这种能力了，也不是你30万可以留住的了，人家早去拉风头，去创业了。
根据我对国内两家做的比较成功的互联网公司的观察，他们采用了将传统行业产品经理的职能一分为二的办法，成功地解决了这个问题。即
产品经理（传统定义） = 产品经理 + 项目经理
项目经理负责项目开发环节，产品经理负责其余非技术环节。这样做有一个直接好处，就是可以让你成功的为这两个岗位配备合格的产品经理，配备合格的项目经理。
我了解到的一个腾讯的项目经理，从他大学毕业，然后在腾讯从事2-3年技术开发，就可以胜任项目经理。另外，如果一个毕业生，在公司内得到3-4年的产品设计方面的不断培训，也可以胜任产品经理的首要职能产品设计的工作。
也见到一些另外的公司，赋予产品经理负责全部职能的责任的情况。如果产品经理没有开发背景，管理的项目开发流程多半很混乱，就算勉强管理好了，也会耗费工作时间的绝大多数。我就见到过这样的产品，一周5个工作日，和工程师扯皮扯了4天半，到了周五下午好容易扯完了，竟然开始在网上看看新闻。原来长期扯皮，自己已经忘记了自己的一些本职工作，例如分析分析数据等等。这种例子可以举出很多，以后有机会再拿出来分析。
最后用我一个腾讯的朋友的例子来说说项目经理和产品经理的交接面问题。用户研究到产品设计环节的产出物 MRD市场需求文档或叫可行性分析，项目开发之后就是产品上线，这些大家都很清楚。产品设计环节到项目开发环节，那自然就是PRD产品需求文档了，很多人认为这再自然不过了。记得04年的时候，我一个腾讯的朋友刚从市场转产品工作，我就很羡慕的问他，你写那个PRD啥样啊？他马上就给我发来了一个word文档，我一看只有3页，当时很是失望。不过他紧接着说，我写这3页都是精华啊，我们的项目经理给我这个文档扩充到30页。然后工程师再依据这30页的东西进行开发。这个例子有点极端，但也强烈的说明了腾讯公司的项目经理担负的重要职责，他们不仅仅是个执行者，其实每一个人也是一个很有业务头脑的另一种意义的产品经理。我现在认为这些人应该是该公司的中流砥柱。他们不对那3页说明产品竞争力的地方负责，其余他们很多地方都要负责。这样做有很多的好处，他们有开发背景，有能力在不是很耗费精力的情况下，写出一个很完整的产品文档（不妨叫需求规格说明书）。另外，由于他们承担了这个规格说明书的完善工作，产品经理可以节省出很大时间，去专心研究用户需求是什么！！！只有充分的了解了用户需求，你才能做出好产品。
回到前面说的情况，两个人配合，才可能把那五个职能全部涵盖到，全部涵盖到了的时候，就可以保持
1）永远领先对手发现用户需求 —— 用户研究
2）永远做的比竞争对手更好的产品体验 ——产品设计
3）永远高质量比竞争对手快速的推出新产品 —— 项目开发
4）永远......
5) 永远先人一步的告知用户 ——市场推广

我们要是有一支创造5个永远的超级竞争力的团队，你还怕有什么不能超越的呢？

产品经理如何把产品做成功

修泽 — 2009-09-11 17:24:11

原文作者：修泽
原文链接：产品经理如何把产品做成功
译者：修泽

昨天说到了产品经理如何把产品做成功(上)：“做正确的事儿”。今天来谈谈产品做成功的下半部分“把事情做正确”。
当产品的方向制定之后，产品经理要考虑的首要问题就是如何把产品做正确？
这跟项目经理如何把项目做正确有异曲同工之妙，项目考虑的是如何把项目做正确，产品经理考虑的是如何把产品做正确。项目是产品中的一个环节。
把产品做正确主要包括如下几个要素：

一、产品目标

识别出主要的产品目标，并作为产品设计的核心产品标准在你做一个产品的时候，产品目标经常会是不唯一的，遇到这种情况，产品经理需要分清晰哪个为重哪个次之，定义出产品目标的优先级，产品目标的优先级是技术经理定义产品开发优先级的重要参考要素之一。
产品目标必须要让产品团队的人员知道，开发团队人员也必须知道自己做的这个产品将要达成什么样的目标，产品经理需要去宣介你的产品目标，让客户、公司领导、相关部门都知道你这个产品要完成的目标是什么。这个目标是产品提炼出来的精华。是统一各协作团队思想的重要组成部分。

二、产品计划

制定可行的产品计划做任何事之前，最好有一个计划；虽然大家常常会说“计划不如变化”，但是如何没有有一个计划，你会不清楚产品的各阶段工作是如何有序进行的，甚至你的团队成员都不知道下一步应该做什么。如果你在做事之前还没有列计划的习惯，那你决不是一位合格的产品经理人。在有些公司，产品经理是没有产品团队为其做支撑的，这时候需要产品经理自己给自己定义产品计划。但大多数正规公司，是有产品团队的。产品经理的计划是经过产品团队一起分析讨论，制定出产品大纲，再细化为各产品的阶段性计划，汇总给产品经理形成产品的计划。产品计划中的构建阶段、发布阶段计划由技术经理提供。

三、产品规范和流程

制定清晰的产品流程和规范当产品经理制定好产品计划后，产品团队成员如何去高效的执行？这就是产品经理接下来要考虑的问题了。往往有些产品经理会想出一个宏伟的产品目标，制定出产品计划；但是由于没有统一清晰的产品流程和规范，导致各团队成员做出来的需求规格不同、质量不一、要花大把的时间去核查去调整。所以说制定一个统一的产品流程和规范有助于提高产品工作的效率。
我先说说我们团队中的产品流程和规范体制是如何建立的，可能也会有不足的地方，我们也在不断的完善中。
a.建立统一的文档模板库，用统一的产品模板；规定了产品的流程图、线框图、功能描述、用例图的规范、保证格式和范围上的统一。
b.建立产品的作业指导书，对于产品中的各阶段工作都会有一个较为详尽的指导书，告诉产品人员每一步应该做什么工作，如何做。
c.四审核机制的建立在文档提交给产品经理审核之前，由各产品专员交叉审核交叉审核完成后，由产品组长审核产品组长审核后，再交由产品经理审核产品经理审核后，再上产品评审会大家不要常见得这个四审核机制有点长，但用时并不多，而且这部分工作如何做得仔细，会大大降低后期的产品修改的工作量。

四、建立高效的沟通机制

常常听到技术经理向产品经理抱怨：“你们产品团队的人员咋总是问我重复的问题呢？累死我了！！！汗！！！”，这是一种常见的情况，如何解决这一问题呢这就需要建立一个高效的沟通机制，我们团队的沟通机制是这样的，仅供大家参考。
产品细节问题，由模块化的产品专员与技术专员直接沟通，如果10分钟内无法达成一致，则交由产品经理和技术经理共同决策。
需要决策的事宜，由产品经理与技术经理直接沟通，且相关产品技术人员旁听。
如果产品经理与技术经理仍不能达成一致，则由产品经理决策，且责任由产品经理承担。

五、汇报评审机制

建立有效的汇报评审机制产品经理需要定期向领导汇报其所负责的产品当前的状况是什么？要让领导知道你在做什么？产品到了哪一个阶段？需要领导协调的资源是什么？
有些公司的汇报和评审机制是放在一起的，评审时，由产品经理向领导汇报产品工作。
但我建议的是，汇报和评审分开，为什么呢？
因为领导关心的问题往往与评审的主题是不相同的，且领导没有太多的时间去听产品的细节，他更关注的是产品的里程碑状况。而评审更多的是评审产品的细节，有时候也会谈到方向，但更多的是关注产品的本身。
我们的汇报评审机制如下：
汇报机制每周由产品经理向高一级领导单独汇报产品的当前状况，汇报的形式：周会、周报评审的机制在产品需求完成后，由产品经理发评审通知，主要参与人员：项目经理、技术经理、测试经理、QA、UED经理、及部分主要核心专家成员一起评审，并填写评审报告单。评审结果由CM入配置库。

六、跟踪机制

跟踪机制本来不想写跟踪机制的，但最近经常听到朋友说其下辖的产品专员总是忘记跟踪产品，导致产品经理直接去跟踪更细的细节，浪费大把的时间。
在这里我想说的是，不论是产品经理或是产品专员，任何一个做产品的人，都应该把跟踪视为自己的一个常态性工作，而不是由规范来圈定你去做这件事儿？跟踪是产品的本能性工作。如果你是一个合格的产品人，我相信这一点不用多说。当然，产品经理可以在制定产品计划时，把“跟踪到位”重点强调，并作为考核的一部分，应该会有些效果。
好了，今天先写到这儿，欢迎大家交流。

相关话题：产品经理源地址：http://www.yeeyan.com/articles/view/89367/58639

谁是合格的产品经理？

hozin — 2009-09-14 21:18:29

当提倡国货声中，广告上已有中国的“自造舶来品”，便是一个证据。
——鲁迅《伪自由书|从幽默到正经》

本文提到的产品经理，一般指网络产品经理。

产品经理是个算是舶来品，在传统的中国式经营中，有东家，有掌柜，有账房先生，有掌勺师傅，有跑堂的伙计，有学徒，没有“产品经理”；要给产品经理验明正身，就要从产品说起；产品就是菜式，菜单真的是由掌勺师傅发起？菜单一定要经过东家的确认？最近总是看到产品经理在抱怨工作氛围与合作环境，大多是“不被理解”或者“不能左右”，那么，是不是这期间真的产生了什么问题？我们尝试的去分析一个合格的产品经理所处的位置和境遇。

说文解字：从产品说起

随便搜索一下“什么是产品”都等得到一些冠冕堂皇的答案。在大规模协作的今天，不可能在自留地里生产食物，用自造的锅铲把它们弄熟；从产业的角度，产品是流程产物，也就是来自不同部门、不同职位、甚至不同公司的原材料，通过生产工艺加工出来的结果；对于万维网产品，则是一项彻底的工程活动。

产品本身的价值，是满足人们的需要，这个价值不是商业价值；产品要套现，就要变成商品，这个概念很重要；不是所有的产品都要变成商品，公益的、非盈利的、公共属性的产品随处可见。

从产品的特质分析中不难发现，产品经理貌似是不需要对商业负责的，他们只需要实现产品的价值——满足用户需求，就OK咯；这就好比掌勺师傅只需要炒出让食客满意的菜肴，而根本不必关心它们是否赚钱。

真实的情况是，产品经理往往因为产品销售的不利而背负巨大的压力，这是抱怨的原因之一。

产品经理的艰难定位

Product Manager产品经理，哈，Manage这个动词在英语里包含丰富的意义，看来这个舶来品还真不简单。

Manage不是Create

产品的创建不应该是产品经理的任务；那么我们是否肯定马花藤是QQ的产品经理？李宴宾是摆渡的产品经理？盯儡是网艺的产品经理？当然你这么理解也未尝不可。但是你要明确：麻晕不是掏宝的产品经理，张炒洋也不是馊壶的产品经理……决策产品是否创建，绝对不是一个产品经理能够决定的；炒菜的师傅很难决定菜单上有什么，除非他自己是东家。

Manage不是Marketing

产品的营销不应该是产品经理的任务；那么我们是否可以肯定产品经理不用对利润负责？产品经理每天要忙着处理大小订单？产品经理也要知道财务报表？可是，访问注册量指标能够仅仅依靠良好的用户体验去实现么？现在可不是那种“好酒不怕巷子深”的年代啦。

Manage不是Maintenance

生产流程不应该是产品经理的任务；那么是不是每个生产工艺都需要产品经理去Flow？半成品的质量把控是否也需要产品经理染指？工作进度也需要产品经理负责？可是，项目经理和QA会成了吃闲饭的岗位！

Manage不是Design

产品设计不应该是产品经理的任务；那么是不是每个产品经理都应该去画线框图？PD 文档真的是产品经理应有的交付物么？要不干脆就叫产品设计师吧；一个汽车设计师只要在纸上画出来原图，而那些其他细枝末节都交给CAD制图员去处理了，那么为什么网络产品经理还要自己画线框图呢？那么为什么产品经理往往要百般的讨好技术经理才能让产品付诸实施……

越分析越模糊，相信很多身为产品经理的人也在模糊；如果Manage代表了“处理，支配；管理，经营”的含义，那么产品经理就相当于CEO的角色了。

PM是个抢饭的角色

按照很多产品经理自己的观点，要胜任这个定义模糊的职位必须成为一个超人那样的SuperMan，例如我们随便搜索“合格的产品经理”这个关键词，得到如下的信息：

这位产品经理抢了项目经理的饭碗: 成为一个合格的产品经理，必须要重视三个方面的能力：. 1，文档的规范能力； 2，项目管理能力； 3，跨部门沟通协作能力
这位产品经理抢了UED的饭碗: 合格的产品经理应当具有撰写报告的能力，如：分析报告、用户调查、可行性报告等等
这位产品经理抢了需求工程师的饭碗: 一个合格的互联网产品经理在向技术部提交产品策划方案时，除了详尽的需求说明外，还必须提供清晰易懂的产品原型设计(Prototype Design)方案
这位产品经理抢了销售总监的饭碗: 一个产品经理如果只看到现在，只看到产品销量的增长，只去考虑如何把他的产品卖出去，那么，只能说这个产品经理还不是一个合格的产品经理。
这位产品经理抢了市场总监的饭碗: 合格的产品经理还需要考虑成本预算、销售量的监控、利润监控、价格体系的制定与维护等等东西，这都需要你有基本的财务能力，平时没事炒炒股票弄弄基金 ...
这位产品经理连SEM工程师的饭碗也要抢: 一个合格的产品经理应该是半个SEO专家
这位产品经理逐渐意识到成为超人有多难: 产品经理不是万能的，应该解放产品经理，现实的情况是产品经理要做很多事情，完全和我之前提到的“超级产品经理”的情况相反。
这位产品经理已经想明白了: 在产品管理中，产品经理是领头人，是协调员，是鼓动者，但他并不是老板。

可以看到，产品经理这个职业的现状和遇到的窘境。产品经理不得不模糊的从事者自己的工作，倘若清晰些，发现自己什么都要承受，堪其重负。莫不如干脆承认自己做的是一份清晰的职业，比如UED、交互设计、产品规划、网站设计、网站策划、项目经理、需求工程师、技术支持等等。珍爱青春，远离产品经理。

只有老板才是合格的产品经理

回到问题的中心：谁是合格的产品经理？答案很简单，给别人打工的产品经理永远都无法合格；只有那些能够掌握自己命运，真正达到可以“处理，支配；管理，经营”产品的境界，才算是合格的产品经理。

奇怪的逆推定：成为老板之后，他们可能还会去雇佣其他的产品经理去完善自己创立的产品，因此那些被雇佣的产品经理依然永远是“不合格的”，合格代表了产品经理的职业终结。

关注不断被“边缘化”的产品经理，关注这个舶来品角色，其是否水土不服，是否在挣扎，是否受到经济颓势影响最深的一群。

从轻量级产品设计到重量级产品经理的转化

wkcow — 2009-08-07 18:37:39

一直以来人们都对产品经理的职责分辨不清，或者说有所疑问，或者有所争议。其实这与公司对于产品经理的定位是有直接关系的。简单的说：

    1.公司给你这个产品经理的职责
    2.公司给你这个产品经理的权力
    3.公司给你这个产品经理的资源

    抛出掉上面的公司层面的定位，我们，作为产品经理，要清晰的明白自己的定位。大家都知道，产品经理可以基本分为两种类型：
    1.轻量级产品经理，轻量级的产品经理一般来说，都是产品规划者、设计者。出身技术的产品经理，一般情况下是向技术部门的老大汇报。出身品牌或者营销的产品经理，一般情况下是向销售部门的老大汇报。稍微说明下，大家如果在找工作的时候，如果发现招聘要求里面需要的是技术出身，那么多半是属于技术部门；如果需要的是营销经验，那么多半是属于销售部门。
    对于轻量级的产品经理，他的工作多是支持角色，即非主导角色。一般情况下，工作经验在1-5年以下的产品经理都是属于这类角色。把属于自己的角色及职责完成，超出预期的完成，就已经证明自己了。

    2.重量级产品经理，重量级的产品经理，都是产品的带头人、实际上就是该产品的总经理。有的时候，我们喜欢用乔布斯做产品经理的例子，呵呵，我承认他是产品经理，但他也是一般产品经理无法企及的产品总经理。作为产品的总负责，他们已经拥有了人事权、财政权。也就是说，这个产品的所有相关人员都是向其汇报，对其负责。这样的产品经理，是真正的cross team，就是跨团队工作的强者。
    对，他也许不是技术出身，但他了解技术的变现能力；
    对，他也许不是品牌出身，但他了解品牌的建造过程；
    对，他也许不是销售出身，但他能够卖出自己的产品；
    对于重量级的产品经理，他的工作是规划、计划，具体的执行都是他的团队成员去完成。他会提出产品要求，就如乔布斯提出要一台书一样的笔记本；他会提出营销方案，就如史玉柱的脑白金营销；

对于产品经理来说，他的工作历程，或者是工作方向其实就是从轻量级的设计经理，向重量级的产品经理迈进的过程。百度电子事业部的李明远是一个例子，或者说是百度对其能力的信任。

    最后，围绕着产品经理的一个有争议的地方，就是小公司要不要产品经理，其实我个人的认为是，百分之2000需要。
    1.虽然小公司的创始人就是产品的总经理，但他更多的是提需求，而不是去设计，去运维，去实现
    2.所以小公司需要设计的产品经理，运维的产品经理，实现的产品经理
    3.小公司养不了产品经理，大多数原因是定位问题，老板自己都是产品总经理了，再整一个过来，不打架，冲突才怪。如果你觉得自己是个销售人才，自己不是乔布斯那么能，索性放权，如果不放，就给予招聘的产品经理以清晰的定位，然后择人而用。

产品经理为官会更有利于产品

兰思 — 2009-08-01 11:52:05

如果是在国外，如果是在一个很重视产品或者规则很好的国内公司，产品经理的确可以不为官。但是现在国内这个情况却恰恰相反。产品设计师，不为官还说得过去，产品经理，却不能不为官。

这里没有冒犯思域的意思，但是兰思和思域的看法不但相反，而且相反的很远。

先看思域的四个理由：

首先：高职位很容易衍生高姿态

兰思个人认为高姿态完全不是高职位引发的问题，而是本身的心态就存在问题，只是高职位给了这样的人一个展示自己心态的空间罢了。

如果一个产品经理在很高的职位的情况下，还能积极听取别人的意见，并且能以低姿态和别人完成沟通，那么我相信他所能获得的尊敬会更大，办事会更容易。

如果一个产品经理在讨论产品的时候：“认为别人对产品的攻击是对自己的不尊重，开始人和人之间的讨论”那么这样的产品经理从专业上就不合格，完全达不到作为产品经理的素质，同时，这样的人即使在员工的身份的时候，别人对产品的批评他一样不能接受，而且会认为是会认为别人不认可他的能力，只是他由于职位的问题，没有胆量或者没有办法去不接受而已。

其次：官比老百姓更容易成为众矢之的

没错，的确是官比老百姓更容易成为众矢之的，但是产品经理是负责整个产品的生命周期的人，他理应当承担产品的被寄予的期望和做好产品的责任。如果连这个责任都没有的话，那么还是产品经理或者是产品设计师吗？

的确，我承认国内的大部分产品设计师都不背负相关的责任，但是我却认为这个是不合适的做法，在中国这样一个职业道德和尽职工作不健全的环境下，并且大部分人的职业素养都不足的情况下，作为产品的父母的产品经理的确是应该背负更多的责任。否则我们很难想象会出现什么样的产品。

同时，压力是产品动力的源泉，人在压力下往往会存在两个极端的状态，一个是极度的冷静，一个是极度的慌乱，而往往是在压力下极度冷静的人才是最后能成功的人，那种在压力下极度慌乱的，即使在没有压力的情况下，也仍然是很难有冷静的判断。

再次：如果产品经理是官，很难避开公司领导层之间直接的利益斗争

权利和利益的争斗，在任何一家公司中都存在。但是如果这个争斗影响到了产品，那对于公司的的影响，可能是非常深远的。

想远离这个争斗，往往是需要职位作为保证的。越是职位高的人，保持公平，公正就越有保证；如果是产品经理作为一个员工，的确可能很少被卷入到分争中去，但是在公司的分争中，利益的任何一方都不可能以损失销售的方式来达到自己的利益（极端的放弃销售的情况也见过），这样对大家都没有好处，但是产品对于调节双方的资源等环节却起到了至关重要的作用，于是产品或者是技术的领导必然被卷入到这个分争中去；如果是幸运一些的，领导本身就非常公正并且本身就非常强势的还好，如果是领导是个墙头草或者是过分维持和谐的，产品就惨了，产品经理想维持公正，最优的心态对待产品，那么他就很有可能被干掉。（魏征，包拯能长期保持公正并且不被干掉，就是因为他们位高爵显）

最后：如果产品经理是官，那么在公司行政管理方面会耗去他大量的精力。

的确，作为一个员工，的确是不需要在行政管理方面好去大量的精力，但是产品经理很大的职责是是协调和保证产品设计，研发，运行等顺利进行，这块无论是在无授权的沟通还是在授权的沟通下，都不是一个很好的解决方法，所以很多事情必然卡在沟通的环节。而作为拥有职权的一方，沟通环节会有很大的优势。

再者，虽然是节省了行政管理的精力，但是如果产品经理在产品决策上的话语权就少很多，甚至要话很多向上沟通的精力。任何一个设计都要向组长，小领导，大领导……等等的人员申请，例如兰思为了申请去掉整站非常重的背景色，光收集理论资料，实例，数据等证明材料就花了一个多月的时间，而且要沟通说服N 个高层。至少这个时间比行政管理的时间，一点不少。

同时，在国内，没有职位就代表着没有话语权，很少有公司能让最专业人去决定专业的事情，当产品经理没有职权的时候，就代表着产品要由一些不专业的人来作决策，作为产品父母的产品经理如果不能替产品作决策，那么让产品的****为产品作决策的错误风险又有多大呢。

作为我们的同行，白鸦应该算是个比较明显的例子，除了支付宝对用户体验的重视，白鸦在支付宝的职位也是他的思想能顺利的执行的一个保证，如果白鸦在支付宝是一个普通的员工，我相信通过他的努力，通过培训，沟通等等手段，也可以让用户体验的思想在支付宝更深入，但是这其中沟通的时间，以及别人是否接受风险。（我不信支付宝中就没有一个不靠谱的人）将花去他更多的时间。

的确我也承认，高职位对产品经理来说，会带来一些精力上的牵扯，但是同时也能带来一些好处：

高职位给产品经理带来更大的独立性：

思域说，产品经理在公司里面可以是独立的，这一点我是同意的；但是和我国为什么设立人代会直属的最高法院，而不是把法院放在国务院的一个部委下面一样，法律裁判部门放在任何一个部门下面都无法保证法律裁判的独立性，公正性也就很难保证。

同样的道理，如果产品经理没有很高的职权，如何保证产品经理在产品策略上的独立性呢？而没有这样的独立性，即使产品经理想，但是他任何保证自己在各个部门沟通，取舍间的独立性呢!

高职位给产品经理带来更大的沟通空间：

这里不是说产品经理需要头衔为自己开道，对于一个员工来说，即使是想，也并不一定能收集到很多很多的意见，甚至部分产品经理不得不动用女性产品经理、请客吃饭……手段来达到这个目的，但是这并不是一个正常的情况，而且也不是在所有的场合都通用。别人的时间，精力，兴趣……等等问题都增加了产品经理收集意见的难度。

但是对于一个职位比较高，又乐于纳谏的人来说，这样的沟通的难度等因素都会小得多，解决沟通中，下级对上级没“胆”的问题，怎么说也比解决评级之间没“肺”，和上级对下级没“心”容易得多。

高职位给产品经理更强的驱动力:

一个公司要发展，这个向前的驱动力量，而公司的管理系统是掌舵的职责，如果再让他们承担这个工作，很可能导致他们无法全力的控制方向性问题。

现在这个驱动力往往是在各个部门中，但是却要向产品上集中（现在很多公司是在市场上集中，但是这个很大程度上是在该变速系统，而不是驱动系统）。而如果产品经理只是一个员工的话，那么这个驱动力量要由其传达到方向系统中，要经过过多的步骤，减弱很多，甚至可能导致能驱动公司前进的设计在传递的途中被湮没掉。

高职位给产品经理更多的信息：

信息是判断的一个基础，产品经理要想在产品设计中，达到良好的判断，那么必然要收集大量的信息。

国内大部分公司的信息流都是各个部门向上方反馈各类信息，而向在没有制度的情况下，平级和下级是得不到这样的信息的；而这些信息经过相应层面的过滤或处理以后，也会视相应需要部门的情况分发给相应的部门或人员。

那么产品经理如果是在员工层的话，就算是他努力的想获得信息，所能获得的信息量也少的可怜。例如是公司在考虑战略上的调整的信息，如果产品经理在高层，很可能在第一时间获得这个信息，已经可以作产品调整的准备了，但是产品经理是个员工的话，那么将在确定了这个事实以后才能获得这样的信息，那产品的调整就手忙脚乱了。

PS1：以上说的情况是在产品经理有相应的能力和合格的性格素质的情况下，并且是【产品经理】，不是产品设计师。

PS2：产品经理即使为官了，也要以设计师的心态去处理问题，官只是为产品经理提供空间、独立性和保证。

产品经理应该是一个翻译

nings — 2009-07-04 15:21:21

我昨天去饭店吃饭，前台给了两张假发票。基于我对发票鉴别的经验，一眼就看了出来。我说，要么你给我换真发票，要么不要票了你给我免掉税钱。前台一口坚持这就是真票，对我的两条建议予以拒绝。甚至在后来，我在税务局网站上进行真伪查询，已经证明是假发票的时候，打电话过去她还反反复复说“就是真的，不可能”。我不差这个发票，也不差这个税钱，但毫无疑问，我不会再踏足这个饭店。如果这位前台经理算是产品经理的一种，这是最差劲的那种。

3月27日我收到Datou《互联网产品经理进阶之路》这本书，分别用针式和激光打印机打了两份，放在单位和家里，断断续续的看了两遍。其中学习了不少东西，对很多观点也有强烈共鸣。抛开这本书不谈，就我接触的那些不够好的产品经理来说，他们最大的问题是懒惰。只说面向客户一方面，总是遇见把自己当做接线员的产品经理，他们把客户的反馈简单归结为两种：遇到了求助就念念产品说明书；遇到了分歧，一刀切的糊弄而过。这样的客户经理，归根结底，是个懒人。他们不是不知道应该怎么做，不是不知道怎么做可以做好，但是他们为了自身的清净、省事，因为老板轻易看不见——他们不介意搞糟那些面向客户的问题。如Datou说，产品经理应该是一个翻译。然而一名翻译的困境在于，他的老板并不能立即知道自己的翻译是否翻译详尽到位了；翻译自身的操心与不操心，难以量化，难以看到立即的实际效果，这就造成了大量的懒翻译，不把自己当“人”，把自己当做Google Translate。

当我今天回到电子版，我看到这本书的标题变为：要有光。下面是一些深有体会的话：

如果把用户、公司老板、研发人员当作三个来自不同星球的人，产品经理就是翻译。
产品经理的二八原则：20%的优秀产品经理完成了80%的最优价值工作，他们开天辟地；剩下20%的打杂工作则由其余80%的产品经理（或者产品助理）完成，他们修剪草坪。
西方有句谚语，魔鬼在细节中（The devil is in the details），什么是魔鬼，魔鬼就是让人摔倒的陷阱，当我们不了解足够多的细节的时候，就等于迈入了雷区。
作为一名互联网产品经理，请时刻提醒自己，不要重新发明轮子，要么第一个发明轮子，要么找到想要的轮子拿过来就好。
“想”是不够的，一定要动手去做，产品都是在做的过程中逐步被完善的，在能开始测试的时候就尽快开始测试。
消灭拖延提升效率的方法，就是把任务分解为连续的在能力范围之内的小任务。
用户体验影响产品口碑，口碑影响产品成败，产品成败影响产品经理的利益，这就是为什么用户体验高于一切。
用户对产品的忠诚度与产品的更新频率有关。管理用户期望至关重要。
先要做到人有我精，专注于核心创意并通过硬指标说服专家。

相关话题：产品经理源地址：http://nings.cn/2009/06/30/hurricane.html

如果你不是产品经理

wkcow — 2009-07-04 15:28:32

     当你是产品经理的时候，当你负责一个产品的时候，当你可以判决一个产品的时候，你有没有想过：
        a.如果你不是产品经理？你会怎样?
        b.如果你无法判决一个产品？你会怎样？
        c.如果你不需要对一个产品负责？你会怎样？

      1.如果你不是产品经理，那么你会在其他领域成功么，如设计、如管理、如编程等等？人都都说产品经理，都是万能胶，那么你可以在别的领域有所成就么？

      2.如果你不把自己当做产品的生杀予夺的掌握人，你会聆听别人的看法么，看着别人怎么做么？你也许就知道，多倾听别人的建议是多么的重要。

      3.如果你不是把自己当做这个产品的负责人的时候，你才会发觉，某个产品，因为有自己的决断才走到今天；你才会发觉，某个产品，因为没有按照自己的判断，才走到今天。这是时候，你是否会淡然的说那么一句，“原来这个世界没有什么人是不可替代的”

       4.如果你不是产品经理，你会寻找比你厉害的人来做这个产品的负责人么？这些比你厉害的人会信服你么？

       5.如果你不是把自己当做一个产品经理的心态，而是让你的工作不断地为产品的各个部门服务，那么你会为此开心么？

       6.就算你被任命为产品的产品经理，可是你能够掌握这个产品么？你了解产品的方向、细节、数据、UI等等么？

       7.就算你没有被任命为产品的产品经理，你就不能掌握这个产品么？掌握一个产品有两方面，一种是产品的方向，另外一种则是产品的发展计划并且实施出来。

       8.对于产品来说，希望大家都不要太在意职位上的划分，比如你是产品经理，我是设计师；或者你是项目经理，我是QA；或者你是美工、我是前段程序员。重要的是，大家一起把产品做成，而想把产品做成，大家需要一个Leader罢了。你对于这个产品的贡献足够大的时候，那么你已经是这个产品的驱动者了。而不是那些给你命令，或者给你想法的人。

产品经理和项目经理的区别

吕维 — 2009-06-23 00:55:46

产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润的。

项目经理——靠做。项目经理是把事情做正确，把事情作得完美，在时间，成本和资源约束的条件下完成目标。

从管理的角度讲,项目经理是纵向的,而产品经理是横向的。

例如我们姑且理解项目经理是一个开发部门的项目经理,那么他一定是对某个产品进行开发的管理,负责开发的进度,开发过程中的协调,供应链等有关开发方面的问题,他最大的目标是时间第一,立项目标达成第一.并不会很尊重产品本身的市场需求以及业务逻辑的问题.

在一个公司中类似这样纵向管理的部门都是一个个职能部门,例如市场部,主要负责推广,销售部主要负责销售等,而产品经理是横向管理的,也就是说他将负责某个产品或者某个产品线从商业计划\市场竞争\开发需求\推广方案\渠道策略\物流等各个方面.当然产品经理不一定是决策人,每个公司对产品经理的权限限制也不同,但是产品经理一个产品线从头到尾的重要参与人.想做好产品经理需要很多方面的才华和技能,他也是一个公司中最适合培养复合型人才潜力的职位。

一个产品经理可能没有权利,但是一个产品经理要善于运用同事关系,客户关系去协调去促进事情的发展,一个项目是属于项目经理开发的,他有开发目标达成的责任.而这个项目也是属于产品经理的,他有对商业计划负责的责任.因此作为产品经理就意味着的和本产品有关的事,不论是开发\生产\推广\销售 \成本\物流\渠道都是你的问题!

如果希望做一个复合人才就选择产品经理,如果希望做一个专注人才就选择项目经理。

项目经理与产品经理另一个重要区别是授权的范围不同：

项目经理一般是被授权的合同履约的负责人：

项目合同是规定承、发包双方责、权、利具有法律约束力的契约文件，是处理双方关系的主要依据，也是市场经济条件下规范双方行为的准则。

项目经理是公司在合同项目上的全权委托代理人，代表公司处理执行合同中的一切重大事宜，包括合同的实施、变更调整、违约处罚等，对执行合同负主要责任。
当然，根据企业的不同，老板能否给予项目经理相应的授权是另一回事。

产品经理的授权是保证流通链的畅通：

产品经理保证其所负责的产品，从上游创意、研发开始，至采购、生产，到下游渠道、通路，直至终端用户的整个流通链的畅通，因此要求产品经理既要有产品知识，也要有市场意识，还要具备协调能力，例如：财务、售后、物流……

但是，产品经理并无对外签订合同的授权。