存档

‘产品设计:0000 概述与杂谈’ 分类的存档

产品设计体会(0013)产品经理应该是管理者么

2009年12月6日

7月29号,思域写过一篇《产品经理应该拒绝为官!》,两天后,兰思又写了一篇针锋相对的《产品经理为官会更有利于产品》。我常说:看到一种观点,就应该本能的寻找与之相反的观点,继而从观点的对比中找出现象背后的本质,做到正反合。所以,有了这篇和稀泥式的文章,说下自己的看法。

首先通过一系列对比辨析一下“管理”与“领导”。

  • 管理更像科学,领导更像艺术;
  • 管理靠的是权力,领导靠的是魅力;
  • 管理者需要职位,领导者需要理想;
  • 管理者强调稳定,领导者喜欢冒险;
  • 管理者强调效率,领导者强调结果;
  • 管理者依法治人,领导者以德服人;
  • 管理的对象是行为,领导的对象是思维;
  • 管理是正确的做事,领导是做正确的事;
  • 管理是一步一个脚印,领导是不走寻常路;
  • 管理者注重短期目标,领导者注重长期发展;
  • 领导者是企业家和创业者,管理者是职业经理人;
  • 管理是汽车的制动系统,领导是汽车的驱动系统;
  • 管理是告诉团队怎么做,领导是告诉团队为什么做;
  • 管理让团队能完成这些事,领导让团队喜欢做这些事;
  • 管理者要求员工顺从标准,领导者鼓励员工进行改革;
  • 管理对人的影响由外而内,领导给人的力量由内而外;
  • 领导像狩猎,是西方的游牧文明,管理像驯养,是东方的农耕文明;
  • 伟大的领导者可以没有管理才能,优秀的管理者不能没有领导才能;
  • ……

从对比里可以看出,产品经理必须是一个好的领导者,但通常在大多数公司里,产品经理并没有行政上的管理职位,所以被称为“无授权领导”。而工作职责使得产品经理必须要做很多的管理工作,那么,为什么不给我们一个管理职位呢?或者说,本节的标题更准确的说是——产品经理应该拥有管理职位么?

这种问题一上来就可以定调子,如果产品经理是管理职位,必然既有优势、也有劣势,否则这就不成为一个问题了,我们不妨从优劣势的对比中寻找现象背后的本质。

管理岗位拥有话语权,不知你是否同意,产品经理最大的激励是成就感,国内很多公司的现状是,没有职权就没有话语权,当产品经理不是管理者的时候,很可能就成了一个实现别人观点的执行者,更悲惨的,作为外行的老板决策,下面执行,出现“外行领导内行”的局面,这样怎么会有成就感?解决之道,我们可以培养“专业的人做专业的事”的价值观,让产品经理在他熟悉的业务领域拥有话语权。

管理岗位利于获取信息,就现实而言,公司里很多重要信息都是自上而下传递,如果能参与管理会议,就可以掌握先机。产品经理需要做很多决策,而决策失误的一个重大原因就是信息不充分,如果不是管理者,就算你的老板能传达,也有时间延迟信息失真。这个问题,当然也有很多办法解决,比如部分重要信息通过用户调研、数据分析自下而上传递的,又如让重要的非管理人员参与管理会议的业务讨论部分。

管理岗位利于争取资源,夸团队沟通是一件很麻烦的事情,如果你是一个有权力的管理者,做事也挺靠谱,那么专制、独裁是最高效的手段。在争取资源的时候,至少有保底的招数——行政命令,特别是对于国情现状,“官本位”的思想多少存在于每个人的潜意识里,君不见很多团队里,其实那个大老板就是一个产品经理。从这点里,我们发现,如果产品经理有临时的资源支配权,也可以解决部分问题。

管理岗位有很多行政工作,这些事的效率往往并不是那么高,会占据产品经理大量的时间。而产品经理的所有工作,最能产生效益的都是与产品直接有关的,无论在产品生命周期的哪个阶段,跨部门沟通、做规划、跟进项目、接触用户、分析数据等等都已经忙不过来,如果再来一块“官场”有关的事务,那必定不堪重负。所以,我们应该让产品经理“对事负责”,对业务负责,而其他的一些事务性工作,不妨留给其他管理岗位的同学。

