从编辑到PM

标签: 编辑 pm | 发表时间:2011-02-25 18:10 | 作者:纯银 小鱼
出处:http://ucdchina.com/rss/all
春节前收到一封陌生人的来信,一位网站频道编辑,向我咨询转型PM的可行性。他问道:“你觉得做媒体和做产品,以前一样么?未来一样么?”并希望我为此写一篇日志。

话题很有趣,我也乐意就此写点什么。遗憾的是,编辑转产品的成功概率却是不高的,就我的经验来看,存在四个障碍。

1、傲慢
媒体工作需要捕捉阅读的共性,即“大家都爱看的内容”,相对来说比较忽视用户的个性化特征。由于阅读的共性并不难掌握,久而久之,容易形成判断上的主观倾向,即“我推荐给你的就是好的”,对自己的构想过分自信而验证不足,尤其轻视观点不同的用户声音,觉得那是少数派,或是不智之言,不值得看重。

这种思维模式在产品工作中是非常危险的。媒体阅读本身是一个轻交互的用户行为,变数相对较少,重视感染力而不是个性化,但到了更复杂的应用情景,个性化的倾向会指数级增加。换句话说,当你自信代表了大多数人的产品需求、产品习惯的时候,也有可能你才是不折不扣的少数派,必须通过专业的需求调研来验证其结果。然而在媒体工作中,研究需求与竞品的时间往往不超过5%,转型后也积重难返。

我的许多媒体同行,不论是大人物,还是小职员,在谈论产品的时候普遍存在这一问题。总想拿点什么东西出来吓用户一跳。这还是做报道,做专题的思路,强调自己的洞察力和创造力。然而这些判断并不是建立在市场分析之上的,既没有丰富的数据支撑,更没有大量的一手用户案例论证,就是一拍脑袋,蹦个灵感出来。因为我了不起,我敏锐我深刻,所以我的见闻一定有代表性,想法一定比别人好。下意识里排斥细致扎实的需求调研,觉得那是体力活,靠自己的头脑就能见微知著,举一反三。

2、逻辑
媒体有媒体的逻辑,产品有产品的逻辑,后者更接近技术逻辑。媒体逻辑往往强调,这个道理是讲得通的,有说服力的;而产品逻辑则会考虑,这个设计会引发一系列什么样的后果。或者更形象点解释,媒体逻辑是就事论事的逻辑,把这个观点讲圆,讲通就可以了。产品逻辑却重视牵一发而动全身,将观点放到一整个产品生态环境中去,考虑和它关联的数十个产品点之间的相互作用,也包括不同用户情景引发的多个分支路径。

两种逻辑并无高下之分,只是转来换去,殊为不易。从媒体转产品工作的话,单单是理解每个产品生态环境中包含的无数产品点,就是件非常艰难的事情。比起抓重点,抓共性的媒体工作,真是头痛欲裂。

3、浪漫
好的媒体人都有点浪漫情结,这是好事,衍生出更多的创造力与激情。但把浪漫情怀带到产品工作中去就变成了坏事。产品项目更接近工程项目,讲究务实性,讲究严密论证。可是人一浪漫起来啊,就容易自己感动自己,敢上九天揽月,敢下五洋捉鳖。

记得4年前,内容部门发起了一个超恐怖的产品项目,一听就傻眼了,人Google都没能做好。我含蓄地表达了对可行性的质疑,同僚淡然答道:“不要畏难,这个事情是很有价值的。”语气类似于“为什么要登山?因为山在那里。”此后来来回回断断续续折腾了一年多,产品还是一点可用性都没有,只好放弃。

同样是4年前,一位媒体同僚跟我感慨说,咱们有幸生在这个互联网勃起的大时代,天下英雄出我辈。四手相握,热血沸腾。后来我转型产品,他一直在做媒体,我们都折腾了不少产品项目,越浪漫的死得越惨。在不断的挫折中才发现,缺乏实证态度,高呼革命口号的浪漫实乃一剂毒药。你追求天翻地覆慨而慷么?最后头破血流创可贴。回忆起当初和他那一席对话,觉得自己荒唐得紧,浅薄得紧。

