作者：霹雳

​来源：人人都是产品经理

编辑：善小倩

 

 

互联网行业发展的这些年，培育了一批又一批产品经理。

 

起初大家都统称为“产品经理”，后来进一步分成了app产品经理、网页产品经理、后端产品经理、桌面软件产品经理。到了现在，分得就更细了，可以结合类型（如社交、游戏、电商、金融），可结合模块（如消息推送、支付、订单等），也可以结合业务（招聘网站上常常出现XX业务产品经理）。

 

但是这些都是各个公司根据业务和发展的需求进行的区分，并不能体现出产品经理在能力上本质的差别。

 

甚至，很多所谓的高级产品经理和产品总监也名不副实——不过是在一家公司的一个岗位上的时间久而已，和同行优秀者相比并不具备竞争力。

 

那么，产品经理的竞争力体现在什么地方呢？

 

笔者私以为：产品经理竞争力上的差别，很大的程度上取决于其能否发现问题和解决问题，也就是是否做正确的事和正确地做事，这才是体现思维能力和思维层次的地方。

 

见过不少同行工作了多年还是不具备独立思考的能力，对于做过的项目还能正常推进，但是一遇到不熟悉的项目就懵逼不知道怎么入手。

 

笔者也经历过这样的阶段，即使到现在也不能保证项目交到手里、在没有指导的情况下也能完成。

 

不过，在经历过多次磨练后小有心得，形成了自己的方法论。

 

在此把它概括成七步：

 

1. 面临的问题是什么（只能有一个）？

2. 问题的背景是什么，利益相关方有哪些？

3. 导致问题出现的原因是什么？

4. 用什么方法可以解决问题？

5. 目前欠缺什么资源和条件？

6. 如何搞定资源？

7. 怎样进行任务排序，时间规划如何？

 

以下结合案例来说明（纯属虚构）。

 

第一步：思考问题是什么？

 

S是活动产品经理，主要对接用户运营部门，跟进各类活动项目的需求-开发-上线，工作中涉及的系统有运营平台的活动管理模块及app端的活动banner位。

 

时间是周五下午3点，S在wiki上写完周报。虽然为了赶下周上线的排期，RD周六要来公司加班一天，自己作为负责任的PM也要来，但是最近项目进展还比较顺利，心情大好。

 

这时上级T在内部通讯工具里@S让她过去一趟。

 

T：老板刚刚组织了一个电话会议，要求下周一上线一个预约活动，运营部门已经制定好活动规则，现在开始协调库存。你出一个产品方案，找研发协调人力，明天加班赶一下，下周一晚上就上线。

 

相信多数PM都有经历过类似的情况，如果S是菜鸟，可能不问三七二十一就按上级吩咐的做了，毕竟有这张免死金牌也能把项目推起来。

 

但是结果不一定尽如人意，在研发超负荷工作的上线关键阶段，突然插进紧急的新需求，将使两个项目的质量都受到影响。

 

如果S是老鸟，她可能会这样思考：为什么要做这个项目？

 

今天是周五，虽然老板不靠谱（员工多少会有这种想法），但是现在人力超负荷的情况他是知道的。

 

而且开发中的项目也是一个大型活动，早就规划好了，是不论如何都不能延期的，在这种情况下还有新增一个活动，是出于什么考虑呢？

 

运营制定好活动规则一般会先同步给PM，为什么这次跳过PM直接汇报到老板那？运营方案才通过就开始协调库存，这个节奏也不正常，是什么原因需要做的这么匆忙？

 

S：我们做这个项目要达到什么目的和目标呢？

 

T：老板听说对手Q想要做一个与我们对标的活动，而且有可能先于我们上线，所以紧急批了预算并且找运营新加了预约的活动，目的是狙击对手和给大型活动预热，并没有具体的目标。

 

到这里，情况相对比较清晰了，S分析目前的情况：

 

1. 有一个高优先级的项目紧急插入；

2. （不用协调也知道）RD资源不足，可能会顾此失彼；

3. 以现在的资源情况，不能完全开发好活动并且按时上线。

 

1是问题吗？

 

第一感觉好像是，但是类似情况到处都有，而且没有说明危害性如何，所以这只是问题的表象。

 

2呢，资源不足是问题吗？

 

有道理，但是在互联网公司资源不足是常态，没见哪家公司因为这个原因挂掉的。

 

3才是问题！在项目管理里，时间、质量、成本是“不可能三角”，强行提高其中一个指标都会对其余两个指标造成影响。

 

现在的情况是要在短时间内以有限的资源完成项目，那么只能牺牲一部分质量。

 

这样问题就明确了。

 

第二步：分析背景和利益相关方

 

外部背景：

 

Q是公司的死对头，在过去几个月一直打得不分上下，一方有动静另一方马上跟进。现在S的公司稍占上风，目前集中全公司的力量都在设法保证优势能持续下去。

 

内部背景：

 

大家连续几个星期周六加班，已经有些疲惫，而且早就安排了研发任务，也不可能抽调更多人力投入新任务。

 

利益相关：

 

老板和上级自不用说，这个项目必须要能在他们预期的时间上线；运营方面需要尽快去了解他们的活动规则是什么，这样才能出方案；

 

研发方面，研发leader已经知道情况，表示后端人力都在项目上，前端有一个人力可以支持；既然做活动，肯定需要UI的支持，虽然她们在项目上，但是调整一下优先级是OK的。

 

第三步：分析产生问题的原因

 

这一点上面已经说过，是因为时间和资源没有什么调整空间，但是还要尽量保证质量。

 

第四步：用演绎法列举出所有可能的解决办法

 

用归纳法得出每个解决办法的优点和缺点。

 

 

我们假设S有这三种选择，而且很清楚地知道每个方案的优缺点。

 

实际上，任何一个方案都可能是个好方案，也可能是个错误，关键是需要根据实际的情况进行拿捏，选择投入小收益大的方案，这里所说的收益不单是短期的收益而且还是长期的，不单是个人的收益而且是所有利益相关方的。

 

比如：S可以狐假虎威、威逼利诱让RD同学加班完成项目，但是这种方案不能常用，特别是这样做对公司没有带来什么好处的时候，因为这既伤害了长期利益也伤害的别人的利益。

 

第五步：分析现在还欠缺的资源和条件

 

假设S和上司、老板、运营都沟通完毕，确定了选择第三套方案。现在S需要需求文档、前端、UI、QA资源，还需要使用公司统一的外部表单账号，所有这些到现在为止都没有确定。

 

第六步：搞定欠缺的资源

 

需求文档S自己写就行，因为是项目组的组织形式，所以前端、UI、QA都挂在一个leader下面，而且他已经得到了新项目的消息，S和这个leader沟通一下方案即可。

 

表单工具的账号还未注册，而注册表单账号需要使用公司的对外邮箱，邮箱由项目组内的一位同事负责。

 

第七步：要做的事情清楚了

 

S罗列出先后顺序（创业公司的节奏）。

 

 

这样整个方案就出来了，之后按照计划执行即可。

 

很多情况下，当PM对配合的团队和流程熟悉后，对于简单的项目，在无意识中就可以完成思考。

 

但是对于复杂的情况，特别是涉及面广、牵扯的团队多、项目流程长、不可控因素多的时候，是很有必要进行方案拆解的。

 

拆解的能力非常考验PM的功力，也是很多招聘者在面试中喜欢考的问题。

 

而且不止于此，在日常生活中，如果好好培养和运用这一能力，很多问题将迎刃而解，生活效率也将得到提高，这里就不具体举例了，读者感兴趣的话可以试试。

 

 

— end —