首页 > 文章内容

看山还是山 | 产品经理成长必经的三个阶段

每个产品经理都会经历这几个阶段,只是快慢不同,而决定快慢的因素首要的就是我们自己的认知,尽早意识和明确自己的边界,才能有针对性地去不断提升自己,尽早突破到下一级。

简单说说自己的经历:毕业后在传统公司接触互联网业务;然后为追求专业化进步,去了大厂作为非正式员工开始系统化规范化入行产品设计;而后为追求独当一面,去了创业公司负责整条产品线的功能设计;如今为能够从0到1搭建产品框架在独角兽公司升级打怪。这一路的产品经历,有自己的不断摸索,也有所遇导师的不吝指导,可以说是相当草根了。

这几年在工作中也遇到过不少新人或同辈,发现无论是创业公司野蛮生产的草根产品,还是毕业就在大厂接受系统培训的正规军产品,大家的成长经历居然有很多相似。因此希望总结出来,算是给自己复盘,也给后辈同行们一些借鉴,不当之处还望大家可以积极在评论区沟通,一起成长。

先抛出一个需求案例,例如要做一个活动管理需求(非一次性活动,可模块化上线发布运营活动),可能需要考虑:

(1)运营后台要满足活动运营以及市场的需求

(2)前端要引导用户积极参与活动

以案例切入,自己的产品历程大概经历了以下几个阶段:

一、看山是山:眼见为实,纠结表层

由于初级产品经理都是从一个个的功能点做起,特别是对于已经成熟的产品而言,由于业务的复杂性,新人上手需要慢慢熟悉。这时候鉴于经验的有限,以及信息的不对称性(对已有逻辑的熟悉度不够),看问题的深度往往不够,就导致做前端的兼顾不了后台,做后台的无法考虑到前端,大家只关注自己的那部分功能需求。

以案例为例,可能前端产品更多的精力放在表现层,活动入口的交互够不够酷炫,活动页面的UI好不好看banner吸不吸引人。后台产品更多的精力放在范围层,最大限度地满足业务方的需求点,能支持的活动类型要多,奖励的配置要更自由化等等。如果各自都只考虑自己的点,可能会造成一开始的需求量会很大,而且前后台数据交互存在很多问题。

因此,前后台业务无法串联,只关注自己这部分需求的表层功能可能是这个阶段产品经理面对的最大问题。当然,这个问题也有客观因素,因为只分配给了新人某块功能需求,不过相信这是大部分初级产品的工作内容常态。因此想要获得更大的进步,就得多听、多看、多思考与自己负责的功能点有关的业务需求逻辑,让自己先形成线的产品思维。

移动互联网时代,很多公司招APP产品经理,实际上只是体验产品经理或者界面产品经理,关注点可能和交互设计师差不多,然而不了解后台的APP产品经理注定无法搭建成一个APP。即使是后台产品经理,也依然得往深入里考虑到更下层库表的结构,以及更上层用户使用界面的布局,如此才能形成大局观,从解决点的问题成长为可以解决线的问题,甚至是面的问题。

二、看山不是山:追求大全,死磕分枝

串起了前后台的业务逻辑后,会发现自己的眼界突然变宽了,至少做需求时不会茫然了,因为已经对需求的实现了熟于心。但同时,要考虑的点也会变多,毕竟后台要考虑满足业务方的需求,前端要考虑到用户场景需求,业务的复杂性意味着用户可能面对各种情况。

这个阶段的产品经理为实现业务闭环,就会追求功能的全面,希望把每个业务分枝都做得尽善尽美,满足用户所有场景下的需求。

由上面的需求案例可以看出,这已经不是一个功能点的需求,而是一个模块的需求,这也是这个阶段产品经理的价值产出。一般来说,模块需求的用户场景会比较复杂,因此若想解决所有环节用户可能遇到的问题,就得不断完善业务逻辑。

这时候感觉就像是在水里按瓢,此起彼浮,为追求逻辑的严密性和业务的闭环,这阶段的产品会不断增加新的需求去补漏,从而造成开发和测试苦不堪言。但大家估计也有苦说不出,因为产品经理一般会说:你想下,这的确是用户在某种场景下会遇到的问题,所以必须解决哈~

长此以往,模块的业务逻辑会越来越复杂,功能点耦合性也会比较强,会造成后续的拓展比较麻烦,有时候有些继任者不得不重构甚至是重做。我想这是每个进入大公司,接手前辈们的需求时都会遇到的一个问题,毕竟大部分产品经理都追求完美,想要逻辑自洽,给用户完整和绝美的体验流程。

因此,这个阶段的产品经理太过于追求业务场景闭环,不自觉地就把需求做复杂了,造成产品功能或者业务逻辑的冗余,但产生的实际价值却是有限。做加法容易,怎么做减法是需要在这个阶段着重培养的意识。

三、看山还是山:关注核心,有舍有得

二八原则想必是很多人都熟悉的,用在做需求上同样如此,有时候百分之二十核心功能的优秀体验就能获得百分之八十用户的芳心。因此关注核心,有舍有得是这个阶段产品经理的最大特征之一。

产品经理的核心价值在于能够持续输出高确定性的决策,要做到这点,一定要先有一条主线,这个主线基本上是通过某个流程或功能解决某个场景下某类用户的某个需求。所以,这条主线是一开始要花费80%精力去考虑的。一旦确定,后续的决策就很轻松了,非针对场景非针对用户群的非主要需求都可以简单处理,无需上线即满足,可不断根据用户反馈及产品数据迭代优化。

其实,敏捷迭代解决的就是这类复杂业务简单处理的问题,先做主线,再做分枝,用小步快跑的形式验证需求,收集反馈,做出符合用户需求的产品。而要做到这点,就需要产品经理先从全局去考虑,把简单的需求点想复杂,然后拆出各阶段的主线,把复杂的业务做简单。

应用到上述的需求案例,先要花费大量精力和运营及市场明确,优惠券的类型有很多,但我们目前要解决什么样的问题,用哪类优惠券形式最有效,那就先做这一种;然后平台上的用户是什么特性,比较喜欢什么样的活动形式,那就先满足这种活动场景。最后,以后还可能要支持什么类型的优惠券,什么样的活动形式,现在先预留功能点,方便以后拓展。

如此,便清晰化的将本身复杂的业务进行了拆解,开发也可以分批按优先级去快速实现并接受市场的验证了。

最后

阶段一对应初级产品经理,更关注用户体验或业务方诉求;阶段二对应中级产品经理,更关注业务流程和闭环;阶段三对应高级产品经理,更关注用户核心价值和关键节点。

当然,对于一个产品经理的成长来讲,后续还有更高阶的阶段,例如让不同业务模块并联实现1+1>2的价值,例如在满足用户价值的同时实现商业目标等等,但抽象来看,基本都是基于点(功能点)、线(业务流程)、面(业务模块)、体(多业务多目标)的考虑。

每个产品经理都会经历这几个阶段,只是快慢不同,而决定快慢的因素首要的就是我们自己的认知,尽早意识和明确自己的边界,才能有针对性地去不断提升自己,尽早突破到下一级。

#专栏作家#

陆庄羽,微信公众号:看风景的人,人人都是产品经理专栏作家。擅长用户分析和原型设计,目前关注工具、内容、健康管理等方向,爱好骑行户外的伪文青一枚。

题图来自Unsplash,基于 CC0 协议

责任编辑:

相关新闻

回到首页 回到顶部

网站简介 - 广告服务 - 诚聘英才 - 联系我们 - 法律声明 - 友情链接