来源|鸟哥笔记

作者|刘锤

我09年毕业开始干互联网,到现在刚好7年。

这七年间,除了写代码以外,互联网行业几乎所有和产品/运营相关的工种都或多或少干过了,而且年限还几乎差不多,三年半产品和三年半运营,以至于经常被人笑话是样样稀松的万金油。

一年半以前我写过一篇总结运营的文章《高级运营和普通运营有哪些区别》，很多朋友来找我聊。有聊困惑迷茫不解的,有聊职业发展的,有聊要不要转行的,也有聊具体工作问题的,我也都尽量能回复和探讨。

但我现在很愧疚,我之前说的东西,我现在认为已经不适合这个新的时代了。

所以我想说点不一样的东西,和我理解的产品和运营的发展趋势。

技术领域有个很有意思的新东西(也不算新,概念提出到现在好几年了)叫微服务,这微服务可不是什么微信做微商那种概念,而是一种在开发领域中技术架构层面的创新。我也不写代码,但本着对技术的关注和好玩,买了点书看了看,结果如获至宝。

具体的东西如果大家有兴趣可以稍微看看《微服务架构与设计》和《微服务设计》这两本书。

我对这东西的理解是这种开发架构,把以前的一揽子框架解耦的很彻底,每个应用被分解到有一个专门的服务与之对应。举个可能不太恰当的例子,就是我们看58同城这种传统分类信息网站,信息发布者和信息获取者,是同一套系统在支撑的。这是基于一种人人都可能同时是发布者和获取者得逻辑。而现在,优步滴滴等快车应用,就拆成了专门的司机端和乘客端。你说有没有司机同时是乘客呢?当然有,但为什么不合起来呢?因为拆开能更专注的提供司机和乘客分别的体验。

当然实际的技术开发中,这种解耦没58-滴滴这种对应那么简单,因为我们今天讨论产品和运营的问题,所以就不展开细说了。

我之所以要先引入这个概念,是我觉得可能在产品运营领域,下一个3-5年,有可能会出现和微服务极为相似的职业变化情况,即非开发工作的“彻底解耦”。

我给这个概念取了个名字,叫“产品运营的去专业化”。简称de-professionalism of pm。

首先,我们先来看看传统意义上,互联网行业的工作中,对产品和运营的划分。

产品:

产品规划 | 需求分析 | 项目管理 | 竞品分析 | 原型设计 | 数据分析 | 文档撰写 | 沟通协作

运营:

市场调研 | 用户运营 | 渠道投放 | 品牌传播 | 社群活动 | 内容运营 | 商务拓展 | 活动运营

为了好对应,我各写8个,多的就不写了。

基于这个分类,我们似乎很容易得出一个人到底的工作算是产品还是算是运营。比如你在公司的核心工作是投各种广告平台,或者你负责新浪微博/微信公众号的文章发布,或者挨个去拜访合作伙伴谈合作项目,那你毫无疑问算是一个100%的运营人员。再比如你每天的工作就是采集需求然后出原型图,每天和开发同学沟通业务逻辑,甚至你得自己去写sql跑数据,axure是你最常用的软件,现阶段你似乎也算是一个100%的产品人员。

但从我最近一年多的感觉来看,这种可被轻松定义的100%纯工作越来越少了。有很多和我交流的同学,上来第一句话都:“我也不知道我算产品还是算运营,总感觉什么都干”。我相信这个观念会萦绕着很多人的内心,让他们产生对个人技能发展和职业路径的困惑。

问题:我到底算产品还是算运营?

衍生问题1:我的职业发展方向到底是产品还是运营?

衍生问题2:如果我是个产品/运营,那么那些运营/产品的事情我要不要做,要怎么做,应该学习什么来更好的做?

衍生问题n....

......

而且不光是一线执行的同学,更多的管理者也有这种困惑。到底怎么为某个看起来很卖力的小弟规划职业路径?这哥们再升职,应该放到什么地方给什么title?这些问题如果不解决好,就经常会发生人才流失的问题。

讲道理,三年前,这种困扰其实不多。但是,时代变了。

在互联网公司中,设计、开发、以及作为职能部门的财务、人力、法务等,都是有非常明确职业路径职位。假设我们谈论一个刚毕业的设计师,他的职业发展路径就是从一个小设计师慢慢变成一个行业的大师,当然在他发展的过程中,也不可避免的要有些拓展,平面,ui,广告,网页,app等等最后可能都要懂一些,但是假以时日,他一定会成为设计行业之中一个特别精通x和y的大师,并作为一个行业领袖存在着。

