当前位置:首页 > 营销知识 > APP推广干货分享 > 正文

聊聊「APP产品经理」和「Web产品经理」的区别?


Data: 2015-08-05
 

移动互联网产品经理和互联网产品经理,基本的技能要求并没有本质的区别。但是因为无线自有的一些特点对以下几部分是要额外关注的(注意是额外关注,即相对互联网产品经理要更多出的一部分):

 

对各种移动平台了解充分

 

所谓的了解,最基本的,是指需要对系统的边界、极限很清楚,如iOS上哪些特性是系统自带的,工程师几乎无需开发就能实现的(如定位);哪些是需要工程师做底层开始进行开发的,哪些是不可能实现的,哪些是越狱后可以支持的(如电话拦截接听)。

 

上面是基本要求,更进一步的,最好对系统整体架构有所认识,如iOS的架构中3d引擎使用的是什么,有什么优劣?

 

这里的理解其实并不需要产品经理深入底层,也不需要阅读代码,而是只从系统构架和逻辑角度能做到心中有数,尤其是对性能边界很清楚,如,android系统的浏览器内核是怎样的?有什么操蛋的地方。

 

对产品质量的控制力较web更高

 

无线产品中除基于WAP、Html5的外,只要是以APP形式出现的,都是用户以软件包的形式下载并安装的。这意味着,无线产品不像互联网产品,可以出了问题随时可以修正。

 

一个软件包一旦发布,就意味着覆水难收——你显然不能指望通过升级版去纠正上一版的重大错误,因为重大错误足以让用户不再浪费时间再去更新。因此,产品经理需要对质量高度重视,包括:

 

发布前反复测试,确保没有质量纰漏——说直接点,无线产品经理对测试方法、流程要有较web深入得多的了解。原则上,一个无法像测试一样去发现复杂bug原因的产品经理,不能成为一个特别优秀的无线产品经理。

 

熟悉各种通过产品设计提前留好挽救冗余(如push功能,自动乃至强制升级功能)。

 

对发布后,不幸出现的问题,要能及时的响应和解决,这里的即时主要不是指速度上,而是指策略上,因为那个时候你往往要面对很对“艰难的决定”,如:

 

是否要马上发布一个bugfix版?

 

还是等待下一个常规版本再解决?

 

是否该功能模块可以在服务端做补救?

 

是否可以终止此模块服务但保证其他的继续可用且向用户做出解释?

 

对项目的控制力要强于web

 

由于上面提要的质量需要更高要求,再加上客户端开发无法做到无限拆分功能模块,周期一般长于web项目。因此,产品经理对项目的控制力将会很受考验,如何有效的在前期规避项目风险,较好的在整个项目中均摊项目压力,以及当项目不得不delay时,如何做出决策。

 

这都将很考验一个无线产品经理。相比web上delay1个月算大“事故”,客户端delay2个月的状态在十分成熟的团队中都会偶有发生。

 

对产品线构建和管理要有很好的意识

 

无线产品经理有一个很幸福的地方,产品天然不能做得太大——有经验的PM一定很能理解这话的意思:)。但,如何找到合适的切入点,以简单、小巧为“基本面”,同时又能满足核心用户的重要需求?这是难的课题。

 

由于产品小,对应的情况是,往往会出现产品线会多的情况。一个一线的、资深的无线产品经理同时cover3~5个完整的产品线甚至更多,并不是什么很奇异的事(但你让做平台型web站点的产品经理试试看?)。产品线多了之后,产品线之间如何配合,如何做到互相支撑、借力而不是彼此打架,这是非常难的课题。

 

资源、节奏控制要极强,让团队既能多线运作,又有节奏。

 

项目周期长,产品线多,平台多。这是一个倍乘关系,我们有时会看到一个无线产品经理做2个产品,但是4个系统平台,实际上他是占用了4*2=8 个开发项目资源!这在任何公司都是很恐怖的。

 

无线产品经理必须能即时、敏锐的做好资源控制,节奏设定,在砍掉不需要的项目和产品的同时,为整个研发部建立节奏感。

 

多久发布一个版? 多个产品线产品、UED/UI、 前端开发、后端开发、测试如何穿插协调?

 

项目有冲突怎么预防、实际发生怎么解决?

 

但更高的要求是,这些问题都不存在,产品经理能做到在团队中建立起节奏,让所有人能像跳竹竿舞一样,灵动、高效、发自惯性和直觉,而又能不被竹竿夹着腿。实际上,能为无线研发团队建立好开发节奏的无线产品经理在整个行业都是很珍贵和难得的。

 

知乎-仗剑:

 

