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

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

　　但是这些都是各个公司根据业务和发展的需求进行的区分，并不能体现出产品经理在能力上本质的差别。甚至，很多所谓的高级产品经理和产品总监也名不副实，不过是在一家公司的一个岗位上的时间久而已，和同行优秀者相比并不具备竞争力。

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

　　笔者私以为产品经理竞争力上的差别，很大的程度上取决于其能否发现问题和解决问题，也就是是否做正确的事和正确地做事，这才是体现思维能力和思维层次的地方。见过不少同行工作了多年还是不具备独立思考的能力，对于做过的项目还能正常推进，但是一遇到不熟悉的项目就懵逼不知道怎么入手。

　　笔者也经历过这样的阶段，即使到现在也不能保证项目交到手里、在没有指导的情况下也能完成。不过，在经历过多次磨练后小有心得，形成了自己的方法论。

　　在此把它概括成七步：

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

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

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

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

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

　　如何搞定资源？

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

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

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

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

　　时间是周五下午3点，S在wiki上写完周报。虽然为了赶下周上线的排期，RD周六要来公司加班一天，自己作为负责任的PM也要来，但是最近项目进展还比较顺利，心情大好。这时上级T在内部通讯工具里@S让她过去一趟。

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

　　相信多数PM都有经历过类似的情况，如果S是菜鸟，可能不问三七二十一就按上级吩咐的做了，毕竟有这张免死金牌也能把项目推起来。但是结果不一定尽如人意，在研发超负荷工作的上线关键阶段，突然插进紧急的新需求，将使两个项目的质量都受到影响。

　　如果S是老鸟，她可能会这样思考：为什么要做这个项目？今天是周五，虽然老板不靠谱（员工多少会有这种想法），但是现在人力超负荷的情况他是知道的。而且开发中的项目也是一个大型活动，早就规划好了，是不论如何都不能延期的，在这种情况下还有新增一个活动，是出于什么考虑呢？运营制定好活动规则一般会先同步给PM，为什么这次跳过PM直接汇报到老板那？运营方案才通过就开始协调库存，这个节奏也不正常，是什么原因需要做的这么匆忙？

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

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

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

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

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

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

　　1是问题吗？

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

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

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

　　3才是问题！在项目管理里，时间、质量、成本是“不可能三角”，强行提高其中一个指标都会对其余两个指标造成影响。现在的情况是要在短时间内以有限的资源完成项目，那么只能牺牲一部分质量。这样问题就明确了。

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

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

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

　　利益相关：老板和上级自不用说，这个项目必须要能在他们预期的时间上线；运营方面需要尽快去了解他们的活动规则是什么，这样才能出方案；研发方面，研发leader已经知道情况，表示后端人力都在项目上，前端有一个人力可以支持；既然做活动，肯定需要UI的支持，虽然她们在项目上，但是调整一下优先级是OK的。

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

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

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

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

　　我们假设S有这三种选择，而且很清楚地知道每个方案的优缺点。实际上，任何一个方案都可能是个好方案，也可能是个错误，关键是需要根据实际的情况进行拿捏，选择投入小收益大的方案，这里所说的收益不单是短期的收益而且还是长期的，不单是个人的收益而且是所有利益相关方的。

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

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

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

　　第六步：搞定欠缺的资源

　　需求文档S自己写就行，因为是项目组的组织形式，所以前端、UI、QA都挂在一个leader下面，而且他已经得到了新项目的消息，S和这个leader沟通一下方案即可。表单工具的账号还未注册，而注册表单账号需要使用公司的对外邮箱，邮箱由项目组内的一位同事负责。

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

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

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

　　很多情况下，当PM对配合的团队和流程熟悉后，对于简单的项目，在无意识中就可以完成思考。但是对于复杂的情况，特别是涉及面广、牵扯的团队多、项目流程长、不可控因素多的时候，是很有必要进行方案拆解的。