只是涉足产品领域一两年,一直浪漫,浪漫至死的媒体人,我也见过。败绩累累仍痴心不改。有次打交道的时候我曾跟他讲,你这构想,世界各国均无成功先例,并分析不能这么做的种种原因。随后得到回复,别人都做不出来,难道我也做不出来么?

另有一些媒体同僚,常问我这个项目能不能做,那个项目能不能做。答,必死,并解释各种原因。观其脸色不悦。再往下谈,他们并不能回击我的观点,只是傲然道,我们家大业大,难道就折腾不出来一点响动么?

你们行,你们就上嘛。不能具体问题具体分析,也不能预见执行中的关卡难点,而是用愿景与勇气去驱动的浪漫,哀哉。即便被捧上神坛的马云,在这个坑里也摔过不少跟头,一拍脑袋,高举高打又惨淡收场的事儿何止十件。相比起极少数成功案例,这些失败案例更值得分析,只是浪漫主义者不屑于去看罢了。BlingBling的市场传奇在灼烧着他们。

4、懒散

用懒散作为小标题,有点过了,但姑且这么叫。更准确的描述是,媒体人通常有智力上的优越感,并乐意做一些用智力来提高效率的事情。比如这事儿别人得做8小时,我3小时就完成了,又快又好,得意洋洋。

可惜产品工作中,不能用智力来提高效率的事情很多,又没法分给别人,自己只做“激烈的脑力活动”。结果就容易挑肥拣瘦,回避“粗活”,最后事情只做一半,到处都是短板。方案既不严密可靠,实现上也是漏洞百出。

此外,产品工作的强度远远超过媒体工作,任务琐碎,加班量大,习惯了“又快又好”的媒体人自然难以接受,也不适应繁琐并且不停变动的任务编排——如同单线程与4线程之间的对比,难免手忙脚乱。尤其是8小时工作惯了的媒体主管,有几个能吃下来这苦头?

我自己做了5年多的媒体,又转型产品3年,直到转型的第二年,才算是真正转了过去,很不容易。以上的四个障碍,前三点感同身受,也深受其苦。这未必是媒体人独有的毛病,很多原生产品人也犯,但媒体人必定发作得特别厉害,治愈不易——我也不敢说已经完全纠正过来。故而同样从媒体成功转型产品的人凤毛麟角,反倒从视觉或技术角色转产品角色的成功率会高出许多。

即便如此,仍不断有老同事问我,从媒体转产品可以吗?怎么转比较好?

我叹了口气,告诉他们一些方法。

1、每天看20条以上的互联网新闻,并订阅三五个大更新量的互联网博客,逐条细看一个月。随后再订阅二三十个博客,有选择地精读,常年坚持风雨无阻。

2、浏览新闻一个月后,选择一个自己主攻的细分产品类型,比如空间、微博、问答、点评、团购、LBS等等,找到该领域国内的一两个领先者,国外的一两个领先者,泡进去玩。必须以纯粹的用户角色去泡,去交很多朋友。

3、对于自己选择的产品类型,建一张excel表格,找出十来个关注对象,把它们的产品点拆分开来,记录你的研究心得与版本动态。每周更新一次。

这样坚持做下来三个月,对于能不能转产品,该怎么转,自己心里大致也有个数了。哪有什么良师,掌握好的自学方法才是王道。

源地址:http://firecacada.blog.163.com/blog/static/70743762011117101018480

相关 [编辑 pm] 推荐:

从编辑到PM

- 小鱼 - 所有文章 - UCD大社区
春节前收到一封陌生人的来信,一位网站频道编辑,向我咨询转型PM的可行性. 他问道:“你觉得做媒体和做产品,以前一样么. 话题很有趣,我也乐意就此写点什么. 遗憾的是,编辑转产品的成功概率却是不高的,就我的经验来看,存在四个障碍. 媒体工作需要捕捉阅读的共性,即“大家都爱看的内容”,相对来说比较忽视用户的个性化特征.

如何与PM沟通

- - 曉生
1.要学会听取别人意见,也许PM提出的问题你并没有考虑到,集思广益,可以得出有更好的方案. 值得肯定的是,你设计时已经能学会从产品角度考虑,引导用户操作,而不是单纯的好看. 只要不是单纯审美上的PK,都可以讨论,不是吗. 2.让产品阐述自己的需求点,明确重点. PM们七嘴八舌肯定不对的,要引导他们梳理出统一的意见.

