产品经理究竟是干什么的?

产品经理究竟是干什么的?

时间:2020-02-06 07:25 作者:admin 点击:
阅读模式 释放双眼,带上耳机,听听看~! 00:00 00:00

上次回家遇到同学,说起以前他校招给我投产品经理的简历被我刷掉的事情。我于是便问他:你究竟为什么想要做产品?我那个同学回答我: 我学长告诉我,产品经理入门简单,啥都不会就可以干,而且工资很高啊!

我忍不住骂了句: 我日啊!

今天又在知乎上看到一个问题:“产品经理究竟是干嘛的?“,看到一个个自说自话的回答实在是受不了,就想写一下,我所理解的产品经理的主要工作究竟是什么。

简单来说,产品经理主要的工作就是:规划、设计产品,对产品研发过程的控制,最终把产品卖出去的一个过程。而产品经理,基于服务的对象不同,主要分为两种:to b (针对企业)和to c(针对用户),虽然两者的侧重点有些不同,但是他们基本的工作方式还是很类似的。

初入门的产品总会有这样误区,就是总觉得产品经理的主要工作是绘制界面原型。曾经面试过一个应聘产品助理的妹子,我在考验她逻辑思维能力的时候,她对我的问题表示出了不屑,不停的跟我强调自己会使用各种绘图和设计软件。其实,学习能力,思维的逻辑性,比单纯的使用一个软件的技能要更重要。而且,产品的原型的设计只是产品经理众多工作输出偏向于后期的一种。

在此之前,是需要进行非常多准备工作的,最后到了原型阶段,只要表达出想要表达的意思,设计和研发能看懂就可。但是如果前期准备不到位,产品的设计有问题,那么,原型做的再好看,屁用都没有。因为,根本没有人会用它。

具体来说,按照流程先后来分,产品经理的工作主要包括如下几个方面:

产品定义 需求调研 业务建模 产品验收 线上运营

注意:这些工作过程并不是每个产品都必须有的,仅仅是做完一个产品的常规过程,有些过程很多时候是被略过的,仅此而已。

以下我来分条说明一下。

产品定义

简单来说,产品定义的过程,就是明确这个产品是做什么的一个过程。这个过程需要明确如下几个要素:

1、产品业务的边界:即这个产品要解决什么问题?这个产品不解决什么问题?

一个个互联网产品可以看做是一系列事情的解决方案的集合,而不管解决什么问题,都得付出资源。无论是任何公司,哪怕是BAT,资源永远都是不够的,所以解决方案还需要聚焦到一两个点去展开,才能尽快建立起自己的领先优势。比如早期的陌陌,就专注于陌生人社交这个问题,最初的小米专注于解决穷人如何拥有一款智能机的问题,最初的百度也就解决如何有效的搜索到自己想要信息的问题。你永远无法用一个产品解决所有问题。就像你永远无法用一个答案答对所有题目一样。这个时候,产品业务的边界就非常重要,定位一定要非常清晰,绝对不能模糊。

2、使用价值:这个产品使用的价值在哪?别人为什么要用你的产品?

我觉得美国著名的电影《教父》里面的维多·克里昂是最成功的产品经理之一,因为他曾经说过这样一句话: I m gonna make him an offer he can t refuse (我将给他一个无法他无法拒绝的理由),然后他做到了。我们可能没有教父那么牛,但是我们可以做的是:我们究竟能不能,敢不敢说出这句话?

这个时候,我们就要思考,用户无法拒绝你的理由究竟是什么?这个问题说的更直白点就是:别人为什么要用你的产品?你的产品和别人的产品有什么区别?你的产品能不能更好的比别人解决用户的问题?

3、商业模式:这个产品究竟应该怎么挣钱?

对于一个公司来说,赚钱就是它的商业伦理,产品是为公司服务的,如果赚不到钱,就是违背其商业伦理。而一个产品如果既赚不到钱又没有用户,那么这个产品就是失败的,它就是一坨屎。即使再用情怀,用理想来包装自己,包装的再华丽,也只是一坨华丽的屎。

