产品驱动力 - UCD大社区

做互联网的基因

千鸟 — 2011-01-15 16:13:14

观察到越来越多的人给自己打上了“互联网产品”标签，好似一夜之间冒出来了这么多搞产品的人。尤其那些“SEO,UE,UI,UCD”从业人士，都纷纷改头换面，以正其名。无论其是否名副其实，都说明了各公司已经在重视产品，重视创新。

“对于互联网产品来说，越大众化的产品，越没有设计模式上的难度。”最近领悟到的观点，私下与多位同行交流，基本赞同。其实就是个简单的逻辑推理，产品越大众化，代表用户群越广，而需要覆盖的用户群体就越多，意味着我们的设计模式只能“降级”处理。否则，不可能做到同一个产品既能让大牛大爷大师们羽扇纶巾，又能让阿猫阿狗路人甲乙丙丁趋之若鹜。

我定义的“大众化”，就是咱老百姓吃喝玩乐衣食住行，就是“战略家、投资人”们认可有着高成长空间的领域，目前互联网上绝大多数网站模式也基于此。相反，“越专业化的产品，在设计上则越有难度。”因为面向的用户群窄，需求更聚焦、更专业和非典型，因此才能更考验产品创新的功力。

或者更明确点说，我认为“大众化”需求对“产品”本身的创新要求不会太高，只需要完善一些具体指标即可。因此，产品团队的重要性，会受“产品”本身所在行业或领域的影响。而现实情况可能更悲惨一些，“产品”这个职能，在不同类型的公司里，甚至在同类型但掌控不同资源的公司里，往往扮演着不同的角色。根据我们对互联网产品三要素“商业、技术、设计”的理解，我认为做互联网产品的公司也有相对应的三种类型：研发为核心、产品为核心、运营为核心。

这几天一打算落草“团购”的兄弟找我聊了些想法，再加上公司的事情，让我对“核心竞争力”这个词有了更清晰的理解。今年8月份在产品为王最后有段在设计角度对“团购”的观点：

比如最近很火的“团购”，我理解是电子商务的模式之一，这门生意我觉得关键在运营能力的渠道上吧？足够吸引用户的商品和价格才是王道。设计此类型产品的门槛很低，在“产品”角度一点意思都没有。

团购对我来说一点吸引力都没有，我网购的典型行为是买稀奇古怪的非主流东西，所以我不是典型用户。当然，我能想清楚这个事，毕竟能够给那些消费潮人们带来实际利益，赚他们的钱也符合天地运转之道。其实这话题写的有点意犹未尽，希望本文能在另外个维度做个补充。

运营为核心

表现为，运营推着“产品、研发”走。依托强大的运营销售实力创造经济效益领先对手。通常会很强势的打压产品和技术团队，甚至违反基本原则。好的情况是在一线接触客户了解更多需求的角度引领创新，差的情况是以客户的名义打乱研发和产品计划。

这种情况下，很可能产品团队和研发团队永远都是救火队，四处奔忙而缺乏长远规划。而运营一旦进入计划或某个阶段，很可能只有一条道儿走到黑，没有回头路。

个人认为，运营为核心其实是很不健康的状态，公司过分追求利益缺乏正确价值观，基本不会有长远预期，而无论多好的前景都很危险。国内很多互联网公司多少都有这样的状况，只因为红色土地的特殊情况，大家都在靠走钢丝的心态互相对掐，拼的不是积累沉淀，而是表面功夫。在互相没有核心壁垒，只比拼金钱和速度的竞争中，各种没有技术含量的手段也就正常了。

研发为核心

表现为，研发推着“产品”走。依托强大的工程研发实力领先对手产品，告诉产品团队现在可以做哪些事，将来可以做哪些事。研发是产品“可行性”的基础，其优势很可能形成对手无法超越的壁垒，这类公司潜力无限。

有些老牌的软件起家的公司里，基本都是这样的传统，以Microsoft为首。但如果没有良好的转换到做互联网的思路上来，研发实力也不能代表一切，其研发传统会严重导致产品的创新乏力。