开发也是一样,一个程序员大约工作三年左右就会定性下来,他会有一个标签,例如”后端-java工程师“,他的技能发展方向可能就和”数据挖掘-python工程师”差别会越来越大,再往后四五年,他们就可能会是完全不同领域的不同专家,彼此之间切换很困难(当然其实也没那么大鸿沟,主要是他们这七年,踩过的坑差别会很大)。

人力财务法务就更不用说了,专员-经理-总监-更屌的公司的总监-更屌的公司的cxo这是一条非常明确的路径。

我们所谈论的这些,本质上是因为这些工作的“进深”(引用一个建筑上的词儿)很深,一个干了十年招聘的人力和刚毕业干了一年招聘的人力,差别可能是非常非常巨大的。在他们的职业发展路径当中,有足够的圈子内学习动力和机会,以及有明确的职级/薪水晋升路径。

但产品和运营不是。

互联网的这些工作里,是没有类似“平面设计”这种进深极深的工种的。换言之,没有那种能让你干一辈子干到老成为“xx大师”的工作。

假设某个叫小A的同学,今年刚毕业,到了一家公司做渠道投放,一开始这家公司只开了搜索引擎推广的账户,小A负责做SEM。小A做的不错,过了一两年老板晋升小A,又招了几个小弟分别负责搜索引擎,展示广告,新媒体广告等等,小A晋升为了渠道经理。

再下一步呢?

小A能做渠道经理做到自己60岁吗?

在传统的行业,这可以,尤其是那种传统意义上的渠道,各种经销商,定期开会喝酒,都是线下的生意,活到老学到老。

在互联网行业,有点难,因为搜索引擎一个智力正常,勤奋的人大约一年就已经是高手了,做内容运营大约也就8个月就到头了,采集各部门需求画原型图,不到半年就应该已经玩的滚瓜烂熟了。

然后呢?

很多和我交流的同学们的痛苦,就来自于“我现在干的事情已经很熟了但是限于环境我没法去拓展更多的东西了”,然后他们会问我下面干点啥,往什么方向拓展好。

对产品运营的工作来说,我们的职业路径不是纵向的。一个人写文案,写的再nb,不可能让他写一辈子,就算他专门去了以文案为生的公关公司,那他的职业路径也是成为那个公关公司的总监、副总、甚至自己当ceo开一家公关公司。

很多技术开发和设计领域的同学们,会纠结一个问题:我工作x年了,我要不要转管理,还是继续精研自己本身的职业方向?

对产品运营来说不存在这个问题,因为单个工作的进深有限性,天然就是要转管理的。

以上废了这么多话,就是要先意识到“产品运营工作的进深有限性”。

那么我们再来看看上述的16个工作

产品:产品规划 | 需求分析 | 项目管理 | 竞品分析 | 原型设计 | 数据分析 | 文档撰写 | 沟通协作

运营:市场调研 | 用户运营 | 渠道投放 | 品牌传播 | 社群活动 | 内容运营 | 商务拓展 | 活动运营

如果你工作了3年以上,你看看你曾经做过的事情能覆盖多少工作,是否你明明认为自己属于产品/运营,但是却干了很多运营/产品的活儿。自己出原型图来推push活动页开发的运营几乎和自己做市场调研的产品一样多。尤其是在规模较小的公司,你会跨界覆盖的更多。

以BAT为首的大公司致力于让人员专业化,比如调研就一个人专门负责调研,用户运营就一个人专门负责做一小波用户的维系。但这种专业化,天然就和岗位人的职业发展产生了矛盾。

从公司角度,希望人员稳定,产出稳定。一个工作一年的媒体监控人员总比刚来什么都不会的实习生要好。但也没法给这个工作在不晋升为管理者情况下更多的薪水了,因为残酷点说“这个工作就值这个钱”,为了公司管理利益,专业化是必然的结果。

从个人角度,希望有更好的职业发展,title和工资都能稳步上升。所以如果工作1-2年,如果想拿多点薪水,在纵向拓展没办法的情况下(公司不可能开高薪给一个只做媒体监控的人),只能横向拓展更多业务,而本公司内横向拓展,就面临着要成为管理者的问题(不然就会抢别人活儿了),而本公司内晋级毕竟有限,这时候就会跳槽去别的公司当经理了。

