产品经理职业生涯规划&每个阶段的弯道超越算法

2018-04-24  本文已影响0人  24ab6a93852e

文章结构:

产品助理的职业定位和职业能力;

产品经理的职业定位和职业能力;

高级产品经理的职业定位和职业能力(包括但不限于某种认知,意识和方法论)。

一、产品助理的职业定位和职业能力

产品助理阶段更多的工作是:产品经理将业务逻辑产品化后,由产品助理将产品需求可视化的过程。这个过程中更多的是接触到各种工具的使用,包括基本的思维导图、流程图、以及原型设计工具,以及试图尝试自己去了解需求,构建完整的业务逻辑闭环,希望自己也可以将需求产品化。

产品助理阶段,通常需要具备包括,但不限于以下几种基本的职业技能:

基本能力,是产品助理阶段应该拥有或应该去获得的基础能力;进阶能力,是产品助理进阶到产品经理的过程中应该拥有或提升的能力,这里不再赘述。

关于产品助理阶段的弯道超越算法

(1)建立自己的知识库/资源库/模板库

产品助理阶段更多是一个知识,技能和经验的积累过程,这个过程中应该建立自己的各种库,就像程序员写代码的时候经常用到的组件一样,拥有自己的组件库好处是可以多次的复用,省时省力。

更重要的是:为后面产品经理阶段能力批量化做准备,产品知识和资源的积累也是一样的道理。

1)知识库

每当自己遇到好的文章就会收藏到相关的文集当做知识储备,方便后续的回溯和内化,当思考新产品策略的时候经常会去翻阅过去积累的内容,往往比去临时找资料更高效便捷。

2)资源库/模板库

小到一个基本的原型控件,大到系统的框架模板和简历模板,都应该定义成自己的标准库,用这些来形成自己产品助理阶段的底层。

(2)拥有自己的规范

之前在《产品设计规范与关乎“秩序和混乱”的人生算法》这篇文章中分享了关于规范的重要性,这里不在赘述,小到一个文件夹的命名,大到产品设计的规范以及思考/思维的规范。

规范是一种美,一种秩序美,它是一种掌控方式,不仅可以掌控你的产品,同样可以掌控你的人生。

(3)按照最高标准要求自己

记得第一次用word写产品说明文档,很担心自己写出来的东西,因为排版难看从而给人留下不专业的印象 , 但是自己的word 水平又不是那么好。

于是产生了这样的思考过程:我想把这个PRD文章写的好看(目的)→ 我要找最好看的排版方式来模仿(方法)→ 什么样的排版方式是最好看的(疑问) → 应该是论文的排版规范吧(解决)。

当然我上面的论据不一定合适,因为我不确定论文排版是不是最好看的,只是觉得它应该是国内要求用word来表达的文本内容里面排版格式要求最高的。

但这不影响我们得出一个这样的道理:做一件事情如果你定义目标是100分,那么你可能会做出来一个80分的作品。如果你的目标是80分,很大可能你做出来的会是一个60分的作品。

(4)关于曲线模型学习法和其实操方法论

之前看过李善友教授在“混沌大学”的《第一性原理》的课程,里面提到过关于归纳法的曲线模型。我把这样的曲线模型用到个人的学习过程中,觉得它也是一种不错的学习方法。

上图曲线可以模拟大多数技能和知识的学习过程,开始的时候我们通过不断的资源和信息获取快速的获得一项知识或技能,进步很快。但是随之也伴随着归纳法不可避免的衰退期——在相同知识或者技能的上花费同样的时间,获得的收益(进步)变得越来越小。

举一个例子:学习axure 基本操作的时候,80%常用的功能在教学视频的20%的课程里面已经讲到了,后面你学的越深,投入同样的时间获得的有效进步是递减的。除非你用演绎法重新为学习axure开设一条学习曲线(第一条曲线:基本操作;第二条曲线:基于Axure的设计规范;第三条:……这是一个不断的精进过程)。

上面的模型给至少给了我们两种选择:

开设新的学习曲线;

 在进入衰退期之前完结这个曲线,开始画其他的知识技能曲线。

之前学习Axure ,我会花一个密集的时间段投入到Axure 的学习过程中,当这个曲线开始下降的时候,我开始学其它的工具,例如:Excel,PPT等。

因为密集的归纳法学习可以快速,高效的获得这些技能,如果你还要做到最好,可以为某个技能开设新维度的曲线。如果你觉得这些只是工具,没必要做到最好,也可以把时间用到开设新知识技能的曲线上。

任何事情我们都应该要求自己做到最好;任何不计时间成本的优秀都不算优秀。希望你用理智去区别二者的不同。

(5)关于思考问题的升维打击算法

刚开始做产品助理的时候,我们接到营销部门的一个需求,要结合我们现有的产品做一个营销活动,带我的导师让我独立负责。

第一次独立负责一个小的产品,接到需求后很迷茫,不知道怎么去分析这个活动并将其产品化。当时直接采用的方式是去百度如何做好这个具体的活动,是站在活动这个具体的维度上去思考具体的解决方法,找来找去依然没有头绪。

这个时候,我试着把这个具体问题的维度升高。我现在面对的是营销部需要产品配合做一个活动,如何做好这个具体的活动是当前问题。或许我遇到的问题不是如何做好这个活动,而是更本质的问题。