PM札记:产品设计这两年

- - 所有文章 - UCD大社区
做产品差不多也两年左右了,基本上这条路是磕磕绊绊,迷迷糊糊,但好歹大方向是正确的,有空回想总结起来,唏嘘不已,看看以前对产品的看法,再看看今天对产品的认识,不仅感叹自己当初的幼稚,如今,更多的是了解了自己的无知与渺小,怀着一颗谦卑的心,继续学习,在产品这条路上寻找自己的价值. 产品职责包含很多东西,产品设计只是其中的一种职责,只是简单的描述一下我在产品设计上的弯路,回想起我的产品设计生涯,目前走过了三个阶段:.

PM培训的答疑课小结

- - 阿里巴巴(中国站)用户体验设计部博客
这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题. 对学员们和讲师的讨论,我做了些小结如下:. 产生这种情况说明项目管理已经存在大的问题了. 要做到的是提前预知,避免这种情况的出现. 万一出现了,首先要深入了解原因. 两个方向,项目内搞定或者项目外搞定. 回答这个问题的关键是找关键路径.

浅析PM工作流引擎

- - CSDN博客推荐文章
1.      JBPM工作流引擎是用来做什么的. 首先要说明的一点是工作流引擎指的并不只是JBPM,JBPM只是工作流引擎的一种. JBPM利用JPDL流程定义语言将现实生活中处理事务的业务流程进行抽象,形成一套业务流程规则,只要处理该项业务就必须按照这个流程规则进行. 举一个很简单的例子,就拿看医生来讲,看医生的整个流程必须是先挂号,再看病,再抓药,只要你进行看医生这个业务就必须按照这套流程进行.

如何防止架构师PM化

- -
和一些做项目主架构或者一号位的同学聊天,经常会听到一种说法:项目主架构做着做着就会做成PM. 这背后什么含义呢,细品下来有几层意思:. 整个集团的架构非常复杂,涉及的域众多,做主架构或者一号位需要大量的协调投入;. 不同域之间的资源错配现象严重,需要投入大量精力在锁定资源和推进排期上;. 项目结构过于复杂,PM催主架构,主架构催域架构,域架构催开发,层层订,各种站会,代码没几行,会议一大堆;.

您的团队需要什么样的PM?

- - 所有文章 - UCD大社区
     在腾讯,多数部门的实际采用了职能化或弱矩阵的组织结构形式. 中心和小组等组织层级实质属于职能线条,产品、开发、测试、运营、运维等职能角色是产品运营的主要角色,而各部门都会或多或少有一些全职或兼职的PM组织管理着各类跨职能活动.       基于各自情况的不同和各自对PM职位理解的差异,对PM职位的定位也千姿百态.

PM成长日记:从需求到产品

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
   本文作者系大众点评产品经理@ 七手八脚裸奔地小石头.   本篇本来打算写如何跟技术进行沟通,其实跟技术的沟通,是贯穿于整个从需求文档到产品上线、产品跟踪、迭代的过程之中的. 本篇更多的是讲作者工作半年来,从需求文档到产品上线的过程,也希望与同行朋友多交流.   当你辛辛苦苦写出来一堆需求文档,跟UED的同学定好交互、视觉、重构;满以为技术会认真对待,但是你会发现,技术同学基本不会看你准备的一堆东西,基本是按照自己的理解来开发,当开发不下去,第一时间也不是看文档,而是看测试用例,或者直接跟产品沟通;基本文档只是QA同学对着写用例.

作为一个PM 该如何做好产品竞品分析?

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  在企业中竞品分析工作大多数产品经理实际工作中很少去做,要么由市场和运营人员代劳,也或者产品部门配备市场研究相关岗位定期来做. 而近来部门同事实行每月对现有产品进行竞品分析,参与一部分工作. 对于既不是专才和通才的产品经理来说也是一种全新历练和学习.竞品分析结果只能作为一种参考依据(由于信息挖掘渠道和关注点都相对带有主观性,比较危险的是有些产品经理会特意朝预期潜意识心里判断来收集数据),通常服务于领导及产品管理层对产品信息动态能够有意识的去关注及时调整相关目标;.