所以走上管理者岗位是产品运营人员天然的结果,无非管多大而已。

但公司又不可能让每个人都走上管理岗位,这就形成了天然的矛盾。

这个矛盾早已有之,但在近一两年尤甚。我看到的是在产品运营行业当中,大家平时日常使用的工具变得越来越便捷和易用。你可以用strinkly很快做一个酷炫的landingpage,也可以用mikecrm很快的组织一个用户调研的表单,用墨刀飞速攒出一个app原型,还有像epub360这种极快的h5页面制作工具。工具的易用性带来了工种门槛的降低和手段的多样化,这意味着产品和运营各个工种之间的边界会越来越模糊。

比如运营同学小A要做一个病毒传播的h5,研发说手头紧,产品说工作忙,设计说得排期。小A一怒之下自己用一大堆组合套件和现成框架自己做了一个,跑起来以后拿到数据证明这条路是可以的,于是说服老板投入更多资源做个好东西。

小A不依赖于任何人,某种程度上说抢了很多人的饭碗。

很多事情都变得可以“自己动手丰衣足食”起来,对那些能力强,不断渴求学习的人来说,是一件莫大的好事。

如果你是技术人员或者有技术背景,你会很容易想到一个概念叫“全栈工程师”。没错,我要说的就是这个。所以这里我要把”去专业化的产品运营“叫做”全栈pm“(抄一下概念)。

pm取百度的product & marketing之意,而不是产品经理那个product manager之意。

基于全栈pm,在业务构架上就有了更多可能,我们刚才讨论的公司需求和个人职业路径的矛盾可能也会得到解决。

新型的公司构架,很可能不会像现在这样,有一个产品部门,由一个产品总监lead,再来一个运营总监lead的运营部门,两边势如水火,经常扯皮和推诿。而是像微服务在架构层面上的改动那样,把公司业务打碎,粒度划分到比现在可能更细,每个细粒度业务由一个全栈pm负责来推进。如果遇到专业上的不熟悉,可以全栈pm之间互相学习和琢磨,继而去探索。

这语言上比较难以描述,我画几个图大家感受下。

这是传统的产品运营金字塔架构,这个独立产品可大可小,如果大,那最下面可能就是不同的部门,如果小,那就一个人会干很多个事情,出现身兼多职的情况。

传统的金字塔架构问题是,当产品不可避免的发展大的时候,就会从一个人身兼多职,慢慢变成一个需要专业化的金字塔。这里面的变数在于:1,最开始这个人是否足以当一个合格的管理者;2、新招的人,是否在某个具体的工作上能超过一开始的人?

所以我猜测未来有可能是这样的(事实上很多公司已经在这么用了,包括bat某些独立的产品)。

这里把产品独立拆成若干业务线,每个业务线有几名什么都做的全栈pm来统一进行产品和运营工作,由一个较为资深的pm带领。具体拆的细分粒度看业务诉求了。然后每个人都有独立产品设计、对接研发、推向市场,接触用户的权限。不再区分到底是产品还是运营工作,而只是就事论事的看业务线本身所需要的。

这么做优势我认为主要有这么几个:

1、人力调配灵活:随时可以将不同业务线的全栈pm们调换或者借调,只不过每个人的技能侧重可能不一样。但这个侧重和传统架构里的“专业化”是不一样的,两个三年的全栈pm可能主要技能都在80分以上,但可能有几个技能在90或者100分,这也是合理和应该被鼓励的。

2、更有利于走上管理岗位,和更好的职业发展:在这样的架构中,每个全栈pm未来都不可避免的要成为管理者,而因为他们技能的多样性,导致接手不同产品的不同业务线非常快,而且因为业务线的细化,在大行业来讲是更容易重合的。而且如果公司里没有那么多管理的坑,这样晋升的方式就是资深的产品运营负责人,某种程度上,独立主导一个产品的产生和发展,这事情进深就已经足够大了。

当然也有缺点,比如你至少需要一个资深一点的全栈pm来作为这个业务线的负责人(相对于业务线的粒度来说),这类人目前在市面上是少的。但我觉得三五年之后,随着工具的进一步便捷和手段的进一步多样化,很多东西学起来是非常非常快的,全栈pm也会越来越多。还有缺点就是个别确实需要专业化的工种是不太适合作为全栈的,不过这也简单,抽出来作为独立的support就可以了。