管理岗位会让人脱离群众,一方面是因为自己心态,认为自己高人一等就会有意无意的忽视别人的意见,如果把各种评审会上的正常争论认为是对自己权威的挑战,对产品更是致命的,久而久之大家甚至都不愿意和你讨论。这个问题也好办,我们学学真正的高手就可以了,他们往往都是很谦虚低调的。另一方面就更致命了,官与民之间总是有隔阂,最明显的现象,我待过的团队,一定有一个全团队的旺旺群,也一定有一个全团队除了主管之外所有人的旺旺群。很多时候大家对一个管理者的观点有异议,也没法像对普通同事一样直接提出,总会在心中先掂量几次,很多可以帮助产品提升的机会就在这些掂量中白白溜走。从这点上看,产品经理不在管理岗位上会有利于工作。

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

这,似乎是一条很好的路。

VN:F [1.2.0_562]
Rating: 4.1/5 (11 votes cast)

产品设计体会(0012)非典型产品经理

2009年10月11日

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

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

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

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

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

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

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

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

VN:F [1.2.0_562]
Rating: 4.3/5 (6 votes cast)

产品设计体会(0011)我想做产品经理,如何入行

2009年8月16日

这篇是写给0岁及以下的产品经理看的

高手阅读时请用批判的眼光帮我指出错误和不足,:)

  • 全文三步走
    • 确认自己真的想做产品
    • 明确自己现在的位置
    • 几个可行的切入点

=========================  正文开始的分割线  =========================

经常被问这样的问题:

“我快毕业了,对产品经理这个职位特别感兴趣啊,怎么入门?”

“产品经理都是招有几年经验的,我原来做技术,要转行怎么做?”

……

经常看到这样的帖子:

《研发转产品,真的很痛苦!》

《我是软件产品项目经理,如何成功转型做产品经理?》

……

这次来谈谈自己的看法,分几步吧。


第一步,确认自己真的想做产品

无色占位专用

很关键,想清楚自己为什么想做产品,主要证明给自己看,下面都以互联网、软件产品举例,因为是做这个的,熟悉一些。

做产品的大前提是要喜欢产品,不然将来你痛苦,团队痛苦,用户也痛苦,是不是?网络上那么多好玩的应用,是很有意思,通常觉得自己想做产品的同学都会去尝试、注册各种各样的产品,去用,去玩,去想(什么,你不是这样?那真要好好想一下大前提了),我们需要明确的一点是:你喜欢产品的原因,到底是喜欢做用户,还是喜欢做产品经理?

当我们对一个产品感兴趣的时候,回想一下脑中萦绕的问题是用户的角度,还是产品经理的角度,就可以基本确定上面的问题了。用户的角度是怎么用这个产品才能产生更大的效用,而产品经理的角度则是在背后,怎么设计这个产品才能更好的平衡用户目标与商业目标

举个例子,SNS里的抢车位游戏,很多人喜欢,用户角度的问题就是,我应该怎么样才能赚更多的钱?怎么最快的买到想要的车?怎么玩最爽……而产品经理角度的问题则是,为什么每个人是4个车位?如果车位多了会怎么样?不同档次的车为什么停车费是一样的?如果高档车停车费高了,会有什么优缺点?这些设计有人做过分析,都是和产品的商业目标有关的,举例说,车位多了,停车费高了,对好友数量的需求就会降低,意味着站内用户互动的减少,与商业目标矛盾,而反过来,如果粗暴的试图增加互动,用户又会不爽,也不行。

如果到这里,你觉得自己真的更多站在产品经理的角度想问题,一想到这些问题就热血沸腾、欲罢不能,那很好,我们接着往下看,不妨先做个测试,看看这个帖子《产品经理的56个特征》,特别是我标粗,加了注释的句子,自己有这些职业病的症状么?如果能看到很多让你莞尔的句子,那么我很期待你的加入,整个行业需要你!举几个很经典的症状吧。

  • 你很想知道iPhone的产品经理是怎么给iPhone的功能排优先级的;很想知道常用的互联网应用里每个新功能都花费了多少工程师资源;很喜欢猜测手边的任何产品即将出现的3个升级是什么。比如不是很好用的msn,你很想要“最近联系人”这个功能,然后就会想可以通过什么方法来验证这个想法是否靠谱?用户研究?选什么样的人群?问什么问题?
  • 你对描述事物背后逻辑的东东很感兴趣。比如看到一些影视节目,电视购物啦、快女啦,你的欣赏角度总是与众不同的,你会看到一个情节,然后大叫:“嗨,这个环节设置的不错,文案设计的很到位!真想和他们的策划聊聊”。
  • 你的婚礼上会有一个PPT演示。也许,之前还有一张mindmap、一个project文档,一个feature list、还有……婚礼完了,会想把这些文档打个包,起名叫standard_wedding_docu_template_toolkit_by_yourname.beta1.0(额的神,千万别让你老婆知道你还打算升级版本号……),放到自己的blog上让别人下载。
  • 你总是问“为什么?”比如接到一个任务,你不会马上考虑怎么做,而是首先想问:“为什么要做?能不能不做?为什么要我做?为什么现在就要做?”很不让老板省心,是吧?通常这类问题,我们大多数在心里问问自己就好了,实在没想通的,也请问的委婉一点,呵呵,进入下一个话题。

