作者:霹雳
全文共 2815 字 2 图,阅读需要 6 分钟
———— / BEGIN / ————
互联网行业发展的这些年,培育了一批又一批产品经理。
起初大家都统称为“产品经理”,后来进一步分成了app产品经理、网页产品经理、后端产品经理、桌面软件产品经理。到了现在,分得就更细了,可以结合类型(如社交、游戏、电商、金融),可结合模块(如消息推送、支付、订单等),也可以结合业务(招聘网站上常常出现XX业务产品经理)。
但是这些都是各个公司根据业务和发展的需求进行的区分,并不能体现出产品经理在能力上本质的差别。
甚至,很多所谓的高级产品经理和产品总监也名不副实——不过是在一家公司的一个岗位上的时间久而已,和同行优秀者相比并不具备竞争力。
那么,产品经理的竞争力体现在什么地方呢?
笔者私以为:产品经理竞争力上的差别,很大的程度上取决于其能否发现问题和解决问题,也就是是否做正确的事和正确地做事,这才是体现思维能力和思维层次的地方。
见过不少同行工作了多年还是不具备独立思考的能力,对于做过的项目还能正常推进,但是一遇到不熟悉的项目就懵逼不知道怎么入手。
笔者也经历过这样的阶段,即使到现在也不能保证项目交到手里、在没有指导的情况下也能完成。
不过,在经历过多次磨练后小有心得,形成了自己的方法论。
在此把它概括成七步:
面临的问题是什么(只能有一个)?
问题的背景是什么,利益相关方有哪些?
导致问题出现的原因是什么?
用什么方法可以解决问题?
目前欠缺什么资源和条件?
如何搞定资源?
怎样进行任务排序,时间规划如何?
以下结合案例来说明(纯属虚构)。
第一步:思考问题是什么?
S是活动产品经理,主要对接用户运营部门,跟进各类活动项目的需求-开发-上线,工作中涉及的系统有运营平台的活动管理模块及app端的活动banner位。
时间是周五下午3点,S在wiki上写完周报。虽然为了赶下周上线的排期,RD周六要来公司加班一天,自己作为负责任的PM也要来,但是最近项目进展还比较顺利,心情大好。
这时上级T在内部通讯工具里@S让她过去一趟。
相信多数PM都有经历过类似的情况,如果S是菜鸟,可能不问三七二十一就按上级吩咐的做了,毕竟有这张免死金牌也能把项目推起来。
但是结果不一定尽如人意,在研发超负荷工作的上线关键阶段,突然插进紧急的新需求,将使两个项目的质量都受到影响。
如果S是老鸟,她可能会这样思考:为什么要做这个项目?
今天是周五,虽然老板不靠谱(员工多少会有这种想法),但是现在人力超负荷的情况他是知道的。
而且开发中的项目也是一个大型活动,早就规划好了,是不论如何都不能延期的,在这种情况下还有新增一个活动,是出于什么考虑呢?
运营制定好活动规则一般会先同步给PM,为什么这次跳过PM直接汇报到老板那?运营方案才通过就开始协调库存,这个节奏也不正常,是什么原因需要做的这么匆忙?
S:我们做这个项目要达到什么目的和目标呢?
T:老板听说对手Q想要做一个与我们对标的活动,而且有可能先于我们上线,所以紧急批了预算并且找运营新加了预约的活动,目的是狙击对手和给大型活动预热,并没有具体的目标。
到这里,情况相对比较清晰了,S分析目前的情况:
有一个高优先级的项目紧急插入;
(不用协调也知道)RD资源不足,可能会顾此失彼;
以现在的资源情况,不能完全开发好活动并且按时上线。
1是问题吗?
第一感觉好像是,但是类似情况到处都有,而且没有说明危害性如何,所以这只是问题的表象。
2呢,资源不足是问题吗?
有道理,但是在互联网公司资源不足是常态,没见哪家公司因为这个原因挂掉的。
3才是问题!在项目管理里,时间、质量、成本是“不可能三角”,强行提高其中一个指标都会对其余两个指标造成影响。
现在的情况是要在短时间内以有限的资源完成项目,那么只能牺牲一部分质量。
这样问题就明确了。
第二步:分析背景和利益相关方
外部背景:
Q是公司的死对头,在过去几个月一直打得不分上下,一方有动静另一方马上跟进。现在S的公司稍占上风,目前集中全公司的力量都在设法保证优势能持续下去。
内部背景:
大家连续几个星期周六加班,已经有些疲惫,而且早就安排了研发任务,也不可能抽调更多人力投入新任务。
利益相关:
老板和上级自不用说,这个项目必须要能在他们预期的时间上线;运营方面需要尽快去了解他们的活动规则是什么,这样才能出方案;
研发方面,研发leader已经知道情况,表示后端人力都在项目上,前端有一个人力可以支持;既然做活动,肯定需要UI的支持,虽然她们在项目上,但是调整一下优先级是OK的。
第三步:分析产生问题的原因
这一点上面已经说过,是因为时间和资源没有什么调整空间,但是还要尽量保证质量。
第四步:用演绎法列举出所有可能的解决办法
用归纳法得出每个解决办法的优点和缺点。
我们假设S有这三种选择,而且很清楚地知道每个方案的优缺点。
实际上,任何一个方案都可能是个好方案,也可能是个错误,关键是需要根据实际的情况进行拿捏,选择投入小收益大的方案,这里所说的收益不单是短期的收益而且还是长期的,不单是个人的收益而且是所有利益相关方的。
第五步:分析现在还欠缺的资源和条件
假设S和上司、老板、运营都沟通完毕,确定了选择第三套方案。现在S需要需求文档、前端、UI、QA资源,还需要使用公司统一的外部表单账号,所有这些到现在为止都没有确定。
第六步:搞定欠缺的资源
需求文档S自己写就行,因为是项目组的组织形式,所以前端、UI、QA都挂在一个leader下面,而且他已经得到了新项目的消息,S和这个leader沟通一下方案即可。
表单工具的账号还未注册,而注册表单账号需要使用公司的对外邮箱,邮箱由项目组内的一位同事负责。
第七步:要做的事情清楚了
S罗列出先后顺序(创业公司的节奏)。
这样整个方案就出来了,之后按照计划执行即可。
很多情况下,当PM对配合的团队和流程熟悉后,对于简单的项目,在无意识中就可以完成思考。
但是对于复杂的情况,特别是涉及面广、牵扯的团队多、项目流程长、不可控因素多的时候,是很有必要进行方案拆解的。
拆解的能力非常考验PM的功力,也是很多招聘者在面试中喜欢考的问题。
而且不止于此,在日常生活中,如果好好培养和运用这一能力,很多问题将迎刃而解,生活效率也将得到提高,这里就不具体举例了,读者感兴趣的话可以试试。
———— / END / ————
本文由 @霹雳 原创发布于人人都是产品经理。未经许可,禁止转载
点击“阅读原文”下载APP