当然,这只是一个泛化的模型,具体讨论起来细节有很多。

举一个例子:

ABC公司是一个刚刚拿到B轮融资的公司,公司的主要产品是一个赌球app(既然是假想咱们就讨论些非法的东西)。公司的app主要有3个大独立业务线:足球信息资讯,赌球竞猜,赌迷社区。

传统的架构(尤其是公司小的时候),很可能是有一个产品部,然后产品部里面有几个产品经理,分别负责这些业务功能的产品设计和跟进,再有一个运营部,有些人负责搜集足球信息,请一些资深足彩写手来写文章,再有些人负责监控每日竞猜数据和赔率支持,再有些人负责在赌迷社区里活跃,找一些ugc,搞线下社交等等。

我们不要这样搞。

我们先按用户的属性,分成三个组,五大联赛组,中超组和其他组。

每个小组的全栈pm负责各自用户可能会做的所有事情。比如五大联赛组的pm要从产品的设计,用户的运营,引导充值和下注以及活跃后续的讨论等等。因为用户虽然是割裂的(关心英超的人可能根本不会看中超),但用户行为不是割裂的,一个赌迷可能先看看资讯,再去下个注,再去球迷社区看看帖子等等。

而一旦有欧洲杯这样的大事情,就可以三个组里分别抽调一波人,来做一个专门叫欧洲杯的项目,这个项目里面也都是全栈pm,从欧洲杯产品的设计开发上线一直到推广运营赔率计算和球迷活动组织,一并进行。

这思路其实一点都不新鲜,项目化做事古已有之,但全栈pm的意义在于,把所有日常的事情都当成是特殊的一个项目(就像微服务那样),把项目常态化。

那么这里又会出现一个问题,业务组分到多细是合理的呢?我的倾向是,按用户来分,看用户重叠程度来确定。比如如果有必要,把五大联赛具体分为英超和非英超(毕竟英超球迷多商业化好赌金多),用两个小组去跟进。

而且为了保证产品整体的统一性(比如你不能让英超和中超用差别太大的UI界面吧颜色虽然可以换换),需要各个组例行进行标准的统一和规范的确定(有点像技术开发里面一个公司对于代码规范的要求,这是有必要的)

谈到这里,可能你会觉得有点理想化和纸上谈兵,但事实上是很多公司虽然没有这么说和这么要求,但其实已经在这么做了。尤其是以bat为首的公司,你但凡看他们那些近一年内推出来的新业务,几乎初期全是各个其他老部门抽调出来的全栈pm。随着业务顺利发展,会招一些工作经验不足的毕业生实习生来做一些基础的细分工作,但一段时间之后,很多人都具备了从需求采集画原型图跟进开发到产品上线以后的推广运营功能迭代等所有的技能能力。

用他们自己的话来说,这叫”被逼出来的“。

我们总会被逼无奈的去学一些东西,那么如果学习成本越来越低,不如主动去学习,职业进深不够深,那么就往更广的方向去走走。

因为产品运营工作不同于设计/开发等进深比较深的职业特殊性,全栈pm将是未来互联网对产品运营人才的大趋势。所以不要把自己局限在产品还是运营这种问题了,对于某一波特定的用户来说,你既是产品,又是运营。你所要做的是让你的用户觉得你的东西有价值,持续的用,围绕这个问题,到底是功能改进,还是活动的策划,已经不重要了。

总会有一些工作是那些连“是不是要招个专门的人来干这个”都不确定的类型,这时候就是全栈pm的价值了,因为如果某些细分的东西你不懂或者很快学习到了解的程度,连找外包你都可能会被坑。

当然了,在产品运营某个细分领域上一定程度的专业积累是很有必要的,所以2年工作经验内的新产品运营人,还是致力于积累2-3个核心技能,从实践到方法论都有了基础的保证,再去扩展其他技能点吧。

所以说到最后,我给全栈pm下一个定义:

互联网相关工作中,能利用多种技能和工具,在快速学习能力的基础上,可以独立完成产品的规划设计,开发上线,运营推广全流程工作的岗位。