互联网公司里可能最典型的工程师文化公司是Yahoo和Google，也可能Yahoo更典型一些。因为Yahoo似乎并没有自己设计出有口皆碑的产品来，但Yahoo工程师团队的实力业内均认可，有点怪异的现象。而Google系产品则是誉满天下，老少皆宜，童叟无欺，虽然外界用户顶礼膜拜的多半是Google的产品“设计”，但我认为这些其实都是“研发”实力奠定的基础。

比如我们在淘宝开放平台上做了款为淘宝店铺提供数据分析的工具“小艾分析”，最关键和压力的是咱们关于运算的研发能力。对于用户来说，使用工具来进行数据分析，核心需求自然是数据要准确，而产品层面的表现形式到是其次。

产品为核心

表现为，产品推着“研发”走。依托强大的设计创新实力而树立壁垒的产品，不断提出新需求，让研发团队来满足。产品用来维系用户“期望值”，但产品模式和创新其实很容易被抄袭，可能有句话能形象的表达“一直被抄袭，从未被超越。”

在创新环境相对健康的国外例子很多，比如linkedin,Flickr,Twitter,Facebook我认为都算。国内的“豆瓣”我认为也算，完全用产品建立的核心壁垒，国内的两家大公司“阿里巴巴”和“腾讯”也在逐渐往这条线上靠，建立了相对有益的创新机制。

还有个异类“Apple”其实也是这样的典型，这两年风头正盛，以“专注、极致”的创新思想横扫江湖。虽然其成功有一定运营策略的因素，但基本上还算“产品为核心”的结果。总结起来，就是足够吸引眼球的创新加上不错的运营，结果等于白花花的银子。最近老调戏Macbook Air，我从来都没否认Macbook的优秀，只是它不至于好到被吹捧的那么神奇而已。

在我的互联网职业生涯中，见证过很多产品的失败，我总结其原因基本都是对“产品”的不够重视。互联网其实是个很特殊的领域，我认为搞互联网产品的将来一定是“产品为核心”，也许这就是我们做互联网的基因吧。

相关话题：产品驱动力源地址：http://blog.rexsong.com/?p=12171

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

旁观者 — 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.”，作为产品出身的你，也许会认为上帝让你创造了一个好的产品设计，但魔鬼给你送来了一堆垃圾工程师；作为研发出身的你，你也许会想魔鬼带来的这个产品经理，需求改得那叫一个子龙大战长坂坡七进七出，把兄弟们折腾得不善。所以，强者为王。

PM与工程师

纯银 — 2011-02-18 00:15:09

过节前看到一篇文章，讲产品项目就应该由工程师来主导，但国内让PM去驱动项目，搞得乱七八糟，很恼火，怎么可能做出一款好产品来呢？

很显然，写这篇文章的是一位愤怒的工程师，Angry Engineer！我跟他至少有两点共鸣：

1、国内的PM确实常常折腾工程师，甚至不乏“把工程师当工具对待”的情况。
2、如果工程师有开阔的产品视野与全面的设计素养，知行合一，由工程师来驱动项目是一个完美的选择。

可惜由于教育环境的问题，国内通才太少。一个优秀的工程师，同时又是一个优秀的PM，凤毛麟角，只能人任其长，各自做自己拿手的活儿。这时候更擅长需求分析与产品设计的PM来驱动项目，也是不得已的选择。

说来惭愧。需求不靠谱，或是来来回回修改，折腾工程师的事儿我也做过不少，直到最近一年多才算是大有好转。我应该忏悔……虽然能做好PM的工程师极少，靠谱的PM其实也不算多，最后大家都得写周报对不对？

在产品行业远远不够成熟的现阶段，痛苦的来回折腾难以避免。但最起码，PM应该把工程师作为伙伴而不是工具，想法设法地站到一条战壕里去，争取他们的理解。因此抛开难以鉴定的需求的对错，仅仅从协作流程的改进上，我积累了以下的经验。