商业模式其实可以大体可以分为两种:赚钱的和不赚钱的(或者可以说是以后赚钱的)之所以说商业模式分为赚钱和不赚钱两种,是因为互联网行业的特殊情况来定的(即商业模式不清晰的情况下,只要有大量用户,迟早会有办法挣到钱)所以往往也能够吸引大量用户的产品也能得到资本市场的青睐,比如说美团。

科幻小说《基地》里面讲的是,一代宗师哈里·谢顿对未来三万年的预测和推演,并通过自己的推演来重新建立人类文明的故事。虽然做不到像哈里·谢顿那样,商业模式能否盈利,的确是需要进行市场调研和沙盘推演的。因为往往市场的情况就决定了,一开始,这个产品未来的发展和走向。我们通过市场主要影响因素的估算,算出分几个阶段做这个产品,制定出产品的RoadMap(关键节点),以及多长时间能够盈利。最后产出的就是要给VC(风险投资者)看的BP(商业计划书)。

但市场情况风云突变,很少可以按照计划来执行,写BP主要是还是为了融资和沙盘推演看这件事情究竟是否可行。

商业模式的产品定义这一块得考虑相当多的内容,不光得深入到行业,还得深入了解经济趋势,政策风险等,才能较为准确的对产品有所了解。而商业模式在未得到验证的情况下,是不能进行快速批量投入的。得先小批量验证,验证无误,解决了批量推广的瓶颈以后,然后再花大力气去推。

所以我们总是说创新是一件很难的事情,更好的一种方式是直接抄袭然后修改。COC (copy to china)就是这样,在国外得到验证过的商业模式,直接抄到国内来。这些成功的例子有很多啦,比如大家痛斥的腾讯,又比如我前老板王兴,我称之为火影忍者卡卡西(复制忍术),虽然王兴几乎所有的创业项目都是照搬国外现成商业模式的,但他都快成大佬了,充分说明这种流氓式抄袭过来修改的方式还是挺管用的(虽然很没节操)。

需求调研

思维的过程是这样:思考问题得由大到小,由浅入深。解决了产品定义问题以后,我们就需要解决另外一个问题,我怎么验证自己的想法是正确的?我该怎么样才能知道真正的用户是怎么想的?这个过程又分为如下的几个方法:

问卷调查

总的来说,问卷调查会有很多问题,比如如何去获得有效问卷?如何去找到你的目标用户?也是一个非常有趣的讨论话题。 关于问卷调查,我曾经简单的写过一篇相关的文章,大家可以去看看,这里就不多阐述了。问卷调查的好处在于,可以获得大量用户反馈的信息,获取信息的效率更高,虽然准确度可能不太好控制。

面谈

问卷调查以后,面谈可以作为问卷调查的一种补充。面谈的好处是你可以更好的了解到用户在想什么,主要就是去了解用户的痛点,然后对于这个痛点他是如何解决的?但为了避免对用户的面谈结果进行影响,其实还是有一些技巧可言的,和问卷调查有点类似,简单的总结一下:

不要使用肯定或者否定式提问 尽量使用用户能够接收的方式来询问 尽量让用户陈述事实,而不是观点 沉浸在用户环境内

亲身经历一个事情带来的情绪记忆要比看着或听说别人这个事件所感受到的强烈得多,形成感受的反射也远远要更持久。而且,比较传统的用户,很多时候,并不会对你说实话。去到用户的环境里,不但可以切身体会到用户的感受,而且还能从侧面去观察这个行业,总之,好处很多。所以我做之前影视项目的时候,就去片场呆了将近一个月的时间,吃剧组饭,也客串了几把演员,我也因此弄明白了影视行业的潜规则和一些行业消息,发现很多用户的痛点是没法说,或者不愿意说出来的。

竞品的分析