成为全栈pm的人,工作不是为了成为某个资深的专家工匠手艺人,而是为了“做成一件事”。为了”做成一件事“,会去在学习成本可控的情况下,学习所有相关的技能。如果你致力于成为一个专家/工匠/手艺人,互联网行业的产品运营工作真的可能不是你好的选择。

每个公司的创始人,不就是第一个全栈pm么。

接下来我们聊聊全栈pm的技能树及学习路径。

在讨论细节之前,我要指出,“全栈pm”并不是一个我凭空生造出来的概念,它是实实在在发生在现在众多互联网公司的产品运营人员的现状,我们虽然借用“全栈工程师”的“全栈”,但毕竟和开发领域是不一样的,具体的差别我后续会说。所以大家也不用非要去套用全栈工程师的一些概念和结论,差别真的很大。

全栈pm,和现行管理结构下产品/运营以及产品/运营内部的岗位割裂状况,最大的区别在于其万金油属性,即“什么都会”。但万金油只是一个表象,万金油的表象背后其实是超强的“学习能力”。但学习这个事情吧,总会有投入有产出,时间有限情况下,学习哪些东西算是基础,能为以后学习其他东西打下更好的基础,让学习其他事情变得更容易,就是我们这次要着力探讨的问题。

首先,本着以终为始的原则,我们要明确“全栈pm”的核心价值和竞争力,再去谈怎么建设和培养打造这些价值和竞争力。

任何一个互联网产品,总得创新,总要不断的在创新的方向上试错。而论及试错,就会有成本的高低。你直接招一个资深xx,再招几个高级xx和几个初级xx(xx代指各种被割裂的岗位如渠道运营,产品经理,新媒体运营等),上来什么都没干一个月几十万工资开出去了,然后发现不行,产品没人用或者市场环境不合适,砍掉这个团队或者转岗——这是试错,高成本的试错。你找个人,先让他摸索,且不论人愿意不愿意(有相当概率是不愿意的,毕竟可能远离自己以为自己的主要职业方向),让他自己从0开始尝试,一步步学习,几个月学习成本太高(毕竟很多东西之前没接触过),然后错过了市场机会,这也是一种试错,成本低的试错。

高举高打和小步快跑,在策略上讲,都是一种选择。巨头做某个东西,资源充足,当然要高举高打,恨不得直接气势如虹的霸占市场,创业小公司做某个新东西,资源紧张,当然也得小步快跑,最小投入下验证新东西靠不靠谱。所以成本高低其实不重要,重要的是在这些成本投入下,我们是否能验证“这个方向有戏,继续加大成本投入”的结果,继而判断出这些成本是不是值当呢?答案很显然是不一定的。

而我认为,全栈pm,及全栈pm带领的团队,就将是平衡这些成本的一个很好的方式。在有限的资源下投入数量可控的全栈pm,直到这些新业务足以被验证“是否要加大投入或者砍掉”,再接着往下推进。如果加大投入,无非变成一个新业务新部门,如果砍掉,没关系,他们还可以做别的事情。这就比招了一票专业的人结果发现这个方向没得做,而他们也无法实现内部转岗,导致不得不裁员(或者等着大家辞职)的悲剧要好。我相信这个场景很多人应该都经历过吧。

所以,全栈pm的核心价值在于两点:

1、创新业务的发展初期最大程度节约成本;

2、业务发展中后期有可以纵览全局的管理者。成本优势和全局业务掌握能力就成为了全栈pm相比普通团队和管理者最大的竞争力。(遇见过xx出身的经理根本不懂oo但是却对△△指手画脚的情况么?你懂我在说什么。)

这事儿其实很好理解,具体的成本核算和管理方式我会在后续的章节中讨论,这里先不展开了。(其实还有一个隐藏价值是防止产品的核心资源过渡集中在某1-2个核心岗位的人员身上,算是鸡蛋不能放在同一个篮子里的感觉吧,因为一个全栈pm去replace另一个全栈pm其实是很简单的一件事情。这里咱们后面再说)

所以围绕这个核心价值,我们再来看看一个全栈pm的天赋树应该怎么点。(全天赋图附后,先不要看这个,读完了再看)

首先,在最最一开始,有三个核心基础技能方向,以及对应的核心进路(approach)

1)产品设计(核心进路:原型设计)——站在远端思考用户。

2)获取用户(核心进路:渠道投放)——站在中间观察用户。