无色占位专用

第二步,明确自己现在的位置。

无色占位专用

充分利用已有的知识结构、资源,找到一条最近的入行之路。

先简单说说应届生吧,机会不可谓少,很多公司在校园招聘的时候言明要产品经理,但其实刚毕业的同学只能先跟着学学,因为学校里根本没有很对口的专业么,也许把类似的职位叫做“产品助理”更准确,我自己就是应届生直接入行的,不过开始的职位是“需求分析师”,比产品经理更偏技术一些,技术可以速成,但是商业感觉没个三五年是磨不出来的。

这类职位应聘主要看面试,要是我来面的话,最在乎的是这个人是否够机灵、好学,思维逻辑是否清晰,沟通表达是否顺畅,其他的都次要一些,比如对行业的熟悉,既然是招应届生,这块不会很看重,关键是潜力而不是实力,如果有类似助理职位的实习经历,当然更好,小结一下,这其实算一个非技术的职位,相应的经验到处都是,就不赘述了。

我发现确实有不少,而且越来越多的同学在学校里对这行就已经相当有感觉了,加之半年到一年的实习,刚毕业就能独当一面的也有,但还是太少,不具普遍性。

然后,谈谈工作了几年的人,都可以算是转行的吧,做产品的有个特点,那就是从做啥的转过来的都有,身边就很乱:技术人员,比如开发、测试、架构;商业人员(泛化为非技术人员),比如市场、运营。这些信息至少能给人信心,不管现在做什么的都可能转化做产品,对比一下,做产品几年以后,正常人类是不可能再去做技术的。我想这和产品经理需要照顾产品的各个方面有关,所以一个产品团队的构成,我们也希望有各种背景的产品人员,可以让群体在考虑问题的时候更加全面。

无色占位专用

第三步,几个可行的切入点。

无色占位专用

确定自己想做,知道自己的位置以后,就剩下怎么去的问题了。也许你要失望,因为真的没有银弹!

在想转的时候,我的建议是先在本职工作上找到与产品有关的事情做一些尝试,并且考虑先从产品经理周边的职位做起

比如你是做开发的,那就经常要参与需求评审,不妨比别人多用点功,每次都预先了解需求,多多思考,然后在评审会上对需求提出自己合理的建议,时间长了大家都会觉得你很有想法,做产品也许不错。关于职位,可以从“需求分析师”切入,说白了有些像系统分析的工作,比如业务逻辑、流程图这种,都是已经很熟悉,整天看的,慢慢培养商业的感觉,重点体会商业上的某个需求,是怎么转换成产品需求的。

又如做运营的同学,有时候会要专门做一些活动的页面,通常是把需求提给用户体验部门的同学,这样的事情其实就是在做一个小产品了,你可以改变原来用word随便写几句要求,甚至口述沟通的方式,而是把这个活动当作一个产品做,自己练习写一下BRDPRD,虽然这类文档可能对一个小活动没啥必要,但这个过程帮助自己在以后碰到较大产品的时候,心里有点底。所以原来偏商业的同学,可以先做“运营专员”,对已有的产品做一些推广策划类的工作,增强自己对产品的理解,做一段时间,相信就能提出自己的对产品的想法了。

而项目经理也比较好切入,我们这里有很多项目经理直接过来做的,我经历过的团队,产品经理也是要带项目的,所以找个项目经理来也算先得个便宜,不过也正如《产品经理和项目经理的区别》里说的,有其特定的优势和弱点。

最最不济,你做过上面的这些事情以后,至少面试的时候可以多点谈资。还有一个很简单的办法——研究招聘广告,我一直觉得把这事儿做成一份漂亮的调研报告去应聘产品经理是个很靠谱的事,原来在这里也说过,可惜还没见过有人这么做。

这次只说到如何入行,下次不妨再说说入行之后的前几步,应该怎么走。

VN:F [1.2.0_562]
Rating: 4.3/5 (18 votes cast)

产品设计体会(0010)我们到底是不是产品经理:给互联网、软件业者