首先要得到工程师对整个项目的认同。每个月都有一场一小时的部门月会，对着PPT，我来讲下个月乃至下个阶段，我们的任务规划是什么，目标设置又是什么，详细解释制定规划与目标的原因，近景与远景分析，为咩做这件事情为咩这样去设计等等。希望工程师能认可他即将做的事情是有价值的，值得为之而努力的。为接下来PM与工程师的沟通做好铺垫。

月会上还有一个环节，详细分析本月发生的所有数据，尤其是最近发布的新功能的数据。这个环节也是为工程师准备的，使他们了解自己的工作能产生多少实际效果。

至于月会上送出的新功能礼品（以前讲过许多次），最开始是为工程师专设的彩蛋，再后来才将PM与运营包括了进来。我得承认自己对工程师偏心眼，因为有信心能激励PM与运营，却出于沟通深度不足，需要借助更多的手段来激励工程师投入项目。

项目任务分两种，大版本与小模块。对于大版本，在基本框架定下来之后，PM提前向工程师讲解，听取技术视角对设计方向的建议。整个设计过程中还会反复讨论三五次，为技术上的合理性征求意见。小模块则在策划案基本敲定之后，与工程师共同确认一次，视觉稿出来后再通报一次。（所以PM与工程师坐得近是很有必要的）

我曾经在部门月会上公开承诺说，任何一个需求，只要工程师认为是不合理的，都可以停下来不做。直到PM能说服工程师为止。如果死活谈不下来，才由我和技术经理出面来协调。强硬要求服从的情况在我这里基本上没有，被工程师说服倒是时有发生，按工程师提出的意见来改方案。我也常常跟PM讲，小分歧你们都听工程师的，没有必要坚持己见。你让他爽一点，开发速度就快一点，大家都获益。再说你多听听技术伙伴的意见有什么不好呢？帮助你转换思考的角度，共同找到提高开发效率的方法。

最后方案定下来了，PM说OK，工程师也觉得方向大致没错，细节基本合理；进度方面则由工程师进行评估。PM觉得时间太长接受不了，再找到我和技术经理一起商量，看是分阶段砍需求呢，还是加把力加点班。除了极少数紧急修复任务外，不会由PM单方面确定开发时间安排。包括一系列任务的优先级安排，也由PM先提草案，工程师根据开发情况来调整顺序，再共同确认。

在PM提出需求的整个流程里，始终在进行不断的协商，保证工程师对任务是理解并且接受的，不会出现抗拒，或者是麻木的心态。如果遇到突发性的需求变更，更加会向工程师反复解释，请求谅解，因为浪费了他们的工作成果而心存歉意。为此而花费的时间对比更高的开发效率，稳赚不赔。虽说具体协作时还有一些不到位的地方，但态度总归是好的，基本的效果也是有的。

当然，这套流程的实施得具备两个前提。第一是有稳定的团队，如果变成提单协作，这个月一起干下个月分道扬镳，那就不可能实现共同的项目归属感。第二是工程师的个人素质基本靠谱，沟通顺畅；尤其是技术经理可以服众，协调好分歧而不护短。比如说一个功能能不能做，至少开发多久，我和PM都搞不掂，主要靠技术经理来做最终判断；如果出现开发过程中的失误，或是不按照约定好的方案进行开发，则由技术经理进行处罚。我对开发组更多作行政管理，全靠这位技术核心伙伴来负责业务管理，他也会更深入地参与到产品的结构设计，任务规划里来。

这样做，也就撇开了把工程师当工具对待的嫌疑。我觉得把任何同事当工具都挺可耻。怎样才算是伙伴呢？比如交流必要的信息，理解对方；比如能站在对方立场去换位思考；比如多一点点鼓励与帮助。

换个角度看，我这边曾经出现过由工程师来提出大致构思，PM认可并负责细节设计，再由这位工程师来实现的情况。结果皆大欢喜。我后来多次在月会或别的场合征求工程师的创意，换一换视角，引入新鲜的想法与灵感。即便想法不一致，也会非常温和地解释反对原因，绝不可能一口否决。唯恐工程师们默不出声闷头干活——听不到技术伙伴的意见是多大的损失啊。

今上有敕云：“科学发展观的核心是和谐发展。”