导读
由于环境原因,我们接触到的产品经理似乎总是“特别的”,以至于这个问题困扰了许多人。
产品经理到底是什么,我现在做的事情,真的是产品经理要做的事情吗?
产品经理的工作
本文所提及的观念,为我个人的心得分享,不具备标准性质,但具备参考性质。
谈到产品经理的工作,“杂,乱”,是最常听到的定义,包括我本人也在许多场合提到了产品经理的工作内容很杂。
这有两个原因,其一,我们并没有掌握这些看上去杂乱任务背后的共性,其二,我们懒惰,相比长篇大论的陈诉以及费尽心思的沉淀,就只需要一个字概述——"杂"。(我便是后者,惭愧 ,嘿嘿)
用杂乱来定义产品经理的工作内容,就如同用写代码来定义开发, 用画图来定义设计师一样,只是一种自嘲的回应,并不是真正的定义。
我简单的将我个人对这个角色的定义分享一下,并不代表所有的产品经理,但也代表我所认识,所接触过的大部分产品经理,分析样本在100人以上。
工作环节这是一个工作的循环,一共是7个环节,分别是接受任务,分析,设计产品,交付产物,跟进进度,验收发布,结果分析。
我们来简单讲讲每个阶段的工作性质。
接受任务
这里提到的接受任务,原则上是产品经理一系列工作的起点,这些任务便是我们的需求。
正式工作环境里,我们的需求大部分通过任务性质被下发给我们的,这一点即便是产品负责人,产品总监也不例外,区别只是我们的任务不一样而已。
以产品总监为例,我们会接受到要启动某个新产品的任务,而这个任务或者是由企业上层决定,或者是由战略决定,或者是由市场决定。
其本质上更多的是任务,而不是想做什么就做什么。
我们来看看几种典型的任务:
●我们增加一个打赏功能吧
●我们增加一种消息样式
●我们做个转发,怎么样
●现在直播很适合我们公司的方向,你来操刀,设计一个直播系统吧
●积分等级体系能有效的增加用户的活性,来一发
●我们有教育资源,想找一位产品经理来做一款教育类app
当然,除了上级的直接要求以外,我们通过对市场,对用户的了解,也能发现一些问题,发现一些机会,而这部分内容,也同样是任务性质的,只是我们自己扮演者任务分配的角色。
冬日的某天,小雪,A和B两人相约去某地开会,准备打个出租车前往,两人在雪地等了许久,都没有出租车经过。
此时,A抱怨道,要是有一款APP ,能让我点一下就能叫到车就太好了(任务下发)。
B思考了一下,觉得这是一个很好的想法,于是回应道,咱们自己做一个(任务接受)。
于是 ,有了 UBER。
于我个人而言,我其实很排斥“想法”,更多的是喜欢以“任务”的概念来驱动项目,想法过于偶然了,具备十足的不确定性,同时又过于廉价,谁没有几个想法呢?而任务却不一样,具备一定要达成的潜意识,我们接受任务或者下发任务时,都持有必须完成的心理。
分析
分析是一个大类的环节,这样的称呼大概会让你感到迷惑,我们先来看看分析阶段都包含了哪些事情。
市场调研,用户调研,需求调研,技术调研,数据分析,kano模型,马斯洛需求层次,用户画像等等。
在分析阶段,我们运用各种各样的方法来完成对任务的分析,是的,我们所知道的许多看似很高端的名词,大概都是在分析阶段的某种方法论。
产品经理是个强思考的角色,这里的强思考主要就体现在分析阶段。
分析阶段在任务接受之后,我们分析的目的是如何去达成任务。
分析的目的 在于寻找达成目的的方法,而不是去寻找拒绝任务的理由。
很多时候,我们在分析时会有错误的思路,我们会下意识的去寻找能够帮我们拒绝执行任务的理由,这是一种潜意识,是我们需要克服的困难。
我深刻的知晓许多任务,在我们接受时,就已经存在不可执行性,从一开始就注定了失败的,但很遗憾,我们对此无能为力。
就像是士兵一样,服从是军人的天职,达成任务便是我们产品经理的天职,尽管他多么的离谱。
要知道,许多伟大的事情,都是在不可能完成的情况下被完成了。
产品经理接受的任务,极具挑战性质,80%以上的任务都是属于不可能完成的任务。
我们的角色,本就是将不可能变为可能,将可能变为现实。
所以,你还在排斥任务吗?或者你是否做好心理准备, 迎接一个又一个的不可能完成的任务。
再来说到具体的各种方法论,如同我们刚才列举的许多方法一样,其目的都是为了帮助我们分析。
我们已然清楚分析的目的是什么了,那如何分析便是这些方法论发挥作用的时候了。
这些方法论并不神秘,只是包装过于华丽了,我们简单列举几种分析方法吧。
●市场调研
我们在获取需求时,最先做的就是市场调研,简单的来讲,就是去分析任务所对应的目标市场,具备什么样的特点,需要什么样的服务。
需要注意的是,此处调研对象是“市场”,比如出行市场,IT市场。
●用户调研
任何一个产品都是被某人所使用的,我们借助市场调研明确自己要做什么服务以后,就需要做用户调研了。
用户调研的落脚点在于某人,正确的讲,应该是某类性的群体。
●技术调研
技术调研是在有一定想法以后,我们找上开发人员,简单评估一下技术的实现成本,如果某个idea的实现成本过高,我们可能就要重新想想方案了,许多产品经理在设计产品时,会忽略技术实现难度及成本,这是不可取的。
在应用层面,大部分的需求都是不需要强行攻关的,比如我们要实现支付功能,但并不是一定要自己开发一套支付系统以及安全系统,直接接入第三方就好啦。
当然资金量很大时,我们的收益足够平衡我们的成本时,就很有必要自己开发了。
●kano模型
kano模型是作为划分需求优先级的方法被创造出来的。
需求总是很多的,但前人经过研究,提取出了需求的共性,并总结成了需求的五个类型。
使用这个方法,我们可以很轻易的判断某个需求属于何种类型,再借助该类型需求的价值以及效应,最终来判断出某个需求的优先级和重要性。
设计产品
产品是被精心设计出来的,这是我所遵循的产品观念,在我体验一款新产品时,我会尝试站在对方的角色,来思考。
如果是我来做,我会如何设计呢?
当我们结束了分析阶段后,我们会根据自己掌握的信息,根据自己分析所总结出来的信息,来设计产品。
我们所使用的每一个参数,都是精心设计的,不仅仅是参数,一句提示文案,也是可以被精心设计的。
只是我发现许多产品落地很差,这点在设计上可以充分体现出来。
与分析阶段相同,设计产品也有诸多的方法,并且经常被我们使用到,只是很多时候,我们并不曾注意到。
设计产品的方法:结构设计, 业务设计, 流程设计, 原型设计,情感设计,MVP设计原理等。
产品经理行业,由于外界盛传的0门槛或者门槛低,导致许多朋友尚未准备好,就进入到这个行业,再加上目前尚未出现通用的技能体系,在实际工作中,许多leader ,许多产品老人,都尚未将自己的经验沉淀,最终的结果,是比兴奋更为巨大的迷茫。
迷茫:
从心底里想要学习,并认真的热爱这个行业,但却连自己应该学什么,都感到疑惑。
看不清当下,也看不清未来。
自己现在能力到底怎么样算好还是算差,又或者是一般。
下一步,我应该学些什么,如何才能变得更好?
其实没有那么复杂,这个行业远比我们想象的还要接近事物的本质,你所欠缺的只是应用的技能,以及对技能的熟练度。
在产品设计阶段,我们的差距更多的体现在思考面积的强弱上,我们掌握的设计方法越多,便越能设计出好的产品。
最合适的就是最好的。
在创业团队里,产品经理可能不会决定项目的成功,但却极大的决定了项目的死亡。
若产品经理没有掌握MVP设计原理,以及产品结构设计,极有可能在1.0版本花费太多的时间,并给未来的产品迭代遗留许多问题。
这将极大的增加创业团队的时间负担,创业而言,每一个小时都是极为珍贵的资源,可以想象,浪费一个月等同于将整个团队置于死亡边缘。
而一次版本迭代,若牵扯到了结构重构,几乎是必然超过一个月的时间耗损的。
在不同的时间,不同的阶段,不同的环境里,我们需要使用不同的设计方法,这就需要我们不断的充实自己,不断的学习。
设计方法之间是不存在正确或者错误的, 这完全取决于我们是否在合适的地方,用了合适的方法。
因此,我们无需因为自己设计出来的产品被排斥,被冷淡,而动摇自身的信念,也无需为了失败而感到沮丧。
我们所欠缺的,其实只是方法,那便学习方法就好了,不需要漫无目的的学习。
这些方法并不在已有的产品相关书籍里,而是在于传统行业的金科定律里,相对历史悠久的传统行业,互联网作为一个行业而言,显得无比稚嫩。
现在大家所认识的kano模型,金字塔原理,马斯洛需求层次,没有任何一个方法论是属于这个行业原创的,均是来自于对前人知识的学习以及再应用。
要知道,早在互联网之前,人们就已经设计出了许多精美的”产品“,我们其实早已掌握了产品设计的”精髓“,我们也早已接触了数之不尽的”产品“。
一段文字,一本书,一部电影,一场真人游戏,乃至我们所使用的碗筷,衣物,都是被作为”产品“被设计出来的。
因此, 你,无需感到畏惧,也无需感到迷茫。
未完待续。。。
已经有3500多字了,现在还有4个环节没有写,分别是交付产物,跟进进度,验收发布,结果分析全部写完大概接近万字长文了吧。
考虑到大家的阅读时间不宜过长,决定将这篇文章分成两篇来写。
网友评论