先说共同点,产品经理的共同点就是围绕一个群体的一个需求打造一款产品,这个产品可以是一个网站,可以是一个软件,也可以是一个手机APP,当然也可以是一个实体工具,最早的产品经理来自于宝洁,所以,所谓的产品经理的核心能力是相通的,就是洞察用户需求,采用某种办法解决这个需求,实现自己的利益诉求。

 

从这个角度看,李家村的铁匠王家屯的木匠不也是产品经理么。

 

具体到互联网的细分领域,是有偏重的。从产品形态说,互联网领域主要有三类产品经理,一是网站产品经理或者叫web端产品经理;二是软件产品经理或者说客户端产品经理;三是APP产品经理或者说移动端产品经理。

 

有什么区别吗?当然有区别,铁匠和木匠都是解决需求做个吃饭的勺字,但是你做得好铁勺未必代表你一定能做好木勺,因为铁匠和木匠解决需求的手段是完全不一样的。

 

木勺和铁勺没有优劣之分,也没有谁更值钱,完全取决于市场需求。

 

移花接木到互联网产品,你是一个做web端的产品经理,你未必懂移动端的交互,未必懂移动端的实现困难,未必懂移动端产品的操作特性,未必懂移动端的用户行为习惯,未必懂移动端的运营规则。乍看之下,好像没多大区别,但是高手的区别仅在于细节。

 

按照木匠的思路去做铁器,未必做不出来,但是要做一个精致的高质量的铁器,恐怕你还是得接受铁匠的那一套玩法。

 

举个很简单的栗子,在web端时代,大家的主要玩法就是网站做出来SEO,这曾是web时代各大网站的主要运营阵地,到了移动时代,百度忽然被边缘化了,为啥?

 

很简单,大家获取app的途径不是百度搜索,那么你再懂SEO有啥意义?数据说明问题——我们的产品到此为止各种渠道获客来源中,SEO和SEM的效果仅占2%,注意,是个位数,聊胜于无。

 

再从产品设计的角度看,IOS和Android系统,以及WP,一直在升级,IOS每一次的升级改版,从IOS6到IOS7的巨大变化,带来的是一整套的交互规则、UI规则的升级,这些都需要产品经理花时间去研究,在研究的基础上发展出新的设计,不仅要考虑创意,也要follow规则,这些东西,不是说做过web端产品或者做过客户端软件的人就能轻易搞明白的,同样的是卖东西,卖首饰和卖大米还是有很大区别的。

 

再从应用场景来说,移动端产品最大的特殊性在于用户是用碎片化时间操作,而传统的客户端和web端产品是用户坐在电脑前花几个小时去玩,所以不论是游戏还是其他应用,你都必须考虑用户是一个急躁的小白,弄得不好就把你删掉了。

 

并且用户可能信号不好,可能网速很差,这也需要你在做产品的时候充分考虑各种复杂的场景,比如说你的app里要调用GPS,如果这个时候GPS信号弱,咋整?

 

这些都是PC时代根本没有的新问题,总之就是一句话,老革命遇到了新问题。

 

做移动端产品,更像是做实验,产品往简单了整,但是功能还要保证强大,一个“微”字,囊括了很多东西,传统PC端那一套铁定是不行的,等你规划了半天的产品上线,媳妇儿都改嫁了,你还硬气个屁,所以移动端更需要快速迭代,敏捷针对市场动向调整产品策略,也能更快看到成果。

 

我刚才举的栗子,都是些显而易见的栗子,还有很多很多藏得很深的栗子,比如移动端的用户怎么分析,用户机型的考虑,这些都是老革命遇到的新问题,事非经过不知难,没干过移动端的产品经理,即使有十年web端产品经验,未必能练此功。

 

更可怕的是,人是有惯性思维的,一个人在web时代越成功,越容易走进死胡同,你要证据?看看微信和手Q。

 

别急,我这有个BUT。

 

但是,不管是移动端产品经理,还是web端产品经理,或者是软件产品经理,在“道”的层面是完全一致的,区别仅在于术、法、器,所谓的术,就是执行手段,所谓的法,就是工作方式,所谓的器,就是借助的软件。

 

这些层面的东西,其实都是很容易懂的,一个真正得道的产品经理,完全可以轻易超越术、法、器的低端竞争,用他的产品之道解决所有问题,但是这需要你足够牛叉,就我看来,大部分的产品经理还是需要在后三者多一些积累才可以。

 

至于要求高低的问题,我认为没有任何区别,web端也同样要求很高。题主想必是多年web产品老兵,找移动端时碰了一鼻子灰。这个问题很简单,去年全中国西红柿产量超高,虽然红彤彤一个个,但是不好卖,于是今年大家都不种西红柿,于是菜市场西红柿100钱一斤,种西红柿的人发了大财,而今年种白菜的未必就那么好运气了。

 

时也,势也。完全只是供求关系变化罢了。

 

哎,不想当厨子的裁缝,不是好司机啊!

最新更新文章