3.1 产品经理入门指南
枯叶
正如所有的行业一样,产品经理也会经历三个阶段的成长,这将会是我们从入门到独挡一面的里程终点,同时也是从专业角色上升至管理角色的重要起点。
产品助理→产品经理→产品负责人
2018年,产品经理的竞争将会越来越激烈,这个行业已经经历了十多年的发展,作为行业的从业人员,我们需要更专业化的技能认知,更清晰的阶段认知。
一、产品经理不是天生的
请你忽略网络中,关于产品经理的片面观念,这其中包括有想法就能做产品经理等等。
“我是否适合做产品经理”“我是否不适合做产品经理”,这两个问题将会是产品入门的拦路虎,会给我们产生很大的伤害,尤其表现在我们的信念上,忽略他们吧。
10年前,我们无法准确定义产品经理是做什么的,10年后,已经有一些模糊的概念了;再过10年,也许我们会引来更清晰的认知,甚至开设大学课程和专业。
Tips:产品经理是一个专业角色,天赋有用,但却不是最重要的;实际上,我尚未遇到将自己的成功或失败归根于天赋的产品经理。
我们没有办法尝试告诉一位尚未接触编程语言的朋友,“很遗憾,你不适合做程序员,”又或者说:“天啦,你真是最有潜力的程序员,”毕竟,他尚未经过学习。
作为产品经理也是一样的:即使已经在产品经理的岗位上,没有经历过相应的学习,那你的过失,更多的是由于“知识”的不足,而不是“天赋”不足。
与程序员不一样的地方在于:产品经理目前所处的环境并不像编程行业那么成熟,只是近年才出现产品经理的分享浪潮;而遗憾的是,我们必须经历更长的时间,才能将零散的知识整理成体系。
这给现在的我们提供了更高的要求:忘记“挫败感”吧,因为这是我们必须经受的考验。
二、产品助理
本文提到的角色均为产品经理的成长阶段,不是具体的岗位。其实有很多朋友在产品经理的岗位上,做着产品助理的事情。
作为我们迈入这个行业的第一个阶段,并没有大家所认知的那般困难。
网络中盛传的“低门槛”与相应的各种“技能分享”,共同组成了一个“悖论”,这是一个思维误区。我们需要清醒的认知到:作为产品助理而言,应该做什么。
大部分的技能是在产品助理往上成长时,所需要补充的知识面积,而非成为产品助理的硬性要求。在这样一个特殊阶段,最核心的目标是“打基础”,而不是“拍脑袋”。
1.职责
助理的主要职责有三个:撰写需求文档,设计原型文件,收集资料。在许多团队里,真正能起到推动项目效率的,是产品助理,就像“齿轮”一样,转动的越快,整体效率越高,质量越高。
Tips:效率是一个变量名词,这就表示产品助理的职责存在可量化的系数,具备大小和差距。
让我感到非常遗憾的事情是:大多数产品助理将自己定义成了“培训生”,理所应当地接受“任务少”“不被重视”等现象。
产品助理是一个正规的职场角色,即便是工作环境并没有为这个角色量身定制工作内容,我们也要有自己的觉悟。
依照目前互联网团队的成熟及协作方式而言,优秀的产品助理足以提高整个项目组40%的工作效率。
这并不是一个随意提及的比例,实际上在我亲自参与的项目里,这个比例会提高到60%。根本原因在于这样的情况:
Tips:由于时间,精力分配的问题,产品经理和产品负责人会将精力更多的投入到思考和底层设计里,在二八原则里,80%的产品内容,会由助理分担完成。
偶尔,我也会做一些产品入门培训,而且会重点培训产品助理;毕竟我们所处的环境不一样了,现在随便找个人,都能对互联网说一二三;于是,我更关心大家如何做。
这是我个人的一个观点:没有认真经历助理环节的产品经理们,也许会是未来被淘汰的第一批产品经理。
2.成长:用需求文档建立功能认知
成长取决于我们所做的事情,以及做的数量和频率。
我们已经清楚产品助理的三个主要职责,相应地,我们在做这三件事情时,就会收获成长。
比如:当用户或者客户告诉我们一个“需要”时,我们总不能扮演传话筒的角色,将“需要”传达给开发——我们在这个过程中承担了翻译的任务。
案例:
●用户:我想上传我自己拍摄的照片,这样别人就更容易关注到我(用户需要)
●产品需求:图片处理,图片上传,相册,图片列表,图片详情,评论,删除,举报,点赞。
这需要我们自身对功能有一定的认知,能够将一些口语化的“需要”翻译成功能化的“需求”。
需求文档在我们成长过程中,会持续地将我们曾经或者正在实现的功能变成文字记忆,储备在我们的头脑和意识态里。
Tips:最好的存储办法是设计一个自己的“功能需求库”,不仅仅是工作中的需求,闲暇时间也可以将我们平时使用的产品进行分析,并封存到我们的“功能需求库”里。这些都是未来我们做某产品时,宝贵的材料。也是我们职业发展的一条快车道。
你能想象100个功能认知与1000个功能认知的差距吗?这大概就是产品新人和产品老司机的差异。
3.成长:用原型图建立设计认知
原型图的重点并不在于输出的图形结果,而在于设计的过程。
我不太建议大家去模仿其他产品绘制原型,实际上,我禁止我的学生模仿其他产品绘制原型。
原型图是一种表达介质,可以用axure、sketch甚至手绘都可以,这非常的简单,以至于在模仿的过程中,没有任何价值产生。
在设计原型图时,我们需要经历这样几个步骤:
●构造画板(有边间的空间)
●优先绘制稳定度较高的板块(比如标题栏,底部菜单栏)
●剩余空间再进行变化度较高的板块设计(空间划分)
●往往一个板块有非常多的参数,我们需要判断参数的价值(参数选择)
案例:
实际上,这个过程对我影响非常大,你知道我现在写文章的顺序吗?
1.约定字数,通常在2500字左右(有边界的空间)
2.先确定“导读”和“总结”所需要的字数(标题栏,底部菜单栏)
3.设计文章内容的结构(空间划分)
4.设计小标题(参数选择)
Tips:作为产品而言,空间并没有那么庞大,只是我们习惯性的将其视为无限可能,一个页面所能承载的内容非常的有限。能否驾驭这个小小的空间,取决于设计原型图的过程,给我们带来的成长。
我们必然会在这个过程中学会空间感,布局,产品模块,还有并不是所有参数都是一样的效用——也不是参数越多越好,这会让我们学会选择,初步接触产品经理的“判断意识”。
4.成长:收集资料可以触碰到产品的精髓
我曾多次对朋友提及我所理解的产品的精髓,甚至也是创业者的精髓。
“信息提取及大量信息加工的能力”
产品的设计并不是空穴来风的,而是信息处理后的一种结果;越往后面发展,我们所需要捕捉的信息量就越大,对我们并发信息处理的能力要求就越高。
就产品负责人而言,需要承担产品舵手的职责,同时也要肩负产品生死的考验,我们的任何一个决策,都有可能成为产品死亡的诱因——当然,也极有可能成为产品提升的决定性因素。
毫无疑问,现在的环境,产品已经泛滥成灾了,这表示“撞大运”的机会越来越少,更多的是凭借精打细算的思考,以及媲美计算机运算能力的预测。
阿基米德曾说:“给我一个支点,我能撬起地球”。对于产品经理而言,这句话的含义等同于“给我足够的信息,我就能计算出下一个风口,做出一款爆款产品”。
实际上,这样的描述并没有错误。可如何获取足够的信息,以及如何对大量信息进行并发处理是对我们能力的考验。
助理阶段在收集资料时,便是在逐渐建立起“找材料”的习惯,而对资料的汇总汇报的过程,便是在建立“材料处理”的意识。
Tips:这并不是“调研”——尽管未来会发展成“调研”,但目前而言,我们要做的是极尽我们所能,将能找的方法,能找的渠道都尝试一遍,并且不断的尝试新方法,新渠道去获得指定材料。
同时,不要做资料的搬运工,逐渐尝试对这些资料进行处理——要知道,你的leader或者你的导师,可能会使用和你的相同的材料进行分析;他分析出来的情报,便是你需要吸收的知识。
二、产品经理
相对于产品助理而言,较为成熟的功能库,以及熟练的撰写文档和设计原型的技巧,是产品经理们的典型特征。
功能库便是在助理阶段积累下来的认知,这是我们的财富,而且他还会一直随着我们的经验阅历的增加而变得更丰富。
除了这些典型特征,还会出现更多的技能进入到我们的工作中。比如对时间的预估,对进度的把控。
估时并不是研发独有的能力,实际上,在成熟的产品经理里,不乏对时间有精确控制力的朋友。原因在于:每一次和研发沟通的过程中,每一次的迭代版本或者项目中,我们都能收集到研发反馈的信息。
只要对这些信息敏感,便不难对功能实现成本做预测,这就好比我们做了很多次注册登录,再次做的时候,就能评估出研发时间和风险点,而不需要再询问研发同事。
1.职责
这个阶段的产品经理有三个主要职责:定义每个页面存在的意义,追求子目标,设计底层需求。我们在设计产品时所绘制的任何一个页面原型,都有其存在的意义,而且这些意义是不相同的。
Tips:设计方法本身没有问题,任何一种“方法”都曾经或者正在被其他人所使用;然而,相同的思路,放在不同的地方就产生了“对”和“错”的概念。
比如:
●列表页存在的意义是更高的跳转率,在这层含义之下,我们需要寻找更容易诱导用户点击进入资讯详情的方法。
●主页存在的意义是更高的关注率,我们希望用户通过阅读一个人的主页,更容易产生关注他、认识他的冲动,这决定了如何设计这个主页,也决定了通过何种维度来判断主页设计的是否“正确”。
●还会有一些页面,在不同的产品环境下遵从于不同的意义,就像我们的文章详情页,某些产品会更多的提高用户分享率,有些产品则会提倡更多的评论率。
这就需要负责该板块的产品经理,明确定义一个页面存在的意义,并在设计过程中遵从该意义。
这也滋生了产品经理的第二个职责:追寻子目标。
并不是所有功能都会为产品的新增,用户的活跃买单,个人资料就是很好的案例。我们不能说新增低,用户活跃低是因为产品的个人资料做的不好,但也不能认为个人资料页没有影响。
每一个页面都会有自身的数据衡量维度,跳转率是我们常见的一个数据指标,除此之外,还有停留时间,完成率。
搜索追寻的数据指标又与个人资料不同。
我发现很多产品经理,如果不独立负责一个产品,就变得不知道该做什么,这是错误的。即使不负责一个独立产品,我们也会有各自负责的某一个板块,也有我们这个板块存在的意义以及他所应该追求的子目标。
Tips:底层需求是指不可视的需求,我们在助理阶段积累了大量的功能库,但很多都是可以被看见的,也就是由前端驱动的功能。
一个产品的强壮度,往往并不在于前端功能,而在于后端功能和底层功能;需要我们了解数据流动,以及每一个环节对应的细化需求点。
随着我们对产品的掌握力度,我们的需求挖掘对象会逐渐的从左向右转移,对于产品经理而言,后端对应的底层需求是需要我们操刀完成的,原因在于这部分需求并不能通过我们的视觉来分析和拆解。
Tips:常见的底层需求包括推荐系统的推荐规则,匹配逻辑,大数据的应用,还有我们的搜索逻辑,微信的推荐通讯录好友的功能,你知道他是通过哪些需求点实现的吗?
2.成长
在产品经理阶段,我们会开始为数据负责并且通过对某个模块的意义赋予,形成个人的价值观——这是非常重要的一个里程碑,我们终将会进入产品经理的下一个阶段,也终将会为一个产品独立负责。
届时,我们将赋予其意义的,不是某个模块,而是一个产品存在的意义——为用户创造的价值;我们要分析的数据,也不再是某个页面的子目标,而是更深一层的全局分析以及价值分析。
三、产品负责人
请允许我简要描述这部分的内容,这个阶段实际上是一个转折点,也是一个转型阶段;除了专业能力的增加以外,我们还需要扩充团队管理,项目管理相应的技能。
产品价值观、产品结构、团队管理,是产品负责人必备的三个基础能力。
作为一款产品的实际负责人,我们需要承担起舵手的责任,我们需要更多时间来思考:这款产品究竟应该为用户创造何种价值,提供何种服务。
Tips:这是很艰难的减法过程,我们面临太多的可能,太多的诱惑,似乎这样做可以,那样做也可以。
再也没有其他人能帮你做这个决定了,而且我们还要帮更多的人来做这个决定。
十个字的slogan非常短,往往需要一个月乃至更长的时间去思考,我们很多的想法,很多的概念都会在这段时间里增加,减少,融合,最终沉淀为短短的一句话,并赋予给这款产品,从此,这句话就成了某产品的价值观。
产品没有结束和完成的概念,除非这款产品进入了死亡阶段。
QQ音乐迭代了11年,目前任然在迭代过程中。长时间的迭代,堆积的功能就会成为产品的负担,就如同人们身体的病痛,许多都是积累而来。