当产品经理接到一个新需求时该怎么做?活动需求只是众多需求中的一种,如果我解决了这个高阶的问题,我理应当就能解决这个高阶问题下面的所有问题。

以上就是工作中具体的“升维打击”的例子,试着把你遇到的问题升高一个维度去找答案,一个不行再升级更高的维度。

接下来我们用几张图来回溯下刚才的思考过程:

第一维度思考问题得到的结果

第二维度思考问题,得到的结果

我试着采用第二维度的6W3H设问法,然后会得到一个清晰的思路,活动进行的也很顺利。

如果我直接去百度得到的一个类似XXXXY的活动是怎么做的?这个类似的同维度的活动也许并不适合我目前要解决的问题。

但是如果掌握了比它维度高的问题的解决方案,就可以解决很多比它维度低的问题,这种“升维打击”的思维方式,让我们清楚我们真正遇到的问题是什么,从而获得解决问题的更多途经。

二、产品经理/高级产品经理的职业定位和职业能力

产品助理是将产品可视化,而产品经理或高级产品经理则是将业务逻辑产品化。一句话描述产品经理的核心能力,那就是:产品的宏观掌控能力。

这个核心能力伴随着以下多种能力作为辅助:

普通产品经理和高级产品经理的基本能力模型大致是相同的,但是毕竟多了一个“高级”,所谓的“高级”到底体现在哪里呢?我整理以下几个切入点,试图解释“高级”与“普通”背后的差别。

1. 关于职位的定位

1)对于普通的产品经理,更多的是只负责份内的事情,诸如:产品设计、项目推进、需求分析。所以跟其他部门一样,是独立的职能人员。

2)高级产品经理,一方面是视野和感知;一方面是负责的事物和内容,都触及到了其它部门,形成了以产品为核心驱动的共同协作体。

2. 关于具体的执行

1)扩展性

在接到涉及增添新功能的需求时,普通产品经理一般只会考虑怎么达成当前给到的目标,而不考虑未来需求演进后,能否用当前的体系进行扩展和支撑?导致的问题是当后面有进一步的需求时,有可能需要另作一套新的方案,而且为了兼顾旧版本还得同时维护两套方案。

2)运营的灵活性

接到涉及运营的功能需求时,普通产品经理只考虑表面的信息呈现,不关注数据的读取逻辑,没有思考不同方案对运营实际效用的影响及潜在的变更风险,导致各种喜闻乐见的写死——及动不动就要提交新版。

高级产品经理能够更好地进行换位思考,与利益相关者进一步明确需求及挖掘潜在变化。

3)低实现成本

高级产品经理知道哪些设计点是真正有效的,哪些设计点只是锦上添花甚至花拳绣腿。因此可以抓大放小,在给定的条件下进行合理的妥协。在确保实际效用不变的前提下,优先选择低成本的实现方案。

而普通产品经理难以做到这点的原因有二:

一方面是不能够辨别哪些设计点是有效的;

另一方面则是对技术实现的逻辑缺乏抽象理解,无法感知开发成本。

4)精简的文档

普通产品经理的文档排版糟糕,信息抑或缺漏、抑或冗长、语言表达暧昧,不说工程师需要听到的 “人话”。导致的结果是花费了大量时间撰写文档后,交付出去还是避免不了各种各样的口头沟通与确认。

高级产品经理的文档条目清晰,语言简练,看着就少了一半开发的压力。

5)高效的沟通

普通产品经理和工程师讲半天,也不能 get 到对方的 point,高级产品经理的特征之一就是往往他人只说到一半,就能把他剩下的意思以更清晰简练的语言表达出来,大大缩减了对话的时间。能否做到这一点,实际上也是取决于对技术的理解及换位思考。

6)清晰的项目管理流程

普通产品经理天天都焦头烂额地奔走于各个项目成员之间,并以为自己很勤奋、踏实,被自己感动的同时却没有反思是什么造成了这样的问题?而高级产品经理总是能很快地总结出原因,并与团队达成项目管理流程优化的共识, 对产品的主动思考。

普通产品经理满足于完成被安排的工作,缺乏对产品的主动思考,或者流于创意层面。高级产品经理不断拷问自己近期的关键指标是什么?正确的迭代路径应该是怎样的?有着私人的需求池、创意库或 To Do List。

3. 关于产品经理/高级产品经理阶段的弯道超越算法

1)拥有批量化输出自己能力的能力

就像产品助理阶段掌握如何学习的学习方法,掌握如何思考的思考方式一样。产品经理/高级产品经理,应该拥有批量化输出自己能力的能力。

方法论:产品研发标准化,思考问题模型化。

如何评判一个产品经理/高级产品经理的优秀程度?

当然有很多标准,我的标准是:看他是否能在短时间内培养出一个和他一样优秀的产品经理。这个标准高级的地方是:它不是线性的,二流的产品经理培养不出二流的产品经理的,三流的产品经理只可能培养出四九六的产品经理。

只有一流的产品经理才能培养出一流的产品经理,用时越短,说明他对外输出的能力模型越高阶。

上一篇下一篇

猜你喜欢

热点阅读