3)深入用户(核心进路:用户运营)——站在近处倾听用户。

在三个大方向下,基于这些核心进路,可以扩展到整个互联网产品运营的方方面面,而且这些工作中积累的基础,会成为快速学习的保证。

现行的岗位割裂机制下,我们很容易见到离用户极远的产品人员,为kpi机械投放的渠道人员,天天鸡毛蒜皮说用户要爆炸了的运营人员。如同盲人摸象一般,每个人理解的都不一样。你是产品经理,用户的反馈在你看来只有大小,优先级之分,而不是一个个活生生的个体;你是渠道经理,对你来说只有成本--下载--激活的路径,用户是谁你可能根本不用关心;你是运营经理,你觉得用户无小事,一千个用户反馈的问题和十万个用户反馈的问题你认为同等重要。即使偶尔我们会装模作样的做一些用户调研和访谈,但这些事情真正能解决问题么?我们都心知肚明。

所以我们需要能平等的从不同距离感知用户的全栈pm。他们要做的事情不是画出多漂亮的高保真原型图,架构多复杂的产品逻辑,或者精通多么完美的渠道引流细节和建立超级完美的死忠用户社群,他们要做的是在每个方面都能做到70分即可,对,不是80分(还可以)也不是60分(刚及格),而是让人说好也不行说差也不行但是勉强可用的“70分”,而且在这一点上,能力越平均越好。

无论你曾经的工作是什么,强项是什么,如果你想做一个优秀的全栈pm,你需要在这三个核心大方向上能力越平均越好。因为你的能力越平均,就意味着你看问题更容易回归到用户-产品这个最简单的逻辑关系中去,任何一个超出其他能力太多的方向,都可能会因为离用户的远近,给你带来一种偏颇的视野去理解这个关系。你要破除的就是“以产品/渠道/运营的角度看用户及用户产生的问题”这个观念,重新建立一种对【用户-产品】的关系过程密切关注的研究方法。即不要以用户为中心,而要以用户对产品从陌生到熟悉的过程去发现问题和解决问题。

某些有技术背景的同学可能就会忽然想到:这不就是面向对象和面向过程的区别么?我只能说真的很像。

(PS:这里的越平均越好,和我上一章所说的“某些具体技能掌握到90分100分”是不冲突的。毕竟总有些东西我们学习和掌握的就是比别人快和好,这个只是具体的一些实操技能的熟练程度而已)

我们接下来再看看这三个技能方向中,有哪些基础的你应该掌握以及为什么要掌握。

一、产品设计

产品设计这个方向上有这么几类具体的技能:

1)需求分析——掌握基本的需求分析方法

【可能涉及(就是举个例子,实际上远不止这么点):表单工具——mikecrm;数据获取工具——百度指数,竞品参考——it桔子,行业报告——艾瑞等】

2)原型设计——画出可实现的产品原型草图

【可能涉及:原型工具——axure,visio,墨刀,epub360,纸笔)

3)逻辑架构——原型后端的产品逻辑

【可能涉及:mindmanager/xmind,office(数据参数文档),visio】

4)沟通协作——和程序员/设计师等沟通

【可能涉及:需求管理工具——trello,网易云协作,teambition等;沟通工具——嘴、邮件,ppt/keynote】

这里面,最重要的就是原型设计,这也是我认为“产品设计”的核心进路。

所以你其他几个可能没做过,可能不精通,但如果你想成为一个合格的全栈pm,你必须要能作出非常好的原型产品。这里的“好”并不是值你做的多么漂亮,多么规整,而是逻辑足够清晰,足够简单,符合用户的需求。

在不断钻研原型设计的方向上,你会很自然的摸到需求分析,逻辑架构和沟通协作或者其他产品能力的门。因为你反复会去想用户最终看到的东西是什么,这个东西好不好,我自己喜欢不喜欢。在你思考“应该给用户什么东西”的时候,其他技能都只是为了更好的完成这一目的而已。你如果不断在“用户要什么”这个领域中精进,那么其他技能和能力也都是水到渠成会被带动提升的。

所以,在产品设计的大方向,顺着原型设计这个进路爬,你最终一定会:

——知道从哪里和怎样弄数据来支持需求分析;

——能把产品最终呈现的基础草图描述出来;

——能梳理清楚产品各个元素之间的逻辑关系和数据流转;

