这篇文章，其实是写给所有人看的，无论是工作人、学生党，还是不需要工作的人，但凡需要解决问题，就需要这个技能。
但话说回本行，在2016年一整年的工作中，不断感觉到一个至少到目前为止我认为是事实的观点，那就是：产品经理的最重要或者说核心工作还是：协调资源，在合适的时候安排合适的资源在合适的地方。
这个说法在我两年前没毕业的时候，我就看到过，那时候仅仅觉得表面文字看起来好像很有道理的样子，其实并不重视。直到两年后，才从实践中慢慢感受到其中的分量。有关于这个想法的感受，之后有机会也可以写一篇文章来回顾一下吧。
那么，从这个角度来看，如何有效率的思考就成为了产品经理最重要的能力，没有之一的那种，因为有效率的思考决定了后面是否有效率的做。
当然，什么叫有效率的思考，肯定是仁者见仁，智者见智了，我将结合编撰的例子梳理下自己的看法。
核心一：抓住本质去思考
这一点，是我认为在遇到问题后第一要蹦跳出脑中的思维。任何浮于问题表面的思考所带来的解决方法，也许可以暂时解决问题，但终究不是长久之计。
举个例子吧：
老板说：“我们做一个“猜你喜欢”的功能吧，我看别人app里有这个挺好的。”
（1）老板说要做？那就妥妥做呗！
产品经理吭哧吭哧找研发捣鼓出该功能……
（2）老板说要做？可以呀，先问问为啥，理由靠谱再做。
我：“老板，你为啥想做这个功能啊？想先了解下您的目的。”
老板：“因为首页推荐位置太少了啊，我希望能多发现一些东西，让用户多停留一下，多点选择。”
我：“喔，原来是酱紫啊，感觉说的很有道理。那行，我们下个版本做这个吧。”
产品经理吭哧吭哧找研发捣鼓出该功能……
（3）老板说要做？没问题，先找出核心需求来，看情况做。
我：“老板，你为啥想做这个功能啊？想先了解下您的目的。”
老板：“因为首页推荐主题的位置太少了啊，我希望能多发现一些东西，让用户多停留一下，多点选择。”
我：“您是觉得现状寻找更多的内容很不方便吗？”
老板：“恩，是这样的。”
我：“那您想找的内容是符合你个人兴趣的，还是说平台出的新内容呢？”
老板想了一下，然后说，“平台出的新内容。”
我：“这样啊，那您看把原本放在页面最下方的最新主题部分提上来放在合适的位置上是不是就解决您的问题了呢？”
老板又想了一下，“好像是的。”
然后产品经理结合之前的用户反馈，同时考虑页面的内容框架主次，把最新主题的入口放在了首页合适的位置。既满足了用户已有的抱怨以及老板的需求、还避免了后端开发，仅需要前端调整下页面架构即可。
（例子的编撰仅为了说明某个问题，也许从另一角度来说就不对了，请不要细纠例子。）
看起来好像做法c 优于 做法b 优于 做法a，而实际上做法a和b的差别是不大的，都没有去进一步探寻问题的本质。
而这个会带来的直接结果就是拉上了设计、开发、测试为你的思考方式买单；长期结果就是不断被要求加入各种产品功能上的需求，最后自己变成写逻辑、写需求分析、画原型图的工具。最残忍的是，不了解为什么做，如何能写出简约的逻辑、画出简约的交互呢？
上面的例子还仅是产品经理在处理产品功能上的需求时的不同的做法，还没有涉及到技术本身、运营、内容、商务、第三方合作等上的需求呢。如果再加上这些，不挖掘本质思考问题的产品经理们，你觉得你能应付的了多少需求呢？
那么，如何抓到问题本质呢？
根据问题拆解，对每个拆解点做求证和判定；
直到无法拆解，做最优的组合。
不断拆解算是比较初级的做法，相当于慢慢打怪冲关直至终点；高级的做法是本身对问题的经验，相当于直接一个通关卡。当然，人不可能对所有东西都很了解，因此，一般会结合问题拆解+经验综合使用。
核心二：围绕如何解决问题去思考
这个是继抓住了问题本质后，需要马上重视的第二重要的。
举个例子：
老板说：“我们目前的版本有个比较大的问题就是用户主动寻找平台内其他内容的路径不理想，我们需要今天讨论出更合理的推荐内容的方法。”
a说：“我觉得这个问题明显就是用户太蠢，找不到推荐的入口，没啥好讨论的。”
b说：“老板，我觉得这个跟产品没关系啊，都是内容的锅，应该让内容更好的推荐内容才是。”
c说：“啊？有这个情况吗？老板你怎么感觉出来的？”
d说：“我觉得老板说的这个是客观情况，虽然不排除运营有推荐内容的合理性问题，但是确实也是功能上有欠缺的地方，日常的用户反馈以及客观埋点数据都说明了这一点。”
e说：“我赞同b的说法，关于这个我已经有一些想法了，大家可以听听看这个几个方案，然后balabalabala…”
然后d、e、老板三个人开始讨论了起来，最后他们找到了一种改动小、可能见效快的方案来改进功能。
（例子的编撰仅为了说明某个问题，也许从另一角度来说就不对了，请不要细纠例子。）
以上例子中：
a、b为“推锅型”：遇到问题第一反应是“都是别人的错，撇干净自己再说”；
c为“懵逼型”：对问题没有认知；
d、e为“客观实干型”：对问题有认知的同时还付出行动；
有主题无范围无需立刻有结果的头脑风暴集思广益；
有主题有范围无需立刻有结果的解决方案征集；
有主题有范围有特定对象需立刻有结果的解决方案征集；
……
无论表面看起来多不一样，它的本质目的都是被解决。当然，解决方案、解决程度等等都可能非常不同，这个时候，就要根据问题本身去做不同判断了。
那么，如何围绕解决问题的角度去思考呢？
找到问题目的；
撇除其他因素，只考虑问题本身，穷举解决因子；
组合解决因子，找到合适的方案。
另外，值得补充的一点是，如何解决问题其实有两个考虑纬度：问题本身、涉及考虑问题的参与者。参与者的态度以及想法，更多的是一种工作人的工作风格问题，这里就不多展开，但是不可避免的，参与者本身的风格会决定如何解决问题。
以上即是我认为思考问题的两个核心步骤，下面我来列举一下围绕思考两步骤的一些表象思维体现。
1、一个目的，多种解决方案
我觉得这个是属于大家都知道，但是在解决问题的时候，会习惯性困在问题牢笼里的一点。
而究其为啥想不到的原因，我觉得还是上文说的第一大点，因为没抓到问题的本质和核心，因为没有抓到重点，所以思维会局限在特别区域内。
举个例子：
问题：我们需要用更加简短明确的路径让用户发现更多好的内容，比如首页推荐位更多一些。
那么，可以有的做法是：
调整首页的布局，把类似内容分类、内容排行榜放在明显的位置；
调整首页的布局，再加入单独推荐的模块，例如；“猜你喜欢”、“今日最佳”等等；
调整首页原本推荐模块的呈现形式，例如从一页一页轮换的轮播图变成横栏出现一个半推荐的形式；
在用户高频使用的页面以合适的方式在合适的位置加入关联推荐；
用运营活动的方式推荐着重的内容；
记录用户行为，用短信、推送的方式推荐内容给用户；
在契合的产品中植入推荐；
……
（例子的编撰仅为了说明某个问题，也许从另一角度来说就不对了，请不要细纠例子。）
不要因为例子中的“比如首页推荐位更多一些”的话，而把自己限制在产品的首页、限制在产品功能本身。
达到同样一个目的，方法千千万，但是有些简单有些复杂，有些代价小有些代价大，这就需要经验以及拆解来细致分析啦。
2、拆解
不知道自己在这篇文章里出现过多少次这个词了，它就是辣么重要。
为什么要拆解呢？举个例子：
饿了么、美团、百度糯米大家熟悉吧？互联网人必备点餐app，红包也一定抢过吧？红包的种类特别多吧：
分享红包：行为型红包，成功购买后分享出去才能得到，有满用金额限制、失效时间；
天降红包：活动型红包，有满用金额限制、失效时间、（品类限制、使用时间段限制）
品类红包：活动型红包，有品类限制、满用金额限制、时效时间；
新人红包：活动型红包。
红包类型比较多、可控制的字段也比较多，作用也比较不同。重点是，红包可以直接抵扣订单的金额，也就是跟钱有关系，不仅是平台自己的钱，还有商户的钱。
这个时候，你说你是根据当前需要先做一个类型的红包呢还是一股脑儿的把整个系统给做了呢？
（例子的编撰仅为了说明某个问题，也许从另一角度来说就不对了，请不要细纠例子。）
那么，拆解到底能拆什么？
把整体方案拆成一个个小方案，一阶段只做一部分；
把最优方案拆成基础方案＋各个优化，先能运行起来再优化；
把整体拆成局部；
……
至于怎么拆，由于影响拆解的因子太多鸟，还是要视情况而定才可以，就不详细展开惹。（主要是特么篇幅已经太长鸟～）
3、灵活变通
灵活变通的本质还是跑不过思考的两核心：抓住本质做分析，从解决问题的角度去多种情况考虑。
举个例子：
这个版本移动端的需求已经很多了，时间很紧张，但是，客观事实是，运营想做app内发放红包的活动，需要技术力量配合。
这个时候该怎么办呢？
时间不够我也没办法，运营们自己想办法吧；
app内红包功能是肯定来不及的了，逻辑规划、设计、开发、测试一连串的新增。
运营们最终目的是希望通过优惠券的方式来降低用户购买的门槛，让用户先尝下鲜。那是不是可以做成活动h5的形式，结合后端开发呢？
（例子的编撰仅为了说明某个问题，也许从另一角度来说就不对了，请不要细纠例子。）
学会抓住目的去扩宽思路，不要被局限在小小界限内。这跟“一个目的，多种解决方法”讲的其实是一件事。但可能，这里更加突出的是时间上的紧迫性。
产品经理在日常工作中，特别容易“被临时”：发现了个bug需要解决方案、运营临时提出个活动需求、商务临时给你插了个合作方案等等，这个时候，最需要的是一颗理性分析＋灵活变通的头脑。
说起来简单，但其实还是蛮难的。这个，我觉得只有不断的去实践“被临时”，处理多了临时情况后，才能慢慢提高经验值。
4、全局
这个不用多说惹，流经产品经理这里的信息其实最多，也最考验全局的能力。
举个小小小例子：
新版本上线几天后，突然发现一个bug：自然升级的用户无法获取到新版本某个功能的某些数据，这些数据是由后端传给移动端的，可是移动端在代码处理上漏考虑自然升级的情况。
背景是，距现在15天后又有一个新版本要上线。
这个时候，解决方法可以有几种：（排除在线修复的情况）
移动端修改代码，然后再上线一个新版本；
后端简单改下api的写法，例如一秒刷一次，暂时先解决线上的bug，直到下个版本上线再改回去；
如果是你，会怎么选？
选择上线版本吧？测试／投放人力和时间成本、审核时间成本、线上bug无法马上解决、新版本迁移过渡频繁、版本埋点数据无效等等问题会出现；
选择改后端写法吧？不是长久之计、万一临时出问题怎么办；
（例子的编撰仅为了说明某个问题，也许从另一角度来说就不对了，请不要细纠例子。）
全局思考的考验每天都会出现，产品经理们需要不断从决策中积累经验。
好像由思维核心延伸的表象思维也说完了，最后说一下常见的几个思维误区好了。
常见的几个思维误区
1、纯因为自己擅长什么，就推崇什么
举一些“一般来说”的例子吧（误伤请不要认真）：
开发喜欢走开发主导的路线、产品喜欢走产品主导的路线、运营喜欢走运营主导的路线；
有些产品无视产品本身特点，喜欢把产品往社交、内容或者其他之前做过的、自己熟的方向上带；
有些运营无视产品本身特点，喜欢按照自己之前用过的运营方法去推广产品；
有些开发习惯了用自己的编程语言，一味抵制学习、接受新的语言，没了解就觉得其他语言都是垃圾；
……
大到产品方向、开发语言、运营宗旨的选择，小到小问题的不同处理方式，都容易出现这样的问题。
不要觉得这个问题好像你没遇到过，我不！相！信！
对于这种情况，我觉得其实没啥特别好的处理方法，只能希望团队中的人们都是理性、客观的人儿惹吧。
还有一种绝对方面的情况，那就是：纯因为自己不擅长什么，就反对什么。日常中这种例子也比较多，大家可以细心感受一下，我就不多说惹。
2、脱离目的的试图证明自己更对
我觉得这个和性格有很大关系吧，最容易在考虑如何解决问题的时候发生。
举个例子：
问题：用户如何在淘宝上找到自己曾经买过的店铺，重新进去买东西？
a说：“我看到靠谱的店铺会收藏啊，直接从收藏的店铺进去就好了。”
b说：“我一般都在购买过的订单列表里找那家店，然后进去。”
c说：“我靠，乃们居然不是从首页直接搜索店铺进去的？！”
d说：“只有我特么是从购物车里进去的吗？”
……
以上的问题大家发现没有，其实本身就没有标准答案，因为这和每个人的行为习惯有关系。没有对错，只有程度的差别。
另一个明显的例子就是辩论。在辩论中，两方都会对题目设定一些边界、前置条件，从而来试图表明自己的观点更正确。
对于类似这种无对错的讨论，其实根本无法证明自己的思路更正确，即使通过一些数据去证明了，也在很大可能性上对解决问题没有帮助。