竞品分析可以更好的让你了解到这个行业,这个产品的市场,别人在做什么。具体如何去做,网上资料一大堆,都是可以查到的,做这种东西最重要的不是格式,而是从产品设计的角度出发,去探索每个产品设计背后的原因,请记住一句话:『别的产品经理不是傻瓜』 产品经理郝原在知乎上分享过自己在做凤凰新闻客户端的经验,他做凤凰客户端的时候,参考了reddit,豌豆荚,豆瓣小组,网易,贴吧,微社区,抽屉等各个平台的UGC产品的微社区功能,很辛苦的做了一个微社区,怎么推都没有推起来,最终失败了。原因是因为他没有搞懂别人做微社区的原因的情况下简单一味的模仿,导致了产品的失败,最后他总结到:

看别人产品,不应该只看对方体验,而是应该看他的根,他的道理。他的公式是什么,这个公式因何成立?如果做同样的事情,对你的项目是否成立?

用户故事的编撰

以上的步骤做完了,就是去编写用户故事和使用场景了。用户故事,指的是从用户的角度去描述他完成业务过程的操作,它包含三个要素:

角色(谁) 活动(做什么) 商业价值(目标是?)

拿QQ里面的一个常用的故事来举例子,比如给同事传文件就可以写成这样:我(谁),想(找同事传word文件)以便于(协同写作)。当然,用户故事是不止一个的,一个产品会有很多的用户故事,当用户故事收集完成以后,我们就可以开始做产品的下一步的工作:业务建模

业务建模

以上,基本的准备工作都已经做完,这就进入到产品设计的环节了。这个过程,是很多人看得到的产品的显性工作,大多数人都会把时间放到这个上面。虽然说这个过程非常重要,但是,如果前面的工作没有做好,这一步,就是在生产垃圾。这一过程主要分五个阶段:

业务流程图的绘制

一个产品的设计,有显性的地方也有隐性的地方。比如说在京东上,你能看到的,是商品的买卖这是显性的地方。你看不到的,比如说网站客服的支撑体系,物流的支撑体系,公司的财务体系等……都是隐性的部分,业务就好比一块冰山,线上业务是冰山上展露的头。

这个时候,我们就需要根据用户故事来绘制业务流程图了。基本上就是用泳道图的方式把业务串起来,形成一个完整业务的过程。因为线上产品的制作,本质上,还是把线下的过程给搬到线上进行放大和优化的过程。

但我们在设计业务过程的时候,就不能一叶障目,只绘制显性的业务,还是得把整个业务过程给拉取出来,先抽取主要的过程,再加上分支的过程。还拿电商举例,完整的业务过程应该是:商品的产生、商品的库存,商品的在线营销、商品的配送、商品的售后。区分一下,哪些业务是在线上完成,哪些业务是在线下完成的。区分是在线上还是线下完成,一方面要考虑本来业务的属性,比如配送,这个业务的属性决定了它主要业务过程在线下完成。另外一方面还是取决于开发的成本和优先级。比如如果系统内涉及了交易就肯定有结算的功能,但是如果交易又不是主要用户的使用场景而又赶着上线的时候,就可以让这个环节放到线下去结算(当然不是一个好选择,只是举个例子)。因为做产品设计,本质上还是一个投入产出比的游戏。

用例图的绘制

根据上面所说的线上业务流程图,我们会做出一个比用户故事更简单的图。这个图非常简单,你只需要绘制一个个角色,把这些个角色要实现的功能给列举出来即可。这样可以让角色和功能的展现的更清晰,避免功能实现文档出现遗漏或者重复的情况

功能节点的绘制

对用例内的角色和功能合并以后,我们就能得出这个系统需要完成哪些功能,以及哪些功能是主要功能的判断,这个时候我们就可以拉出一个包含着有功能优先级内容的表格了。关于优先级的判定主要考虑如下几点

基本的功能必须要覆盖 主要的场景必须要覆盖 次要的场景次要覆盖 用户价值越高就越需要关注