——能把设计的东西让研发/设计师同学帮忙搞上线。

只需要”能“即可,具体工具的使用上可以熟练和精通,你说我确实有能力用keynote做个漂亮到极致的slide也可以,但在结果上,要考虑投入和产出比,毕竟有很多别的事情也等着你去做。(当然比如你开个产品发布大会来无数记者和媒体和用户,那你做个漂亮的东东确实是投入值得的——前提是你找不到专门做slide的大师帮你搞,不然还是交给他们好一点)

二、获取用户

获取用户这个大框架下,有无数的细分岗位。怎么获取用户,有无穷无尽的技能和方法,但在这其中,渠道投放,为什么是最好的核心进路呢?

何为渠道投放,说粗暴点就是花钱买流量。你花点广告费进去,然后只要不是骗子渠道,那么总会有一些流量进来你的产品,至于他们会不会下载或者激活或者注册,那是另一个问题了。你说我做了一个给xx用户群用的产品,现在产品上线了,有什么比直接去xx用户群聚集的地方直接先来两斤流量更快来验证你的产品好不好用呢?或者你的产品可能再细分,有几类用户(无论你是按男女分还是按城市分还是按行业分),那么分头去买1000个流量来看转化漏斗,一定是比你苦哈哈找一些特定的用户来试用更能直观反映陌生用户的观感。

因为你需要的是数据,而直接花钱买量能帮你更快的获得数据,来验证你现在干的事情是要继续接着投入还是砍掉。

一个强大的的渠道投放能力会帮助你花最少的钱,最快的买到你想要的用户行为数据,那么基于此,有以下几个点你是必须要达到的。

1)熟练掌握1-2个主流广告投放平台的操作(百度竞价,新浪粉丝通,腾讯广点通等)及相关的投放经验(pc+移动平台总花费100万rmb大约是一个我认为及格的经验);这个工作能帮你迅速建立起对用户群体量,获取价格,转化率等的认知,很多时候一毛钱不用花光看看买的关键字或者广告位的曝光量就足以印证你的一些想法了。就算公司暂时没有条件投放,我认为完全应该找朋友公司或者自己搞一个户来研究。百度的http://www2.baidu.com和腾讯家的http://e.qq.com和新浪微博的http://tui.weibo.com和淘宝直通车都可以认真研究,其他平台也可以看看,不过在面对流量推广toB服务方面,有一些文艺网站的广告投放后台,我只能用不专业来形容了。

2)独立设计完成landingpage(着陆页,销售页,活动页)的能力,包括设计(这里和产品方向的原型设计能力强相关,每个优秀的原型设计师都可能是一流的着陆页设计师),撰写文案,设置转化路径等;

3)善用工具进行数据分析(转化分析工具:google analytics,百度统计;app监控工具:应用雷达,app annie等);熟练掌握数据统计和分析方法(ab测试,交叉分析,回归分析);

4)能潇洒的和渠道商谈成合适的deal,渠道商包括但不限于:论坛,qq群,pc媒体,app应用商店(如果你的产品是app的话),甚至渠道商也包括你们公司内部的其他部门,这很常见。能以最小代价迅速搞到足以验证的流量,当然你说你有xx网站的关系,免费给你不用花钱买,这当然是最好的了,但不用花钱并不意味着你可以用蹩脚的landingpage和不合理的转化路径去浪费你的流量。

所以我们发现,当你为了更好的建设你的“渠道投放”能力的时候,你慢慢地学会渠道拓展、数据分析、文案写作、合作谈判,活动设计等核心能力,而这些能力是你做新媒体、商务BD、KOL拓展(即邀请意见领袖),软文营销等等其他获取用户的方式的极大助力,也是在获取用户层面上胜任全栈pm的基础。

三、深入用户

很多人说,用户很聪明。

还有人说,用户很蠢。

还有人说,用户很蠢但是你要让他们觉得自己聪明。

还有人说,用户很聪明但是你要把他们当成又懒又蠢得傻瓜。

这些就是盲人摸象方式下最容易得出的简单结论。

用户不是一个抽象泛化的概念,用户也不是统计工具上的数字和kpi,用户是实实在在的个体的集合。我们要接近用户,理解和倾听用户,但是,也不能离他们太近,不然被他们的情绪感染和灼伤是很容易的事情。

收藏

{{favCount}}

个人收藏