2009年6月18日

这是一次中篇的尝试,先放出1.0版,总觉得干巴巴,希望能收集到多多的意见和建议,一定会改写出2.0版,周末团队去武夷山Outing了,回来再看,:)

将近4000字,有必要给个摘要,本文已用于某机构内部发行的刊物,有媒体对本文感兴趣也可联系我:

本文分析了互联网、软件的产品经理与传统行业的产品经理有什么异同。

文章从“产品经理”一词的来源说起,之后转到互联网、软件行业巨头的“产品经理”招聘广告,从中发现了这个职位的内涵变化。那么,新兴行业的产品经理在概念 上究竟有什么发展?为什么会有这些发展?结果导致产品经理的职责、技能要求有哪些不同?文章的后半部分,分析并提出了造成差异的5大因素:

第一, 市场阶段不同,成熟市场与新兴市场。

第二, 产品形态不同,实物与虚拟物品。

第三, 生命周期不同,几年与几个月。

第四, 盈利模式不同,卖产品赚钱与多元盈利。

第五, 用户心态不同,花钱买与免费用。

注:本文把互联网、软件的产品经理放在一起讲,是因为现在的互联网产品越来越复杂,越来越像软件,而软件产品也越来越多的基于网页浏览器,越来越像互联网,相信不久的将来,这两个概念再也无需区分。

========================= 正文开始 ==========================


产品经理的概念最初是由美国的宝洁公司于1927年提出(另有说1931年,差不多就是二十世纪二三十年代)。当时宝洁推出一种佳美牌(camay)香皂,但销售业绩较差。一名叫麦古利的年轻人在一次会议上提出:如果公司的销售经理把精力同时集中于camay香皂和lvory(宝洁的一种老牌香皂)的话,那么camay的 潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持,之后,每一个宝洁品牌都当做一个单独的事业在经营,有其专门的产品人员、销售人员支持,与 其它品牌同时竞争。同时,他的成功表现使宝洁认识到产品管理的巨大作用,之后,宝洁便以“产品管理体系”重组公司体系。这种管理形式为宝洁赢得了巨大的成 功,也导致后来大部分消费性商品业者纷纷沿用和抄袭。

阅读全文…

VN:F [1.2.0_562]
Rating: 4.5/5 (35 votes cast)

产品设计体会(0009)零零散散之四

2009年1月27日

Ø  职业病一则:当别人要我做某件事情的时候,我总不喜欢直接接受别人的解决方案,希望问问为什么要做这件事?有没有可能不做?确定要做了以后,还要想是不是有更好的做法?更合适去做的人?做完了,再想以后怎么让提问的人自己能够解决从而获得解放……

Ø  产品经理是一个练内功的好职位,内力强大以后,可以驱动招式,转行去做什么都能很快上手,所以我想再做几年看看,对于用户体验,仍然当作兴趣爱好。在我还有很多想法的时候,坚定的走专业路线,以免被一些不熟悉的工作分散精力。

Ø  通过线上运营提高活跃度的悖论:提升活跃度的空间在于把不活跃的用户变成活跃的,而能看到运营活动的多数是已经活跃的,经费都花在了最活跃的那部分人身上,显然违背本意,一定要注意这个问题。

Ø  模板的作用有三:让经常看同类文档的人提高效率;让写文档的新人可以尽快上手,写出团队可用的东东;让写作者不会漏考虑某些内容。各种结构化的方法论,作用也大致如是。

Ø  保持项目经理对项目团队的威信至关重要,无法做出的决策PM可以单独找老板沟通,然后再下达,避免和团队成员一起去找老板的情况发生,此外,技术问题不要与开发争论,而应该去充分获得项目内开发经理的支持。

Ø  亮点应用:“谷歌流感趋势”可以比美国疾病控制与预防中心至少提早一周,觉察出该地区是否有流感暴发。数据的价值真的很高,只是很多都挖不出来。

Ø  忽悠的前提:信息不对称,懂得比对方多,有大局观,所以要求很高。

Ø  内部(偏技术)的大改动往往是外部(偏商业)的小改动,反之亦然,所以去找改动小,收效大的点!

Ø  项目开始之前,PM做两件虚事,邀请项目成员所在部门的大老板组成督导组,不只为了督导,更重要的是让成员们知道他们做的事情有重要人物看到;申请项目经费,或者相关资源。项目开始以后,PM的事情很简单,帮大家买夜宵……

VN:F [1.2.0_562]
Rating: 4.2/5 (16 votes cast)